On 18/05/16 10:03, David Lang wrote:
On Wed, 18 May 2016, John Crispin wrote:
On 18/05/2016 09:46, Ferry Huberts wrote:
On 18/05/16 09:25, John Crispin wrote:
On 18/05/2016 09:21, Radu Anghel wrote:
/* sending again because i hit 'reply' instead of 'reply all' :) */
On Wed, May 18, 2016 at 8:29 AM, John Crispin <j...@phrozen.org>
wrote:
ok, there had been some discussion about building a super daemon that
runs, then ld-preloading bind() and co and using ubus to transport
sockets around. using caps or /proc sounds like a good i between
until
such a daemon exists
Most daemons I know of that need to bind to ports <1024 start as root
and after binding to the port they drop privileges to the privileges
of the user specified in their config file. For those daemons just
adding a user and specifying it in their config file should be enough.
For the daemons that don't need to bind to <1024 just starting them
from their own user account is ok as they don't need additional
privileges.
For example the dnsmasq daemon has these options:
# If you want dnsmasq to change uid and gid to something other
# than the default, edit the following lines.
#user=
#group=
I don't think that integrating such functionality in ubus or some
other LEDE-only super-daemon is a good idea. Config options +
capabilities for those daemons withut such options is a good way of
doing this in my opinion. Also use different users for different
daemons, as others said.
to elaborate, imagine dnsmasq running inside a jailm where ut only
thinks it is root but is not in reality. also ld-preloading bind and
connect would allow us to do pretty adavnced stuff like only allowing
dnsmasq to open certain ports. essentially an acl around the
bind/connect calls.
You might just as well switch on SELinux and use the policies that are
already in-place in Fedora and RedHat/CentOS.
You then get even stronger protection and run-time performance impact is
negligible.
the stuff i proposed has not runtime hit. selinux is simple to full
SELinux's hit is for all intents and purposes zero as well nowadays.
blown and hard to maintain. the idea would be to create a custom
tailored solution for our requirements.
That is why I prefer AppArmor, you don't have the interaction between
different application configs that you do with SELinux, so you can focus
on the specific application that you are concerned about.
AppArmor is significantly less secure than SELinux.
And with SELinux you don't need all the preloading stuff that was talked
about, you can just declare which ports are allowed.
SELinux configs that Fedora uses have to be so permissive to keep from
breaking too many 'normal' use cases that I really question how valuable
they are.
And this is based on what exactly?
I've been using Fedora ever since SELinux was first enabled and I don't
see that. Processes are well secured.
If you think about stuff like Firefox, then ok, that one is really hard
to secure, better run it in a sandbox.
But process that are well-defined in behaviour are well secured.
A SELinux system tuned by an expert is going to be more secure than an
AppArmor system tuned by an expert, SELinux just can do more (at least
right now). But there aren't many experts of that caliber around. A
reasonably competent sysadmin can understand an AppArmor config and
tweak it for their layout without too much effort (once they identify
that AppArmor is blocking what they are trying to do)
Agreed, it is a balance.
However, I must note that I've encountered very few cases where the
policy had to be tweaked, on my laptops, desktop and most of all servers.
One example of tweaking is when I move a service to a different port.
That is a single command, like (moving the port of the 'cockpit' service):
semanage port -a -t websm_port_t -p tcp "$newport"
My 2 cents :-)
David Lang
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
--
Ferry Huberts
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
