Merge lp:~stgraber/upstart/upstart-initgroups into lp:upstart
Status: | Merged |
---|---|
Merged at revision: | 1396 |
Proposed branch: | lp:~stgraber/upstart/upstart-initgroups |
Merge into: | lp:upstart |
Diff against target: |
193 lines (+117/-3) 3 files modified
init/job_process.c (+46/-2) init/job_process.h (+3/-1) init/tests/test_job_process.c (+68/-0) |
To merge this branch: | bzr merge lp:~stgraber/upstart/upstart-initgroups |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
James Hunt | Approve | ||
Review via email: mp+136794@code.launchpad.net |
Description of the change
Call initgroups() before spawning a job to ensure that the user's group list
is properly initialized.
This avoids the following issue:
=== Example of the security problem ===
root@upstart-
setuid nobody
setgid nogroup
task
script
cat /tmp/secret-file > /tmp/public-file
chmod 666 /tmp/public-file
id > /tmp/debug
end script
root@upstart-
uid=65534(nobody) gid=65534(nogroup) groups=
root@upstart-
root@upstart-
root@upstart-
test stop/waiting
root@upstart-
secret
root@upstart-
-rw-rw-rw- 1 nobody nogroup 7 Nov 28 20:59 /tmp/public-file
root@upstart-
uid=65534(nobody) gid=65534(nogroup) groups=
root@upstart-
=== Same commands but with the fixed version ===
root@upstart-
setuid nobody
setgid nogroup
task
script
cat /tmp/secret-file > /tmp/public-file
chmod 666 /tmp/public-file
id > /tmp/debug
end script
root@upstart-
uid=65534(nobody) gid=65534(nogroup) groups=
root@upstart-
root@upstart-
root@upstart-
start: Job failed to start
root@upstart-
The code was tested (as shown above) and the unit tests still all pass.
However, as the tests are meant to be run as non-root, it's not possible
to add new tests testing for initgroups() behaviour.
So after more testing, this bug can't be exploited on regular hosts (physical machines, VMs) as the kernel group list is empty on those, so there's no "root" group to inherit.
On those, the bug is only that you don't inherit the groups of the setuid user, which is problematic but not a security issue.
However for users of containers, the initial group list does contain root, so for those, it's a potential security issue. But the number of users of containers being far lower than those of regular systems, this somewhat lowers the priority of this fix.