Re: [systemd-devel] SELinux labels on unix sockets
For the sock *file*, i would argue, that indeed the setfscreatecon is not strictly needed, and that the labeling for this can be taken care of by using type transition rules in the security policy as suggested. However for the socket classes associated with the process type, setsockcreatecon is required The socket activation selinux related aspect has two parts: 1. the socket associated with the process (setsockcreatecon()) 2. the actual socket file (setfscreatecon()) The latter (2) can, and should *probably* be removed. The setsockcreatecon() stuff should stay, and the setfscreatecon() stuff should *probably* go. -- 02DFF788 4D30 903A 1CF3 B756 FB48 1514 3148 83A2 02DF F788 http://keys.gnupg.net/pks/lookup?op=vindexsearch=0x314883A202DFF788 Dominick Grift pgpuyk4nWBLag.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SELinux labels on unix sockets
On Wed, Mar 25, 2015 at 10:31:41PM +0100, Dominick Grift wrote: For the sock *file*, i would argue, that indeed the setfscreatecon is not strictly needed, and that the labeling for this can be taken care of by using type transition rules in the security policy as suggested. However for the socket classes associated with the process type, setsockcreatecon is required The socket activation selinux related aspect has two parts: 1. the socket associated with the process (setsockcreatecon()) 2. the actual socket file (setfscreatecon()) The latter (2) can, and should *probably* be removed. The setsockcreatecon() stuff should stay, and the setfscreatecon() stuff should *probably* go. Actually, come to think about it, it is not that simple and things should probably stay as they are. For multi level security configurations the proper security level must be associated with the sock file, and that cannot be specified with a type transition rule. It should stay the way it currently is. -- 02DFF788 4D30 903A 1CF3 B756 FB48 1514 3148 83A2 02DF F788 http://keys.gnupg.net/pks/lookup?op=vindexsearch=0x314883A202DFF788 Dominick Grift -- 02DFF788 4D30 903A 1CF3 B756 FB48 1514 3148 83A2 02DF F788 http://keys.gnupg.net/pks/lookup?op=vindexsearch=0x314883A202DFF788 Dominick Grift pgpzL_PeTYa_Q.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SELinux labels on unix sockets
Lennart Poettering lenn...@poettering.net writes: On Fri, 06.03.15 13:04, Jan Synáček (jsyna...@redhat.com) wrote: Hello, when systemd creates a socket file, it explicitly calls a selinux procedure to label it. I don't think that is needed, as the kernel does the right thing when the socket is created. Am I missing something? Why is the explicit labeling in place? Well, it's complicated. If we use socket activation we label a socket taking into account the label of the binary that is eventually started for it. And then, for file system sockets the kernel could traditionally only derive the label to use from the directory the socket was created in, which makes it difficult to have multiple sockets in the same directory with different labels, which is pretty frequently done though. That said, I think this limitation was lifted a while back in the kernel, and the policy can now also take the socket file name into consideration and derive different labels automatically. Ultimately, I only superficially understand the selinux code. We rely on patches from Dan co to keep it up-to-date. Better keep him in the loop. If there is a way to specify the automatic labeling of the socket files according to their names, and not the directory that they reside in, in the policy, then the code that does the explicit labeling isn't necessary. If not, the code would label the sockets incorrectly, which is what actually happens now. Plus the fact that systemd doesn't correctly re-require the libselinux handle (meaning that policy updates/reloads are not recognized) on policy changes makes the logic not work. I've tried to write a small piece of code that would execute whenever a policy is modified, but failed to do so. Calling selinux_set_callback(SELINUX_CB_POLICYLOAD, cb) doesn't do anything. So, I think that the code that explictly labels the socket files should be removed. It would be nice to hear from Dan, though. Cheers, -- Jan Synacek Software Engineer, Red Hat signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] SELinux labels on unix sockets
Hello, when systemd creates a socket file, it explicitly calls a selinux procedure to label it. I don't think that is needed, as the kernel does the right thing when the socket is created. Am I missing something? Why is the explicit labeling in place? Cheers, -- Jan Synacek Software Engineer, Red Hat signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SELinux labels on unix sockets
On Fri, 06.03.15 13:04, Jan Synáček (jsyna...@redhat.com) wrote: Hello, when systemd creates a socket file, it explicitly calls a selinux procedure to label it. I don't think that is needed, as the kernel does the right thing when the socket is created. Am I missing something? Why is the explicit labeling in place? Well, it's complicated. If we use socket activation we label a socket taking into account the label of the binary that is eventually started for it. And then, for file system sockets the kernel could traditionally only derive the label to use from the directory the socket was created in, which makes it difficult to have multiple sockets in the same directory with different labels, which is pretty frequently done though. That said, I think this limitation was lifted a while back in the kernel, and the policy can now also take the socket file name into consideration and derive different labels automatically. Ultimately, I only superficially understand the selinux code. We rely on patches from Dan co to keep it up-to-date. Better keep him in the loop. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
