Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 600624 (CVE-2013-4392) - sys-apps/systemd: TOCTOU race condition when updating file permissions and SELinux security contexts
Summary: sys-apps/systemd: TOCTOU race condition when updating file permissions and SE...
Status: IN_PROGRESS
Alias: CVE-2013-4392
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Security
URL: https://bugzilla.redhat.com/show_bug....
Whiteboard: ~3 [upstream cve]
Keywords:
Depends on:
Blocks:
 
Reported: 2016-11-23 20:58 UTC by Thomas Deutschmann
Modified: 2019-04-02 05:19 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Deutschmann gentoo-dev Security 2016-11-23 20:58:05 UTC
A TOCTOU (time-of-check time-of-use) race condition was found in the way systemd, a system and service manager, used to update file permissions and SELinux security contexts. A local attacker could use this flaw to conduct symbolic link attacks possibly leading to their ability to modify permissions / security context of a path different than originally intended / requested.

Issue found by Florian Weimer, Red Hat Product Security Team
Comment 1 Thomas Deutschmann gentoo-dev Security 2016-11-23 21:08:31 UTC
This only affects setups using SELinux. 

Looks like a design issue which won't be resolved very soon. From https://bugzilla.redhat.com/show_bug.cgi?id=858760#c0:

> shared/label.c:label_fix() does not prevent symlink resolution on the
> path name.  The function should check if the path name contains slashes
> and refuse to proceed in this case.  I think such a drastic measure is
> warranted because by design, this function works on files in other users'
> directories, and is subject to path name races. (There is not fsetxattrat
> interface in the kernel, so fchdir followed by lsetxattr/lsetfilecon is
> the only safe alternative.  Obviously, this is not thread-safe.)

From https://bugzilla.redhat.com/show_bug.cgi?id=859060#c11:

> This is currently blocked by the need for new system calls (or making
> existing system calls work with O_PATH):
> 
> http://article.gmane.org/gmane.linux.file-systems/82821
> 
> We need to open files to check their hard link count and make sure that
> is not greater than 1, so that we do not improperly relabel a file that
> is visible elsewhere in the file system.  Without O_PATH, the open
> operation can have side effects, so we would introduce another type of
> security bug.
> 
> Addressing this would also fix the other issue (lsetfilecon is called
> with absolute paths, which does not prevent symbol link resolution on
> non-final path components), but this issue could be fixed separate if
> desired.


This was first reported in bug 486904.

If you compare the criticized code from https://github.com/systemd/systemd/blob/v208/src/shared/label.c#L93-L136 with https://github.com/systemd/systemd/blob/331d6a201b82a03c5343bb9c25280f0cd8b7d9fb/src/basic/label.c#L29-L41 aka https://github.com/systemd/systemd/blob/331d6a201b82a03c5343bb9c25280f0cd8b7d9fb/src/basic/selinux-util.c#L83-L119 (due to code move in https://github.com/systemd/systemd/commit/a095315b3c31f7a419baceac82c26c3c5ac0cd12) you will notice that a race is still possible and that the code doesn't check for slashes or symlinks.
Comment 2 Aaron Bauman Gentoo Infrastructure gentoo-dev Security 2019-03-29 01:54:07 UTC
Marking this as unstable considering systemd is masked for SELinux profiles. Thus, it is not a stable profile or configuration.