Hi all-
As promised (although belatedly), I wrote up some proposed documentation
for the no_new_privs feature. What should I do with it? I don't speak
groff/troff/whatever man pages are written in.
I would be happy to license this text appropriately for whatever tree
it might end up in. In the mean time, it's GPLv2+.
--- cut here ---
The execve system call can grant a newly-started program privileges
that its parent did not have. The most obvious examples are
setuid/setgid programs and file capabilities. To prevent the parent
program from gaining these privileges as well, the kernel and user
code must be careful to prevent the parent from doing anything that
could subvert the child. For example:
- The dynamic loader handles LD_* environment variables differently
if a program is setuid.
- chroot is disallowed to unprivileged processes, since it would
allow /etc/passwd to be replaced from the point of view of a process
that inherited chroot.
- The exec code has special handling for ptrace.
These are all ad-hoc fixes. The no_new_privs bit (since Linux 3.5) is
a new, generic mechanism to make it safe for a process to modify its
execution environment in a manner that persists across execve. Any
task can set no_new_privs. Once the bit is set, it is inherited
across fork, clone, and execve and cannot be unset. With no_new_privs
set, execve promises not to grant the privilege to do anything that
could not have been done without the execve call. For example, the
setuid and setgid bits will no longer change the uid or gid; file
capabilities will not add to the permitted set, and LSMs will not
relax constraints after execve.
Note that no_new_privs does not prevent privilege changes that do not
involve execve. An appropriately privileged task can still call
setuid(2) and receive SCM_RIGHTS datagrams.
There are two main use cases for no_new_privs so far:
- Filters installed for the seccomp mode 2 sandbox persist across
execve and can change the behavior of newly-executed programs.
Unprivileged users are therefore only allowed to install such filters
if no_new_privs is set.
- By itself, no_new_privs can be used to reduce the attack surface
available to an unprivileged user. If everything running with a given
uid has no_new_privs set, then that uid will be unable to escalate its
privileges by directly attacking setuid, setgid, and fcap-using
binaries; it will need to compromise something without the
no_new_privs bit set first.
In the future, other potentially dangerous kernel features could
become available to unprivileged tasks if no_new_privs is set. In
principle, several options to unshare(2) and clone(2) would be safe
when no_new_privs is set, and no_new_privs + chroot is considerable
less dangerous than chroot by itself.
--- cut here ---
--Andy
Hi,
As-is, this could probably live in
Documentation/security/no-new-privs.txt (maybe with some examples
added).
As for a manpage section, I think Michael Kerrisk would happily add a
section for PR_[SG]ET_NO_NEW_PRIVS to prctl if this could be
summarized into a paragraph or two.
(And this reminds me I should send an update for the seccomp section
in the prctl manpage too.)
-Kees
On Tue, Jun 5, 2012 at 10:04 AM, Andy Lutomirski <[email protected]> wrote:
> Hi all-
>
> As promised (although belatedly), I wrote up some proposed documentation
> for the no_new_privs feature. ?What should I do with it? ?I don't speak
> groff/troff/whatever man pages are written in.
>
> I would be happy to license this text appropriately for whatever tree
> it might end up in. ?In the mean time, it's GPLv2+.
>
> --- cut here ---
>
> The execve system call can grant a newly-started program privileges
> that its parent did not have. ?The most obvious examples are
> setuid/setgid programs and file capabilities. ?To prevent the parent
> program from gaining these privileges as well, the kernel and user
> code must be careful to prevent the parent from doing anything that
> could subvert the child. ?For example:
>
> ?- The dynamic loader handles LD_* environment variables differently
> if a program is setuid.
> ?- chroot is disallowed to unprivileged processes, since it would
> allow /etc/passwd to be replaced from the point of view of a process
> that inherited chroot.
> ?- The exec code has special handling for ptrace.
>
> These are all ad-hoc fixes. ?The no_new_privs bit (since Linux 3.5) is
> a new, generic mechanism to make it safe for a process to modify its
> execution environment in a manner that persists across execve. ?Any
> task can set no_new_privs. ?Once the bit is set, it is inherited
> across fork, clone, and execve and cannot be unset. ?With no_new_privs
> set, execve promises not to grant the privilege to do anything that
> could not have been done without the execve call. ?For example, the
> setuid and setgid bits will no longer change the uid or gid; file
> capabilities will not add to the permitted set, and LSMs will not
> relax constraints after execve.
>
> Note that no_new_privs does not prevent privilege changes that do not
> involve execve. ?An appropriately privileged task can still call
> setuid(2) and receive SCM_RIGHTS datagrams.
>
> There are two main use cases for no_new_privs so far:
>
> ?- Filters installed for the seccomp mode 2 sandbox persist across
> execve and can change the behavior of newly-executed programs.
> Unprivileged users are therefore only allowed to install such filters
> if no_new_privs is set.
>
> ?- By itself, no_new_privs can be used to reduce the attack surface
> available to an unprivileged user. ?If everything running with a given
> uid has no_new_privs set, then that uid will be unable to escalate its
> privileges by directly attacking setuid, setgid, and fcap-using
> binaries; it will need to compromise something without the
> no_new_privs bit set first.
>
> In the future, other potentially dangerous kernel features could
> become available to unprivileged tasks if no_new_privs is set. ?In
> principle, several options to unshare(2) and clone(2) would be safe
> when no_new_privs is set, and no_new_privs + chroot is considerable
> less dangerous than chroot by itself.
>
> --- cut here ---
>
> --Andy
--
Kees Cook
Chrome OS Security
On Tue, Jun 5, 2012 at 12:33 PM, Kees Cook <[email protected]> wrote:
> Hi,
>
> As-is, this could probably live in
> Documentation/security/no-new-privs.txt (maybe with some examples
> added).
Or Documentation/prctl/no-new-privs.txt
Just a decision between what it does and how you get to it, but I'd
think either would make sense!
> As for a manpage section, I think Michael Kerrisk would happily add a
> section for PR_[SG]ET_NO_NEW_PRIVS to prctl if this could be
> summarized into a paragraph or two.
>
> (And this reminds me I should send an update for the seccomp section
> in the prctl manpage too.)
Faster on the draw than me - thanks!
>
> On Tue, Jun 5, 2012 at 10:04 AM, Andy Lutomirski <[email protected]> wrote:
>> Hi all-
>>
>> As promised (although belatedly), I wrote up some proposed documentation
>> for the no_new_privs feature. ?What should I do with it? ?I don't speak
>> groff/troff/whatever man pages are written in.
>>
>> I would be happy to license this text appropriately for whatever tree
>> it might end up in. ?In the mean time, it's GPLv2+.
>>
>> --- cut here ---
>>
>> The execve system call can grant a newly-started program privileges
>> that its parent did not have. ?The most obvious examples are
>> setuid/setgid programs and file capabilities. ?To prevent the parent
>> program from gaining these privileges as well, the kernel and user
>> code must be careful to prevent the parent from doing anything that
>> could subvert the child. ?For example:
>>
>> ?- The dynamic loader handles LD_* environment variables differently
>> if a program is setuid.
>> ?- chroot is disallowed to unprivileged processes, since it would
>> allow /etc/passwd to be replaced from the point of view of a process
>> that inherited chroot.
>> ?- The exec code has special handling for ptrace.
>>
>> These are all ad-hoc fixes. ?The no_new_privs bit (since Linux 3.5) is
>> a new, generic mechanism to make it safe for a process to modify its
>> execution environment in a manner that persists across execve. ?Any
>> task can set no_new_privs. ?Once the bit is set, it is inherited
>> across fork, clone, and execve and cannot be unset. ?With no_new_privs
>> set, execve promises not to grant the privilege to do anything that
>> could not have been done without the execve call. ?For example, the
>> setuid and setgid bits will no longer change the uid or gid; file
>> capabilities will not add to the permitted set, and LSMs will not
>> relax constraints after execve.
>>
>> Note that no_new_privs does not prevent privilege changes that do not
>> involve execve. ?An appropriately privileged task can still call
>> setuid(2) and receive SCM_RIGHTS datagrams.
>>
>> There are two main use cases for no_new_privs so far:
>>
>> ?- Filters installed for the seccomp mode 2 sandbox persist across
>> execve and can change the behavior of newly-executed programs.
>> Unprivileged users are therefore only allowed to install such filters
>> if no_new_privs is set.
>>
>> ?- By itself, no_new_privs can be used to reduce the attack surface
>> available to an unprivileged user. ?If everything running with a given
>> uid has no_new_privs set, then that uid will be unable to escalate its
>> privileges by directly attacking setuid, setgid, and fcap-using
>> binaries; it will need to compromise something without the
>> no_new_privs bit set first.
>>
>> In the future, other potentially dangerous kernel features could
>> become available to unprivileged tasks if no_new_privs is set. ?In
>> principle, several options to unshare(2) and clone(2) would be safe
>> when no_new_privs is set, and no_new_privs + chroot is considerable
>> less dangerous than chroot by itself.
>>
>> --- cut here ---
>>
>> --Andy
>
>
>
> --
> Kees Cook
> Chrome OS Security
On Tue, 5 Jun 2012, Will Drewry wrote:
> Or Documentation/prctl/no-new-privs.txt
>
> Just a decision between what it does and how you get to it, but I'd
> think either would make sense!
This makes sense as it's where the seccomp documentation is.
- James
--
James Morris
<[email protected]>