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...
Alias: CVE-2013-4392
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Security
Whiteboard: ~3 [upstream cve]
Depends on:
Reported: 2016-11-23 20:58 UTC by Thomas Deutschmann (RETIRED)
Modified: 2019-04-02 05:19 UTC (History)
1 user (show)

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


Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Deutschmann (RETIRED) gentoo-dev 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 (RETIRED) gentoo-dev 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

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


> This is currently blocked by the need for new system calls (or making
> existing system calls work with O_PATH):
> 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 with aka (due to code move in you will notice that a race is still possible and that the code doesn't check for slashes or symlinks.
Comment 2 Aaron Bauman (RETIRED) gentoo-dev 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.