containers / containers/bubblewrap

Dropping Privileges

Open
#312 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
C
Stars
8.7k
Forks
386
Avg merge
3d 17h
Merged PRs (30d)
11

Description

Since bubblewrap is a suid application (on many systems), I had a look at the privilege dropping part.

Taking this as an example https://www.oreilly.com/library/view/secure-programming-cookbook/0596003943/ch01s03.html
there seem to be several things missing.

One of the differences in bubblewrap is the handling of ancillary groups

> One more issue needs to be addressed with regard to dropping privileges. In addition to the effective, real, and saved group IDs of a process, a process also has ancillary groups. Ancillary groups are inherited by a process from its parent process, and they can only be altered by a process with superuser privileges. Therefore, if a process with superuser privileges is dropping these privileges, it must also be sure to drop any ancillary groups it may have. This is achieved by calling setgroups( ) with a single group, which is the real group ID for the process. Because the setgroups( ) system call is guarded by requiring the effective user ID of the process to be that of the superuser, it must be done prior to dropping root privileges. Ancillary groups should be dropped regardless of whether privileges are being dropped permanently or temporarily. In the case of a temporary privilege drop, the process can restore the ancillary groups if necessary when elevated privileges are restored.

While I did not have the time to look at this in detail, I found several areas where bubblewrap uses setuid to drop root privileges, but does not use setreuid as is recommended.

EDIT: Actually setreuid is not the best solution, rather we should use setresuid:
http://man7.org/linux/man-pages/man2/setresuid.2.html

> On Linux and Solaris, the setgid( ) and setuid( ) system calls do not alter the process’s saved group and user IDs in all cases. (In particular, if the effective ID is not the superuser, the saved ID is not altered; otherwise, it is.). That means that these calls can’t reliably be used to permanently drop privileges. Instead, setregid( ) and setreuid( ) are used, which actually simplifies the process except that these two system calls have different semantics on the BSD-derived platforms.

More Info: https://wiki.sei.cmu.edu/confluence/display/c/POS37-C.+Ensure+that+privilege+relinquishment+is+successful

https://wiki.sei.cmu.edu/confluence/display/c/POS36-C.+Observe+correct+revocation+order+while+relinquishing+privileges

> Under normal circumstances, setuid() and related calls do not alter the supplementary group IDs. However, a setuid-root program can alter its supplementary group IDs and then relinquish root privileges, in which case, it maintains the supplementary group IDs but lacks the privilege necessary to relinquish them. Consequently, it is recommended that a program immediately relinquish supplementary group IDs before relinquishing root privileges.

Maybe someine with more inside into bubblewrap can confirm weather this is an issue or not. In any case when dropping privileges these best practices should be followed to make sure the use of suid is safe indeed.

Some more intersting information can be found in this talk:
https://media.ccc.de/v/32c3-7284-check_your_privileges

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.