On Monday, June 21, 2010 11:26:48 am Stephen Smalley wrote: > On Mon, 2010-06-21 at 11:20 -0400, Paul Moore wrote: > > 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. > > With Unix domain sockets bound to the filesystem namespace, there are > two separate objects: the socket and the file. Yes, sorry, my mistake; I was thinking of the socket fsetxattr() labeling support - that supported labeling the filesystem and socket components of a UNIX domain socket. -- 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@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
