Re: New init system hitting a distro near you.

[Paul Moore <paul.moore@hp.com>]

On Friday, June 18, 2010 04:31:45 pm Stephen Smalley wrote:
> On Fri, 2010-06-18 at 16:22 -0400, Stephen Smalley wrote:
> > On Fri, 2010-06-18 at 16:00 -0400, Daniel J Walsh wrote:
> > > On 06/18/2010 03:45 PM, Stephen Smalley wrote:
> > > > On Fri, 2010-06-18 at 15:34 -0400, Daniel J Walsh wrote:
> > > >> http://0pointer.de/blog/projects/systemd.html
> > > >> 
> > > >> This has interesting ramifications for SELinux.  I have a working
> > > >> version of this in Fedora 14, but we need to add rules like
> > > >> 
> > > >> allow sshd_t init_t:tcp_socket { getopt ioctl getattr setopt };
> > > >> 
> > > >> Since systemd will be doing the listening and passing the socket to
> > > >> sshd.
> > > >> 
> > > >> Could we have risks of sshd_t grabbing the tcp_socket connected to
> > > >> httpd_t?
> > > >> 
> > > >> In this scenario we are no longer protecting against the name_bind,
> > > >> and are forced to put more trust into init_t.
> > > > 
> > > > Can we get systemd to use setsockcreatecon() to assign the right
> > > > label to the socket?
> > > 
> > > Probably but how does it figure out the context?
> > 
> > The sockets would normally be labeled with the context of the individual
> > daemon process.  So we would want to compute the context in which the
> > daemon process will run and then use that for the socket.  Which we can
> > do via security_compute_create().  Sample code attached.  Compile with:
> > gcc -lselinux -o setsockcon setsockcon.c
> > 
> > Example run (in permissive):
> > $ runcon system_u:system_r:init_t:s0 ./setsockcon /usr/sbin/sshd
> > /usr/sbin/sshd system_u:system_r:sshd_t:s0
> 
> So the concept here is that systemd must already know the path to the
> daemon executable as part of its config, so it can call the
> setsockconfrompath() function on that path prior to calling socket() to
> create the socket.  You can have the function bail immediately if
> (is_selinux_enabled() < 1), and perhaps ignore errors from it if
> (security_getenforce() < 1).
> 
> We'll need something similar for Unix domain sockets to ensure that the
> file gets labeled properly, but using security_compute_create() on the
> daemon context, the parent directory context, and
> string_to_security_class("sock_file") to determine the right context and
> using setfscreatecon() before calling bind().  A bit messy.

I would need to check the code a bit closer and test it to be certain but I 
believe that setsockcreatecon() should work for UNIX domain sockets too.  At 
least selinux_socket[_post]_create() applies the sockcreate_sid regardless of 
the socket's address family.

Granted, determining the correct label is still a bit ugly but at least you 
don't have to use setfscreatecon() would could get nasty very quickly if 
you're not careful.

-- 
paul moore
linux @ hp

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.