<michich> dwalsh, journald gets the context using getpidcon(). it may fail for some reason. one possible reason being that the pid is already gone. * scientes (~scientes@unaffiliated/scientes) has joined #systemd <michich> dwalsh, what's why Lennart asks for "Support passing SELinux labels a la SCM_CREDENTIALS via AF_UNIX sockets." in the "plumber's wishlist" * dhaval has quit (Ping timeout: 240 seconds) <Viking-Ice> dwalsh, excellent blog post as usual * nphilipp has quit (Quit: Leaving) * styrsven (~sven.tele2.se) has joined #systemd <mezcaler1> dwalsh: hmm, so if you run "logger" without a cmdline param <mezcaler1> dwalsh: and then type stuff into it <mezcaler1> dwalsh: do you see the selinux context then? <mezcaler1> dwalsh: if so, then this is the race that michich pointed out <mezcaler1> dwalsh: i.e. when we try to read the context the PID might already be gone <mezcaler1> dwalsh: and yeah, wee need something like SCM_CREDENTIALS for this to fix this properly
So this is a kernel issue?
Yes, we need some functionality in the kernel here, where we can racefreely determine the SELinux context of a process on the other side of a socket, without being vulnerable to the problem that we might read the context of the PID we were notified about only after the sending process is already gone. The idea is to have something like SCM_CREDENTIALS (which only sends pid, uid and gid) which sends over the SELinux context instead. (This would be truly useful in many other cases too, i.e. in the dbus context). So yes, we need a kernel feature for this, and we added it to the kernel plumbers wishlist: https://docs.google.com/document/pub?id=1RmJrtIoTnivkmR9KCqfJNBnEll4X9Jtu0xj5w6hFGs8
What kind of sockets, AF_UNIX only? If so, have you looked at the getpeercon() function?
Yes, AF_UNIX, but datagram sockets (SOCK_DGRAM). I don't think getpeercon() will help here.
Okay, if we're talking datagram sockets then setsockopt(SO_PASSSEC) followed by a recvmsg() looking for SOL_SOCKET/SCM_SECURITY should work.
Oh, interesting, this already exists? is this documented anywhere? what is the format of the SCM_SECURITY data?
(In reply to comment #6) > Oh, interesting, this already exists? Yep. It has existed for some time now. > ... is this documented anywhere? Probably, somewhere. I honestly don't know. > what is the format of the SCM_SECURITY data? Based on the kernel source, it is just a string representing the security label, aka SELinux context.
(In reply to comment #7) > > ... is this documented anywhere? > > Probably, somewhere. I honestly don't know. Hmm, google doesn't find anything useful. Neither documentation nor any code using this. > > what is the format of the SCM_SECURITY data? > > Based on the kernel source, it is just a string representing the security > label, aka SELinux context. Humm, so if I enable SO_PASSEC on an AF_UNIX SOCK_DGRAM socket and recieve a message over it from a process running as unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 I see a control string for SCM_SECURITY of precisely 8 chars which read "unconfin". Why is that truncated? Is that a kernel bug? If not, how can i turn this into something more useful?
Kernel is Linux omega 3.3.0-0.rc6.git0.2.fc17.x86_64 #1 SMP Mon Mar 5 16:54:07 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
I am an idiot. Sizing the control buffer to recvmsg() fixes the issue. Hmm, what's the right amount of space I need to reserve in the control buffer for the label? there doesn't seem to be a #define for the maximum label length exported anywhere. I am looking for something like PATH_MAX but for labels. Any idea?
I don't know if there is a max. Added Steve and Eric.
There is no true maximum. Although most of our kernel/userspace buffers are of page size. So that's what we usually recommend as a maximum.
Hmm, not having a maximum there really sounds like it was the brainchaild of some GNU/Hurd apologetic... ;-) Anyway, I have now changed my code to allocate PAGE_SIZE for this, even though it sounds a bit much. So I guess I can close this bug now, since this is fixed in git.
systemd-44-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/systemd-44-1.fc17
Package systemd-44-1.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-44-1.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-3918/systemd-44-1.fc17 then log in and leave karma (feedback).
systemd-44-1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.