Bug 798760

Summary:	systemd-journal does not record the SELinux context of a process that exits as soon as it sends the syslog message
Product:	[Fedora] Fedora	Reporter:	Daniel Walsh <dwalsh>
Component:	systemd	Assignee:	systemd-maint
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	17	CC:	eparis, johannbg, lpoetter, metherid, mschmidt, notting, plautrba, pmoore, sdsmall, systemd-maint
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	systemd-44-1.fc17	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-03-21 19:10:02 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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.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.