Bug 798760 - systemd-journal does not record the SELinux context of a process that exits as soon as it sends the syslog message
Summary: systemd-journal does not record the SELinux context of a process that exits a...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 17
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-02-29 18:57 UTC by Daniel Walsh
Modified: 2012-03-21 19:10 UTC (History)
10 users (show)

Fixed In Version: systemd-44-1.fc17
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-03-21 19:10:02 UTC
Type: ---


Attachments (Terms of Use)

Description Daniel Walsh 2012-02-29 18:57:19 UTC
<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@m90-141-46-226.cust.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

Comment 1 Daniel Walsh 2012-02-29 18:57:53 UTC
So this is a kernel issue?

Comment 2 Lennart Poettering 2012-03-12 13:30:16 UTC
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

Comment 3 Paul Moore 2012-03-12 13:40:01 UTC
What kind of sockets, AF_UNIX only?  If so, have you looked at the getpeercon() function?

Comment 4 Michal Schmidt 2012-03-12 14:03:16 UTC
Yes, AF_UNIX, but datagram sockets (SOCK_DGRAM). I don't think getpeercon() will help here.

Comment 5 Paul Moore 2012-03-12 14:35:36 UTC
Okay, if we're talking datagram sockets then setsockopt(SO_PASSSEC) followed by a recvmsg() looking for SOL_SOCKET/SCM_SECURITY should work.

Comment 6 Lennart Poettering 2012-03-12 19:19:25 UTC
Oh, interesting, this already exists? is this documented anywhere? what is the format of the SCM_SECURITY data?

Comment 7 Paul Moore 2012-03-12 19:43:28 UTC
(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.

Comment 8 Lennart Poettering 2012-03-12 22:59:28 UTC
(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?

Comment 9 Lennart Poettering 2012-03-12 22:59:48 UTC
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

Comment 10 Lennart Poettering 2012-03-12 23:53:21 UTC
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?

Comment 11 Daniel Walsh 2012-03-13 10:46:26 UTC
I don't know if there is a max.  Added Steve and Eric.

Comment 12 Eric Paris 2012-03-13 13:11:48 UTC
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.

Comment 13 Lennart Poettering 2012-03-14 02:41:52 UTC
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.

Comment 14 Fedora Update System 2012-03-16 02:01:28 UTC
systemd-44-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/systemd-44-1.fc17

Comment 15 Fedora Update System 2012-03-16 19:02:02 UTC
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).

Comment 16 Fedora Update System 2012-03-21 19:10:02 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.