capabilities: Ambient capabilities
Subsystems (6)
v2 cover capabilities: Ambient capabilities
This adds ambient capabilities. See the individual patch changelogs for details.
Preliminary userspace code is here:
I'll follow up with a rough draft of a man-pages patch.
Changes from v1:
- Lots of cleanups to the ambient cap code.
- The securebit is new.
Andy Lutomirski (2):
capabilities: Ambient capabilities
capabilities: Add a securebit to disable PR_CAP_AMBIENT_RAISE
fs/proc/array.c | 5 ++- include/linux/cred.h | 8 ++++ include/uapi/linux/prctl.h | 6 +++ include/uapi/linux/securebits.h | 11 +++++- kernel/user_namespace.c | 1 + security/commoncap.c | 88 ++++++++++++++++++++++++++++++++++++----- security/keys/process_keys.c | 1 + 7 files changed, 108 insertions(+), 12 deletions(-)
Signature · 1 line
2.1.0
PATCH v2 1/2 capabilities: Ambient capabilities
Credit where credit is due: this idea comes from Christoph Lameter with a lot of valuable input from Serge Hallyn. This patch is heavily based on Christoph's patch.
===== The status quo =====
On Linux, there are a number of capabilities defined by the kernel. To perform various privileged tasks, processes can wield capabilities that they hold.
Each task has four capability masks: effective (pE), permitted (pP), inheritable (pI), and a bounding set (X). When the kernel checks for a capability, it checks pE. The other capability masks serve to modify what capabilities can be in pE.
Any task can remove capabilities from pE, pP, or pI at any time. If a task has a capability in pP, it can add that capability to pE and/or pI. If a task has CAP_SETPCAP, then it can add any capability to pI, and it can remove capabilities from X.
Tasks are not the only things that can have capabilities; files can also have capabilities. A file can have no capabilty information at all [1]. If a file has capability information, then it has a permitted mask (fP) and an inheritable mask (fI) as well as a single effective bit (fE) [2]. File capabilities modify the capabilities of tasks that execve(2) them.
A task that successfully calls execve has its capabilities modified for the file ultimately being excecuted (i.e. the binary itself if that binary is ELF or for the interpreter if the binary is a script.) [3] In the capability evolution rules, for each mask Z, pZ represents the old value and pZ' represents the new value. The rules are:
pP' = (X & fP) | (pI & fI)
pI' = pI
pE' = (fE ? pP' : 0)
X is unchanged
For setuid binaries, fP, fI, and fE are modified by a moderately complicated set of rules that emulate POSIX behavior. Similarly, if euid == 0 or ruid == 0, then fP, fI, and fE are modified differently (primary, fP and fI usually end up being the full set). For nonroot users executing binaries with neither setuid nor file caps, fI and fP are empty and fE is false.
As an extra complication, if you execute a process as nonroot and fE is set, then the "secure exec" rules are in effect: AT_SECURE gets set, LD_PRELOAD doesn't work, etc.
This is rather messy. We've learned that making any changes is dangerous, though: if a new kernel version allows an unprivileged program to change its security state in a way that persists cross execution of a setuid program or a program with file caps, this persistent state is surprisingly likely to allow setuid or file-capped programs to be exploited for privilege escalation.
===== The problem =====
Capability inheritance is basically useless.
If you aren't root and you execute an ordinary binary, fI is zero, so your capabilities have no effect whatsoever on pP'. This means that you can't usefully execute a helper process or a shell command with elevated capabilities if you aren't root.
On current kernels, you can sort of work around this by setting fI to the full set for most or all non-setuid executable files. This causes pP' = pI for nonroot, and inheritance works. No one does this because it's a PITA and it isn't even supported on most filesystems.
If you try this, you'll discover that every nonroot program ends up with secure exec rules, breaking many things.
This is a problem that has bitten many people who have tried to use capabilities for anything useful.
===== The proposed change =====
This patch adds a fifth capability mask called the ambient mask (pA). pA does what pI should have done.
pA obeys the invariant that no bit can ever be set in pA if it is not set in both pP and pI. Dropping a bit from pP or pI drops that bit from pA. This ensures that existing programs that try to drop capabilities still do so, with a complication. Because capability inheritance is so broken, setting KEEPCAPS, using setresuid to switch to nonroot uids, or calling execve effectively drops capabilities. Therefore, setresuid from root to nonroot conditionally clears pA unless SECBIT_NO_SETUID_FIXUP is set. Processes that don't like this can re-add bits to pA afterwards.
The capability evolution rules are changed:
pA' = (file caps or setuid or setgid ? 0 : pA)
pP' = (X & fP) | (pI & fI) | pA'
pI' = pI
pE' = (fE ? pP' : pA')
X is unchanged
If you are nonroot but you have a capability, you can add it to pA. If you do so, your children get that capability in pA, pP, and pE. For example, you can set pA = CAP_NET_BIND_SERVICE, and your children can automatically bind low-numbered ports. Hallelujah!
Unprivileged users can create user namespaces, map themselves to a nonzero uid, and create both privileged (relative to their namespace) and unprivileged process trees. This is currently more or less impossible. Hallelujah!
You cannot use pA to try to subvert a setuid, setgid, or file-capped
program: if you execute any such program, pA gets cleared and the resulting evolution rules are unchanged by this patch.
Users with nonzero pA are unlikely to unintentionally leak that capability. If they run programs that try to drop privileges, dropping privileges will still work.
It's worth noting that the degree of paranoia in this patch could possibly be reduced without causing serious problems. Specifically, if we allowed pA to persist across executing non-pA-aware setuid binaries and across setresuid, then, naively, the only capabilities that could leak as a result would be the capabilities in pA, and any attacker *already* has those capabilities. This would make me nervous, though -- setuid binaries that tried to privilege-separate might fail to do so, and putting CAP_DAC_READ_SEARCH or CAP_DAC_OVERRIDE into pA could have unexpected side effects. (Whether these unexpected side effects would be exploitable is an open question.) I've therefore taken the more paranoid route.
An alternative would be to require PR_SET_NO_NEW_PRIVS before setting ambient capabilities. I think that this would be annoying and would make granting otherwise unprivileged users minor ambient capabilities (CAP_NET_BIND_SERVICE or CAP_NET_RAW for example) much less useful than it is with this patch.
===== Footnotes =====
[1] Files that are missing the "security.capability" xattr or that have unrecognized values for that xattr end up with has_cap set to false. The code that does that appears to be complicated for no good reason.
[2] The libcap capability mask parsers and formatters are dangerously misleading and the documentation is flat-out wrong. fE is *not* a mask; it's a single bit. This has probably confused every single person who has tried to use file capabilities.
[3] Linux very confusingly processes both the script and the interpreter if applicable, for reasons that elude me. The results from thinking about a script's file capabilities and/or setuid bits are mostly discarded.
--- fs/proc/array.c | 5 ++- include/linux/cred.h | 8 ++++ include/uapi/linux/prctl.h | 6 +++ kernel/user_namespace.c | 1 + security/commoncap.c | 87 +++++++++++++++++++++++++++++++++++++++----- security/keys/process_keys.c | 1 + 6 files changed, 97 insertions(+), 11 deletions(-)
fs/proc/array.c +4 -1
@@ -282,7 +282,8 @@ static void render_cap_t(struct seq_file *m, const char *header,static inline void task_cap (struct seq_file *m,struct task_struct *p) {const struct cred *cred; -kernel_cap_t cap_inheritable, cap_permitted, cap_effective, cap_bset; +kernel_cap_t cap_inheritable, cap_permitted, cap_effective, + cap_bset, cap_ambient;rcu_read_lock (); cred =__task_cred (p);
@@ -290,12 +291,14 @@ static inline void task_cap(struct seq_file *m, struct task_struct *p) cap_permitted = cred->cap_permitted; cap_effective = cred->cap_effective; cap_bset = cred->cap_bset; + cap_ambient = cred->cap_ambient;rcu_read_unlock ();render_cap_t (m,"CapInh:\t" , &cap_inheritable);render_cap_t (m,"CapPrm:\t" , &cap_permitted);render_cap_t (m,"CapEff:\t" , &cap_effective);render_cap_t (m,"CapBnd:\t" , &cap_bset); +render_cap_t (m,"CapAmb:\t" , &cap_ambient); }static inline void task_seccomp (struct seq_file *m,struct task_struct *p)
include/linux/cred.h +8 -0
@@ -122,6 +122,7 @@ struct cred {kernel_cap_t cap_permitted;/* caps we're permitted */ kernel_cap_t cap_effective;/* caps we can actually use */ kernel_cap_t cap_bset;/* capability bounding set */ +kernel_cap_t cap_ambient;/* Ambient capability set */ #ifdef CONFIG_KEYS unsigned char jit_keyring;/* default keyring to attach requested * keys to */
@@ -197,6 +198,13 @@ static inline void validate_process_creds(void) }#endif +static inline bool cap_ambient_invariant_ok (const struct cred *cred) +{ +return cap_issubset (cred->cap_ambient, +cap_intersect (cred->cap_permitted, + cred->cap_inheritable)); +} +/** * get_new_cred - Get a reference on a new set of credentials * @cred: The new credentials to reference
include/uapi/linux/prctl.h +6 -0
@@ -190,4 +190,10 @@ struct prctl_mm_map {# define PR_FP_MODE_FR (1 << 0)/* 64b FP registers */ # define PR_FP_MODE_FRE (1 << 1)/* 32b compatibility */ +/* Control the ambient capability set */ +#define PR_CAP_AMBIENT 47 +# define PR_CAP_AMBIENT_GET 1 +# define PR_CAP_AMBIENT_RAISE 2 +# define PR_CAP_AMBIENT_LOWER 3 +#endif /* _LINUX_PRCTL_H */
kernel/user_namespace.c +1 -0
@@ -39,6 +39,7 @@ static void set_cred_user_ns(struct cred *cred, struct user_namespace *user_ns) cred->cap_inheritable =CAP_EMPTY_SET ; cred->cap_permitted =CAP_FULL_SET ; cred->cap_effective =CAP_FULL_SET ; + cred->cap_ambient =CAP_EMPTY_SET ; cred->cap_bset =CAP_FULL_SET ;#ifdef CONFIG_KEYS key_put (cred->request_key_auth);
security/commoncap.c +77 -10
153 lines not on this page · raw message
security/keys/process_keys.c +1 -0
@@ -848,6 +848,7 @@ void key_change_session_keyring(struct callback_head *twork) new->cap_inheritable = old->cap_inheritable; new->cap_permitted = old->cap_permitted; new->cap_effective = old->cap_effective; + new->cap_ambient = old->cap_ambient; new->cap_bset = old->cap_bset; new->jit_keyring = old->jit_keyring;
Signature · 1 line
2.1.0
Quoted 6 lines · Andy Lutomirski
security/commoncap.c +0
-2@@ -696,10 +729,18 @@ static inline void cap_emulate_setxuid(struct cred *new, const struct cred *old) uid_eq(old->suid, root_uid)) && (!uid_eq(new->uid, root_uid) && !uid_eq(new->euid, root_uid) && - !uid_eq (new->suid, root_uid)) && - !issecure(SECURE_KEEP_CAPS)) {
security/commoncap.c static inline void cap_emulate_setxuid(struct cred *new, const struct cred *old) · line 739
Quoted 10 lines
security/commoncap.c +8
-2-cap_clear (new->cap_permitted); -cap_clear (new->cap_effective); + !uid_eq(new->suid, root_uid))) { +if (!issecure (SECURE_KEEP_CAPS )) { +cap_clear (new->cap_permitted); +cap_clear (new->cap_effective); + } + +/* +* Pre-ambient programs except setresuid to nonroot followed
I think you meant "expect". This typo changes the meaning of the sentence.
Quoted 5 lines
security/commoncap.c +4
-0+* by exec to drop capabilities. We should make sure that +* this remains the case. +*/ +cap_clear (new->cap_ambient); }
Signature · 1 line
Lukasz Pawelczyk
Quoted 12 lines · Lukasz Pawelczyk
Quoted 11 lines · Andy Lutomirski
security/commoncap.c +3
-4@@ -696,10 +729,18 @@ static inline void cap_emulate_setxuid(struct cred *new, const struct cred *old) uid_eq(old->suid, root_uid)) && (!uid_eq(new->uid, root_uid) && !uid_eq(new->euid, root_uid) && - !uid_eq(new->suid, root_uid)) && - !issecure(SECURE_KEEP_CAPS)) { -cap_clear (new->cap_permitted); -cap_clear (new->cap_effective); + !uid_eq(new->suid, root_uid))) { +if (!issecure (SECURE_KEEP_CAPS )) { +cap_clear (new->cap_permitted);
Quoted 8 lines
security/commoncap.c static inline void cap_emulate_setxuid(struct cred *new, const struct cred *old) · line 739
Quoted 5 lines
security/commoncap.c +5
-0+cap_clear (new->cap_effective); + } + +/* +* Pre-ambient programs except setresuid to nonroot followed I think you meant "expect". This typo changes the meaning of the sentence.
Good catch. I'll fix that for v3.
--Andy
Quoted 1 line · Andy Lutomirski
Cc Christoph Lameter <[email protected]>
This is partially my code it seems. So there should be a
here.
Could you provide an example to demonstrate how it is to be used? Something similar to what I had in my patch?
Quoted 4 lines · Christoph Lameter
Quoted 1 line · Andy Lutomirski
Cc Christoph Lameter <[email protected]>
Quoted 9 lines
This is partially my code it seems. So there should be a
Signed-off-by Christoph Lameter <[email protected]>here.
Could you provide an example to demonstrate how it is to be used? Something similar to what I had in my patch?
Do you mean something like:
setpriv --ambient-caps=+net_bind_service --inh-haps=+net_bind_service --euid=500 --ruid=500 bash
--Andy
Signature · 2 lines
Andy Lutomirski AMA Capital Management, LLC
Quoted 8 lines · Andy Lutomirski
Quoted 3 lines
Could you provide an example to demonstrate how it is to be used? Something similar to what I had in my patch?
Do you mean something like:
setpriv --ambient-caps=+net_bind_service --inh-haps=+net_bind_service --euid=500 --ruid=500 bash
Ok that means we also depend on a tool upgrade.
Quoted 7 lines · Christoph Lameter
Quoted 4 lines · Andy Lutomirski
Quoted 3 lines
Could you provide an example to demonstrate how it is to be used? Something similar to what I had in my patch?
Quoted 7 lines
Quoted 4 lines
Do you mean something like:
setpriv --ambient-caps=+net_bind_service --inh-haps=+net_bind_service --euid=500 --ruid=500 bash
Ok that means we also depend on a tool upgrade.
I think this is unavoidable, unless we want to change the semantics of inheritable caps, and that would open a giant can of worms.
--Andy
Quoted 10 lines · Andy Lutomirski
Quoted 9 lines · Christoph Lameter
Quoted 6 lines · Andy Lutomirski
Quoted 3 lines
Could you provide an example to demonstrate how it is to be used? Something similar to what I had in my patch?
Do you mean something like:
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
setpriv --ambient-caps=+net_bind_service --inh-haps=+net_bind_service --euid=500 --ruid=500 bash
Ok that means we also depend on a tool upgrade.
I think this is unavoidable, unless we want to change the semantics of inheritable caps, and that would open a giant can of worms.
Ok then include a patch and references to that material. Or did I just not see that?
Quoted 15 lines · Christoph Lameter
Quoted 13 lines · Andy Lutomirski
Quoted 12 lines · Christoph Lameter
Quoted 8 lines · Andy Lutomirski
Quoted 3 lines
Could you provide an example to demonstrate how it is to be used? Something similar to what I had in my patch?
Do you mean something like:
setpriv --ambient-caps=+net_bind_service --inh-haps=+net_bind_service --euid=500 --ruid=500 bash
Quoted 9 lines
Quoted 5 lines
Quoted 2 lines
Ok that means we also depend on a tool upgrade.
I think this is unavoidable, unless we want to change the semantics of inheritable caps, and that would open a giant can of worms.
Ok then include a patch and references to that material. Or did I just not see that?
It's in the cover letter, rather vaguely. I think I want to change the setpriv syntax a bit before sending it upstream, though -- it's sucks that you have to duplicate the option.
Perhaps the ambient-caps option should implicitly raise inheritable caps if they're not already raised. Or maybe the absence of an inh-caps rule should cause any requested ambient caps to be made inheritable as well.
--Andy
On 19/05/15 20:07, Andy Lutomirski wrote:> It's in the cover letter, rather vaguely. I think I want to change
Quoted 9 lines
the setpriv syntax a bit before sending it upstream, though -- it's sucks that you have to duplicate the option.
Perhaps the ambient-caps option should implicitly raise inheritable caps if they're not already raised. Or maybe the absence of an inh-caps rule should cause any requested ambient caps to be made inheritable as well.
--Andy
I propose an additional --ambient-inh option to copy everything from --inh-caps to the ambient set. Explicit is better than implicit.
Signature · 1 line
Aaron Jones
Quoted 10 lines · Aaron Jones
On 19/05/15 20:07, Andy Lutomirski wrote:> It's in the cover letter, rather vaguely. I think I want to change
Quoted 8 lines
the setpriv syntax a bit before sending it upstream, though -- it's sucks that you have to duplicate the option.
Perhaps the ambient-caps option should implicitly raise inheritable caps if they're not already raised. Or maybe the absence of an inh-caps rule should cause any requested ambient caps to be made inheritable as well.
Quoted 4 lines
Quoted 1 line
--Andy
I propose an additional --ambient-inh option to copy everything from --inh-caps to the ambient set. Explicit is better than implicit.
Seems reasonable. I'll do something like that for v2.1.
--Andy
It would be best to start a complete new thread about this. You replied to earlier posts about ambient capabilities and people may not see it as a new release.
Quoted 4 lines
pA obeys the invariant that no bit can ever be set in pA if it is not set in both pP and pI. Dropping a bit from pP or pI drops that bit from pA. This ensures that existing programs that try to drop capabilities still do so, with a complication. Because capability
Ok that is a good improvement.
Quoted 6 lines
inheritance is so broken, setting KEEPCAPS, using setresuid to switch to nonroot uids, or calling execve effectively drops capabilities. Therefore, setresuid from root to nonroot conditionally clears pA unless
SECBIT_NO_SETUID_FIXUPis set. Processes that don't like this can re-add bits to pA afterwards.
Quoted 6 lines
The capability evolution rules are changed:
pA' = (file caps or setuid or setgid ? 0 : pA)
pP' = (X & fP) | (pI & fI) | pA'
pI' = pI
pE' = (fE ? pP' : pA')
Isnt this equal to
pE' = (fE & pP') | pA'
which does not require conditionals and is symmetric to how pP' is calculated. Your formula seems to indicate that pA' bits are not set if fE is set. However they are already set unconditionally in pP' regardless. This makes it more explicit I think. And I thought we are dealing with bitmask arithmetic here?
Quoted 4 lines
If you are nonroot but you have a capability, you can add it to pA. If you do so, your children get that capability in pA, pP, and pE. For example, you can set pA =
CAP_NET_BIND_SERVICE, and your children can automatically bind low-numbered ports. Hallelujah!
I love this solution.
Quoted 4 lines
[2] The libcap capability mask parsers and formatters are dangerously misleading and the documentation is flat-out wrong. fE is *not* a mask; it's a single bit. This has probably confused every single person who has tried to use file capabilities.
Hmmm... yes lets clean that up as well. Then your formula makes sense.
Quoted 27 lines · Christoph Lameter
It would be best to start a complete new thread about this. You replied to earlier posts about ambient capabilities and people may not see it as a new release.
Quoted 4 lines
pA obeys the invariant that no bit can ever be set in pA if it is not set in both pP and pI. Dropping a bit from pP or pI drops that bit from pA. This ensures that existing programs that try to drop capabilities still do so, with a complication. Because capability
Ok that is a good improvement.
Quoted 6 lines
inheritance is so broken, setting KEEPCAPS, using setresuid to switch to nonroot uids, or calling execve effectively drops capabilities. Therefore, setresuid from root to nonroot conditionally clears pA unless
SECBIT_NO_SETUID_FIXUPis set. Processes that don't like this can re-add bits to pA afterwards.Quoted 6 lines
The capability evolution rules are changed:
pA' = (file caps or setuid or setgid ? 0 : pA)
pP' = (X & fP) | (pI & fI) | pA'
pI' = pI
pE' = (fE ? pP' : pA')Isnt this equal to
Quoted 7 lines
pE' = (fE & pP') | pA'which does not require conditionals and is symmetric to how pP' is calculated. Your formula seems to indicate that pA' bits are not set if fE is set. However they are already set unconditionally in pP' regardless. This makes it more explicit I think. And I thought we are dealing with bitmask arithmetic here?
I think you're right, except that fE is a Boolean, not a bit mask, so fE | pP' is an odd thing to talk about.
We could say (fE ? pP' : 0) | pA', which could simplify the code a tiny bit.
Quoted 7 lines
Quoted 6 lines
If you are nonroot but you have a capability, you can add it to pA. If you do so, your children get that capability in pA, pP, and pE. For example, you can set pA =
CAP_NET_BIND_SERVICE, and your children can automatically bind low-numbered ports. Hallelujah!
Quoted 9 lines
I love this solution.
Quoted 4 lines
[2] The libcap capability mask parsers and formatters are dangerously misleading and the documentation is flat-out wrong. fE is *not* a mask; it's a single bit. This has probably confused every single person who has tried to use file capabilities.
Hmmm... yes lets clean that up as well. Then your formula makes sense.
Maybe a follow-up patch to change the docs would be a good idea.
--Andy
Quoted 36 lines · Andy Lutomirski
Quoted 27 lines · Christoph Lameter
It would be best to start a complete new thread about this. You replied to earlier posts about ambient capabilities and people may not see it as a new release.
Quoted 4 lines
pA obeys the invariant that no bit can ever be set in pA if it is not set in both pP and pI. Dropping a bit from pP or pI drops that bit from pA. This ensures that existing programs that try to drop capabilities still do so, with a complication. Because capability
Ok that is a good improvement.
Quoted 6 lines
inheritance is so broken, setting KEEPCAPS, using setresuid to switch to nonroot uids, or calling execve effectively drops capabilities. Therefore, setresuid from root to nonroot conditionally clears pA unless
SECBIT_NO_SETUID_FIXUPis set. Processes that don't like this can re-add bits to pA afterwards.Quoted 6 lines
The capability evolution rules are changed:
pA' = (file caps or setuid or setgid ? 0 : pA)
pP' = (X & fP) | (pI & fI) | pA'
pI' = pI
pE' = (fE ? pP' : pA')Isnt this equal to
Quoted 7 lines
pE' = (fE & pP') | pA'which does not require conditionals and is symmetric to how pP' is calculated. Your formula seems to indicate that pA' bits are not set if fE is set. However they are already set unconditionally in pP' regardless. This makes it more explicit I think. And I thought we are dealing with bitmask arithmetic here?
Quoted 4 lines
I think you're right, except that fE is a Boolean, not a bit mask, so fE | pP' is an odd thing to talk about.
We could say (fE ? pP' : 0) | pA', which could simplify the code a tiny bit.
It turns out that would be almost a pure addition of code, so I'll leave it as is.
--Andy
Thanks very much, Andy. Comments and ack below.
Quoted 66 lines · Andy Lutomirski
Credit where credit is due: this idea comes from Christoph Lameter with a lot of valuable input from Serge Hallyn. This patch is heavily based on Christoph's patch.
===== The status quo =====
On Linux, there are a number of capabilities defined by the kernel. To perform various privileged tasks, processes can wield capabilities that they hold.
Each task has four capability masks: effective (pE), permitted (pP), inheritable (pI), and a bounding set (X). When the kernel checks for a capability, it checks pE. The other capability masks serve to modify what capabilities can be in pE.
Any task can remove capabilities from pE, pP, or pI at any time. If a task has a capability in pP, it can add that capability to pE and/or pI. If a task has
CAP_SETPCAP, then it can add any capability to pI, and it can remove capabilities from X.Tasks are not the only things that can have capabilities; files can also have capabilities. A file can have no capabilty information at all [1]. If a file has capability information, then it has a permitted mask (fP) and an inheritable mask (fI) as well as a single effective bit (fE) [2]. File capabilities modify the capabilities of tasks that execve(2) them.
A task that successfully calls execve has its capabilities modified for the file ultimately being excecuted (i.e. the binary itself if that binary is ELF or for the interpreter if the binary is a script.) [3] In the capability evolution rules, for each mask Z, pZ represents the old value and pZ' represents the new value. The rules are:
pP' = (X & fP) | (pI & fI)
pI' = pI
pE' = (fE ? pP' : 0)
X is unchangedFor setuid binaries, fP, fI, and fE are modified by a moderately complicated set of rules that emulate POSIX behavior. Similarly, if euid == 0 or ruid == 0, then fP, fI, and fE are modified differently (primary, fP and fI usually end up being the full set). For nonroot users executing binaries with neither setuid nor file caps, fI and fP are empty and fE is false.
As an extra complication, if you execute a process as nonroot and fE is set, then the "secure exec" rules are in effect:
AT_SECUREgets set,LD_PRELOADdoesn't work, etc.This is rather messy. We've learned that making any changes is dangerous, though: if a new kernel version allows an unprivileged program to change its security state in a way that persists cross execution of a setuid program or a program with file caps, this persistent state is surprisingly likely to allow setuid or file-capped programs to be exploited for privilege escalation.
===== The problem =====
Capability inheritance is basically useless.
If you aren't root and you execute an ordinary binary, fI is zero, so your capabilities have no effect whatsoever on pP'. This means that you can't usefully execute a helper process or a shell command with elevated capabilities if you aren't root.
Quoted 8 lines
On current kernels, you can sort of work around this by setting fI to the full set for most or all non-setuid executable files. This causes pP' = pI for nonroot, and inheritance works. No one does this because it's a PITA and it isn't even supported on most filesystems.
If you try this, you'll discover that every nonroot program ends up with secure exec rules, breaking many things.
PI would have worked great if most programs wanting privilege were self-contained and compiled. Shell scripts and lots of fork+execing make pI [much less useful] [completely useless]. See also golang's predisposition to fork+exec.
Quoted 7 lines
This is a problem that has bitten many people who have tried to use capabilities for anything useful.
===== The proposed change =====
This patch adds a fifth capability mask called the ambient mask (pA). pA does what pI should have done.
Or at least what most people want it to do.
Quoted 5 lines
pA obeys the invariant that no bit can ever be set in pA if it is not set in both pP and pI. Dropping a bit from pP or pI drops that bit from pA. This ensures that existing programs that try to drop capabilities still do so, with a complication. Because capability inheritance is so broken, setting KEEPCAPS, using setresuid to
Sorry, did you mean "... setting KEEPCAPS and then either using setresuid to a nonroot uid or calling execve ..." ?
Quoted 18 lines
switch to nonroot uids, or calling execve effectively drops capabilities. Therefore, setresuid from root to nonroot conditionally clears pA unless
SECBIT_NO_SETUID_FIXUPis set. Processes that don't like this can re-add bits to pA afterwards.The capability evolution rules are changed:
pA' = (file caps or setuid or setgid ? 0 : pA)
pP' = (X & fP) | (pI & fI) | pA'
pI' = pI
pE' = (fE ? pP' : pA')
X is unchangedIf you are nonroot but you have a capability, you can add it to pA. If you do so, your children get that capability in pA, pP, and pE. For example, you can set pA =
CAP_NET_BIND_SERVICE, and your children can automatically bind low-numbered ports. Hallelujah!
Quoted 8 lines
Unprivileged users can create user namespaces, map themselves to a nonzero uid, and create both privileged (relative to their namespace) and unprivileged process trees. This is currently more or less impossible. Hallelujah!
You cannot use pA to try to subvert a setuid, setgid, or file-capped
program: if you execute any such program, pA gets cleared and the resulting evolution rules are unchanged by this patch.
Christoph, just to be sure, is this ^ going to suffice for you?
Seems like it should since any program which is setuid-root, i.e. passwd, isn't likely to be designed to exec other programs.
Quoted 4 lines
Users with nonzero pA are unlikely to unintentionally leak that capability. If they run programs that try to drop privileges, dropping privileges will still work.
Quoted 11 lines
It's worth noting that the degree of paranoia in this patch could possibly be reduced without causing serious problems. Specifically, if we allowed pA to persist across executing non-pA-aware setuid binaries and across setresuid, then, naively, the only capabilities that could leak as a result would be the capabilities in pA, and any attacker *already* has those capabilities. This would make me nervous, though -- setuid binaries that tried to privilege-separate might fail to do so, and putting
CAP_DAC_READ_SEARCHorCAP_DAC_OVERRIDEinto pA could have unexpected side effects. (Whether these unexpected side effects would be exploitable is an open question.) I've therefore taken the more paranoid route.
I'm definitely open to revisiting this question after the current patch has been in use for awhile.
Quoted 18 lines
An alternative would be to require
PR_SET_NO_NEW_PRIVSbefore setting ambient capabilities. I think that this would be annoying and would make granting otherwise unprivileged users minor ambient capabilities (CAP_NET_BIND_SERVICEorCAP_NET_RAWfor example) much less useful than it is with this patch.===== Footnotes =====
[1] Files that are missing the "security.capability" xattr or that have unrecognized values for that xattr end up with
has_capset to false. The code that does that appears to be complicated for no good reason.[2] The libcap capability mask parsers and formatters are dangerously misleading and the documentation is flat-out wrong. fE is *not* a mask; it's a single bit. This has probably confused every single person who has tried to use file capabilities.
Quoted 4 lines
[3] Linux very confusingly processes both the script and the interpreter if applicable, for reasons that elude me. The results from thinking about a script's file capabilities and/or setuid bits are mostly discarded.
Not quite sure what you mean here - setuid and fX are ignored on shell scripts, but I think you're saying something less simple is going on?
Quoted 10 lines
Cc Kees Cook <[email protected]>Cc Christoph Lameter <[email protected]>Cc Serge Hallyn <[email protected]>Cc Andy Lutomirski <[email protected]>Cc Jonathan Corbet <[email protected]>Cc Aaron Jones <[email protected]>CC Ted Ts'o <[email protected]>
Quoted 8 lines
Cc Andrew G. Morgan <[email protected]>Cc Mimi Zohar <[email protected]>Cc Austin S Hemmelgarn <[email protected]>Cc Markku Savela <msa-kXoF896ld44xHbG02/[email protected]>Cc Jarkko Sakkinen <jarkko.sakkinen-VuQAYsv1563Yd54FQh9/[email protected]>Cc Michael Kerrisk <[email protected]>Signed-off-by Andy Lutomirski <[email protected]>
Quoted 98 lines
--- fs/proc/array.c | 5 ++- include/linux/cred.h | 8 ++++ include/uapi/linux/prctl.h | 6 +++ kernel/user_namespace.c | 1 + security/commoncap.c | 87 +++++++++++++++++++++++++++++++++++++++----- security/keys/process_keys.c | 1 + 6 files changed, 97 insertions(+), 11 deletions(-)fs/proc/array.c +4
-1@@ -282,7 +282,8 @@ static void render_cap_t(struct seq_file *m, const char *header,static inline void task_cap (struct seq_file *m,struct task_struct *p) {const struct cred *cred; -kernel_cap_t cap_inheritable, cap_permitted, cap_effective, cap_bset; +kernel_cap_t cap_inheritable, cap_permitted, cap_effective, + cap_bset, cap_ambient;rcu_read_lock (); cred =__task_cred (p);@@ -290,12 +291,14 @@ static inline void task_cap(struct seq_file *m, struct task_struct *p) cap_permitted = cred->cap_permitted; cap_effective = cred->cap_effective; cap_bset = cred->cap_bset; + cap_ambient = cred->cap_ambient;rcu_read_unlock ();render_cap_t (m,"CapInh:\t" , &cap_inheritable);render_cap_t (m,"CapPrm:\t" , &cap_permitted);render_cap_t (m,"CapEff:\t" , &cap_effective);render_cap_t (m,"CapBnd:\t" , &cap_bset); +render_cap_t (m,"CapAmb:\t" , &cap_ambient); }static inline void task_seccomp (struct seq_file *m,struct task_struct *p)include/linux/cred.h +8
-0@@ -122,6 +122,7 @@ struct cred {kernel_cap_t cap_permitted;/* caps we're permitted */ kernel_cap_t cap_effective;/* caps we can actually use */ kernel_cap_t cap_bset;/* capability bounding set */ +kernel_cap_t cap_ambient;/* Ambient capability set */ #ifdef CONFIG_KEYS unsigned char jit_keyring;/* default keyring to attach requested * keys to */ @@ -197,6 +198,13 @@ static inline void validate_process_creds(void) }#endif +static inline bool cap_ambient_invariant_ok (const struct cred *cred) +{ +return cap_issubset (cred->cap_ambient, +cap_intersect (cred->cap_permitted, + cred->cap_inheritable)); +} +/** * get_new_cred - Get a reference on a new set of credentials * @cred: The new credentials to reference include/uapi/linux/prctl.h +6
-0@@ -190,4 +190,10 @@ struct prctl_mm_map {# define PR_FP_MODE_FR (1 << 0)/* 64b FP registers */ # define PR_FP_MODE_FRE (1 << 1)/* 32b compatibility */ +/* Control the ambient capability set */ +#define PR_CAP_AMBIENT 47 +# define PR_CAP_AMBIENT_GET 1 +# define PR_CAP_AMBIENT_RAISE 2 +# define PR_CAP_AMBIENT_LOWER 3 +#endif /* _LINUX_PRCTL_H */ kernel/user_namespace.c +1
-0@@ -39,6 +39,7 @@ static void set_cred_user_ns(struct cred *cred, struct user_namespace *user_ns) cred->cap_inheritable =CAP_EMPTY_SET ; cred->cap_permitted =CAP_FULL_SET ; cred->cap_effective =CAP_FULL_SET ; + cred->cap_ambient =CAP_EMPTY_SET ; cred->cap_bset =CAP_FULL_SET ;#ifdef CONFIG_KEYS key_put (cred->request_key_auth);security/commoncap.c +0
-0@@ -272,6 +272,16 @@ int cap_capset(struct cred *new, new->cap_effective = *effective; new->cap_inheritable = *inheritable;
security/commoncap.c int cap_capset(struct cred *new, · line 283
Quoted 10 lines
security/commoncap.c +9
-0new->cap_permitted = *permitted; + +/* +* Mask off ambient bits that are no longer both permitted and +* inheritable. +*/ + new->cap_ambient =cap_intersect (new->cap_ambient, +cap_intersect (*permitted, + *inheritable)); +if (WARN_ON (!cap_ambient_invariant_ok (new)))
This seems redundant (but safe) in this particular case since you've just calculated it to be precisely (pA & pP & pI)
Quoted 100 lines
security/commoncap.c +30
-8+return -EINVAL ;return 0 ; }@@ -352,6 +362,7 @@ static inline int bprm_caps_from_vfs_caps(struct cpu_vfs_cap_data *caps,/* * pP' = (X & fP) | (pI & fI) +* The addition of pA' is handled later. */ new->cap_permitted.cap[i] = (new->cap_bset.cap[i] & permitted) |@@ -479,10 +490,13 @@ int cap_bprm_set_creds(struct linux_binprm *bprm) {const struct cred *old =current_cred ();struct cred *new = bprm->cred; -bool effective, has_cap = false; +bool effective, has_cap = false, is_setid;int ret;kuid_t root_uid; +if (WARN_ON (!cap_ambient_invariant_ok (old))) +return -EPERM ; + effective = false; ret =get_file_caps (bprm, &effective, &has_cap);if (ret <0 )@@ -527,8 +541,9 @@ skip:* * In addition, if NO_NEW_PRIVS, then ensure we get no new privs. */ -if ((!uid_eq (new->euid, old->uid) || - !gid_eq (new->egid, old->gid) || + is_setid = !uid_eq (new->euid, old->uid) || !gid_eq (new->egid, old->gid); + +if ((is_setid || !cap_issubset (new->cap_permitted, old->cap_permitted)) && bprm->unsafe & ~LSM_UNSAFE_PTRACE_CAP ) {/* downgrade; they get no more than they had, and maybe less */ @@ -544,10 +559,24 @@ skip: new->suid = new->fsuid = new->euid; new->sgid = new->fsgid = new->egid; +/* File caps or setid cancels ambient. */ +if (has_cap || is_setid) +cap_clear (new->cap_ambient); + +/* +* Now that we've computed pA', update pP' to give: +* pP' = (X & fP) | (pI & fI) | pA' +*/ + new->cap_permitted =cap_combine (new->cap_permitted, new->cap_ambient); +if (effective) new->cap_effective = new->cap_permitted;else -cap_clear (new->cap_effective); + new->cap_effective = new->cap_ambient; + +if (WARN_ON (!cap_ambient_invariant_ok (new))) +return -EPERM ; + bprm->cap_effective = effective;/* @@ -562,7 +591,7 @@ skip:* Number 1 above might fail if you don't have a full bset, but I think * that is interesting information to audit. */ -if (!cap_isclear (new->cap_effective)) { +if (!cap_issubset (new->cap_effective, new->cap_ambient)) {if (!cap_issubset (CAP_FULL_SET , new->cap_effective) || !uid_eq (new->euid, root_uid) || !uid_eq (new->uid, root_uid) ||issecure (SECURE_NOROOT )) {@@ -573,6 +602,10 @@ skip: } new->securebits &= ~issecure_mask (SECURE_KEEP_CAPS ); + +if (WARN_ON (!cap_ambient_invariant_ok (new))) +return -EPERM ; +return 0 ; }@@ -594,7 +627,7 @@ int cap_bprm_secureexec(struct linux_binprm *bprm)if (!uid_eq (cred->uid, root_uid)) {if (bprm->cap_effective)return 1 ; -if (!cap_isclear (cred->cap_permitted)) +if (!cap_issubset (cred->cap_permitted, cred->cap_ambient))return 1 ; }@@ -696,10 +729,18 @@ static inline void cap_emulate_setxuid(struct cred *new, const struct cred *old) uid_eq(old->suid, root_uid)) && (!uid_eq(new->uid, root_uid) && !uid_eq(new->euid, root_uid) && - !uid_eq (new->suid, root_uid)) && - !issecure(SECURE_KEEP_CAPS)) {
security/commoncap.c static inline void cap_emulate_setxuid(struct cred *new, const struct cred *old) · line 739
Quoted 10 lines
security/commoncap.c +8
-2-cap_clear (new->cap_permitted); -cap_clear (new->cap_effective); + !uid_eq(new->suid, root_uid))) { +if (!issecure (SECURE_KEEP_CAPS )) { +cap_clear (new->cap_permitted); +cap_clear (new->cap_effective); + } + +/* +* Pre-ambient programs except setresuid to nonroot followed
[ I see 'except' has already been pointed out in the thread :) ]
Quoted 60 lines
security/commoncap.c +30
-0+* by exec to drop capabilities. We should make sure that +* this remains the case. +*/ +cap_clear (new->cap_ambient); }if (uid_eq (old->euid, root_uid) && !uid_eq (new->euid, root_uid))cap_clear (new->cap_effective);@@ -929,6 +970,32 @@ int cap_task_prctl(int option, unsigned long arg2, unsigned long arg3, new->securebits &= ~issecure_mask (SECURE_KEEP_CAPS );return commit_creds (new); +case PR_CAP_AMBIENT : +if (((!cap_valid (arg3)) | arg4 | arg5)) +return -EINVAL ; + +if (arg2 ==PR_CAP_AMBIENT_GET ) { +return !!cap_raised (current_cred ()->cap_ambient, arg3); + }else if (arg2 !=PR_CAP_AMBIENT_RAISE && + arg2 !=PR_CAP_AMBIENT_LOWER ) { +return -EINVAL ; + }else { +if (arg2 ==PR_CAP_AMBIENT_RAISE && + (!cap_raised (current_cred ()->cap_permitted, arg3) || + !cap_raised (current_cred ()->cap_inheritable, + arg3))) +return -EPERM ; + + new =prepare_creds (); +if (!new) +return -ENOMEM ; +if (arg2 ==PR_CAP_AMBIENT_RAISE ) +cap_raise (new->cap_ambient, arg3); +else +cap_lower (new->cap_ambient, arg3); +return commit_creds (new); + } +default :/* No functionality available - continue with default */ return -ENOSYS ;security/keys/process_keys.c +1
-0@@ -848,6 +848,7 @@ void key_change_session_keyring(struct callback_head *twork) new->cap_inheritable = old->cap_inheritable; new->cap_permitted = old->cap_permitted; new->cap_effective = old->cap_effective; + new->cap_ambient = old->cap_ambient; new->cap_bset = old->cap_bset; new->jit_keyring = old->jit_keyring;Signature · 7 lines
2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Quoted 8 lines · Serge Hallyn
Quoted 3 lines
You cannot use pA to try to subvert a setuid, setgid, or file-capped
program: if you execute any such program, pA gets cleared and the resulting evolution rules are unchanged by this patch.Christoph, just to be sure, is this ^ going to suffice for you?
Seems like it should since any program which is setuid-root, i.e. passwd, isn't likely to be designed to exec other programs.
Yes that should work.
Quoted 18 lines · Serge Hallyn
Thanks very much, Andy. Comments and ack below.
Quoted 15 lines · Andy Lutomirski
===== The problem =====
Capability inheritance is basically useless.
If you aren't root and you execute an ordinary binary, fI is zero, so your capabilities have no effect whatsoever on pP'. This means that you can't usefully execute a helper process or a shell command with elevated capabilities if you aren't root.
On current kernels, you can sort of work around this by setting fI to the full set for most or all non-setuid executable files. This causes pP' = pI for nonroot, and inheritance works. No one does this because it's a PITA and it isn't even supported on most filesystems.
Quoted 7 lines
Quoted 2 lines
If you try this, you'll discover that every nonroot program ends up with secure exec rules, breaking many things.
PI would have worked great if most programs wanting privilege were self-contained and compiled. Shell scripts and lots of fork+execing make pI [much less useful] [completely useless]. See also golang's predisposition to fork+exec.
Agreed.
Quoted 11 lines
Quoted 8 lines
This is a problem that has bitten many people who have tried to use capabilities for anything useful.
===== The proposed change =====
This patch adds a fifth capability mask called the ambient mask (pA). pA does what pI should have done.
Or at least what most people want it to do.
Quoted 8 lines
Quoted 5 lines
pA obeys the invariant that no bit can ever be set in pA if it is not set in both pP and pI. Dropping a bit from pP or pI drops that bit from pA. This ensures that existing programs that try to drop capabilities still do so, with a complication. Because capability inheritance is so broken, setting KEEPCAPS, using setresuid to
Sorry, did you mean "... setting KEEPCAPS and then either using setresuid to a nonroot uid or calling execve ..." ?
So, I actually meant:
Because capability inheritance is so broken, setting KEEPCAPS, using setresuid to switch to nonroot uids, and then calling execve effectively drops capabilities.
Fixed.
Quoted 49 lines
Quoted 19 lines
switch to nonroot uids, or calling execve effectively drops capabilities. Therefore, setresuid from root to nonroot conditionally clears pA unless
SECBIT_NO_SETUID_FIXUPis set. Processes that don't like this can re-add bits to pA afterwards.The capability evolution rules are changed:
pA' = (file caps or setuid or setgid ? 0 : pA)
pP' = (X & fP) | (pI & fI) | pA'
pI' = pI
pE' = (fE ? pP' : pA')
X is unchangedIf you are nonroot but you have a capability, you can add it to pA. If you do so, your children get that capability in pA, pP, and pE. For example, you can set pA =
CAP_NET_BIND_SERVICE, and your children can automatically bind low-numbered ports. Hallelujah!Quoted 8 lines
Unprivileged users can create user namespaces, map themselves to a nonzero uid, and create both privileged (relative to their namespace) and unprivileged process trees. This is currently more or less impossible. Hallelujah!
You cannot use pA to try to subvert a setuid, setgid, or file-capped
program: if you execute any such program, pA gets cleared and the resulting evolution rules are unchanged by this patch.Christoph, just to be sure, is this ^ going to suffice for you?
Seems like it should since any program which is setuid-root, i.e. passwd, isn't likely to be designed to exec other programs.
Quoted 4 lines
Users with nonzero pA are unlikely to unintentionally leak that capability. If they run programs that try to drop privileges, dropping privileges will still work.
Quoted 11 lines
It's worth noting that the degree of paranoia in this patch could possibly be reduced without causing serious problems. Specifically, if we allowed pA to persist across executing non-pA-aware setuid binaries and across setresuid, then, naively, the only capabilities that could leak as a result would be the capabilities in pA, and any attacker *already* has those capabilities. This would make me nervous, though -- setuid binaries that tried to privilege-separate might fail to do so, and putting
CAP_DAC_READ_SEARCHorCAP_DAC_OVERRIDEinto pA could have unexpected side effects. (Whether these unexpected side effects would be exploitable is an open question.) I've therefore taken the more paranoid route.
Quoted 2 lines
I'm definitely open to revisiting this question after the current patch has been in use for awhile.
Noted in the changelog for v3.
Quoted 19 lines
Quoted 19 lines
An alternative would be to require
PR_SET_NO_NEW_PRIVSbefore setting ambient capabilities. I think that this would be annoying and would make granting otherwise unprivileged users minor ambient capabilities (CAP_NET_BIND_SERVICEorCAP_NET_RAWfor example) much less useful than it is with this patch.===== Footnotes =====
[1] Files that are missing the "security.capability" xattr or that have unrecognized values for that xattr end up with
has_capset to false. The code that does that appears to be complicated for no good reason.[2] The libcap capability mask parsers and formatters are dangerously misleading and the documentation is flat-out wrong. fE is *not* a mask; it's a single bit. This has probably confused every single person who has tried to use file capabilities.
Quoted 8 lines
Quoted 4 lines
[3] Linux very confusingly processes both the script and the interpreter if applicable, for reasons that elude me. The results from thinking about a script's file capabilities and/or setuid bits are mostly discarded.
Not quite sure what you mean here - setuid and fX are ignored on shell scripts, but I think you're saying something less simple is going on?
I think that's the effect. What I mean is that, when running a script, prepare_binprm and hence cap_bprm_set_creds is called twice:
once from do_execveat_common and once from load_script.
Thanks,
Andy
PATCH v2 2/2 capabilities: Add a securebit to disable PR_CAP_AMBIENT_RAISE
In reply to Andy LutomirskiPer Andrew Morgan's request, add a securebit to allow admins to disable PR_CAP_AMBIENT_RAISE. This securebit will prevent processes from adding capabilities to their ambient set.
For simplicity, this disables PR_CAP_AMBIENT_RAISE entirely rather than just disabling setting previously cleared bits.
--- include/uapi/linux/securebits.h | 11 ++++++++++- security/commoncap.c | 3 ++- 2 files changed, 12 insertions(+), 2 deletions(-)
include/uapi/linux/securebits.h +10 -1
@@ -43,9 +43,18 @@#define SECBIT_KEEP_CAPS (issecure_mask(SECURE_KEEP_CAPS))#define SECBIT_KEEP_CAPS_LOCKED (issecure_mask(SECURE_KEEP_CAPS_LOCKED)) +/* When set, a process cannot add new capabilities to its ambient set. */ +#define SECURE_NO_CAP_AMBIENT_RAISE 6 +#define SECURE_NO_CAP_AMBIENT_RAISE_LOCKED 7/* make bit-6 immutable */ + +#define SECBIT_NO_CAP_AMBIENT_RAISE (issecure_mask(SECURE_NO_CAP_AMBIENT_RAISE)) +#define SECBIT_NO_CAP_AMBIENT_RAISE_LOCKED \ + (issecure_mask(SECURE_NO_CAP_AMBIENT_RAISE_LOCKED)) +#define SECURE_ALL_BITS (issecure_mask(SECURE_NOROOT) | \ issecure_mask(SECURE_NO_SETUID_FIXUP) | \ - issecure_mask(SECURE_KEEP_CAPS)) + issecure_mask(SECURE_KEEP_CAPS) | \ + issecure_mask(SECURE_NO_CAP_AMBIENT_RAISE))#define SECURE_ALL_LOCKS (SECURE_ALL_BITS << 1)#endif /* _UAPI_LINUX_SECUREBITS_H */
security/commoncap.c +2 -1
@@ -983,7 +983,8 @@ int cap_task_prctl(int option, unsigned long arg2, unsigned long arg3,if (arg2 ==PR_CAP_AMBIENT_RAISE && (!cap_raised (current_cred ()->cap_permitted, arg3) || !cap_raised (current_cred ()->cap_inheritable, - arg3))) + arg3) || +issecure (SECURE_NO_CAP_AMBIENT_RAISE )))return -EPERM ; new =prepare_creds ();
Signature · 1 line
2.1.0
Re: [PATCH v2 2/2] capabilities: Add a securebit to disable PR_CAP_AMBIENT_RAISE
Quoted 18 lines · Andy Lutomirski
Per Andrew Morgan's request, add a securebit to allow admins to disable
PR_CAP_AMBIENT_RAISE. This securebit will prevent processes from adding capabilities to their ambient set.For simplicity, this disables
PR_CAP_AMBIENT_RAISEentirely rather than just disabling setting previously cleared bits.Requested-by Andrew G. Morgan <[email protected]>Cc Kees Cook <[email protected]>Cc Christoph Lameter <[email protected]>Cc Serge Hallyn <[email protected]>Cc Andy Lutomirski <[email protected]>Cc Jonathan Corbet <[email protected]>Cc Aaron Jones <[email protected]>CC Ted Ts'o <[email protected]>
Quoted 8 lines
Cc Andrew G. Morgan <[email protected]>Cc Mimi Zohar <[email protected]>Cc Austin S Hemmelgarn <[email protected]>Cc Markku Savela <msa-kXoF896ld44xHbG02/[email protected]>Cc Jarkko Sakkinen <jarkko.sakkinen-VuQAYsv1563Yd54FQh9/[email protected]>Cc Michael Kerrisk <[email protected]>Signed-off-by Andy Lutomirski <[email protected]>
Interesting - at first I thought this wouldn't please Andrew as he'd want the inverse, but I guess this way keeps the pure-capabilities mode (with SECURE_ALL_BITS set) ambient-free which I suppose is really the important thing.
Quoted 51 lines
--- include/uapi/linux/securebits.h | 11 ++++++++++- security/commoncap.c | 3 ++- 2 files changed, 12 insertions(+), 2 deletions(-)include/uapi/linux/securebits.h +10
-1@@ -43,9 +43,18 @@#define SECBIT_KEEP_CAPS (issecure_mask(SECURE_KEEP_CAPS))#define SECBIT_KEEP_CAPS_LOCKED (issecure_mask(SECURE_KEEP_CAPS_LOCKED)) +/* When set, a process cannot add new capabilities to its ambient set. */ +#define SECURE_NO_CAP_AMBIENT_RAISE 6 +#define SECURE_NO_CAP_AMBIENT_RAISE_LOCKED 7/* make bit-6 immutable */ + +#define SECBIT_NO_CAP_AMBIENT_RAISE (issecure_mask(SECURE_NO_CAP_AMBIENT_RAISE)) +#define SECBIT_NO_CAP_AMBIENT_RAISE_LOCKED \ + (issecure_mask(SECURE_NO_CAP_AMBIENT_RAISE_LOCKED)) +#define SECURE_ALL_BITS (issecure_mask(SECURE_NOROOT) | \ issecure_mask(SECURE_NO_SETUID_FIXUP) | \ - issecure_mask(SECURE_KEEP_CAPS)) + issecure_mask(SECURE_KEEP_CAPS) | \ + issecure_mask(SECURE_NO_CAP_AMBIENT_RAISE))#define SECURE_ALL_LOCKS (SECURE_ALL_BITS << 1)#endif /* _UAPI_LINUX_SECUREBITS_H */ security/commoncap.c +2
-1@@ -983,7 +983,8 @@ int cap_task_prctl(int option, unsigned long arg2, unsigned long arg3,if (arg2 ==PR_CAP_AMBIENT_RAISE && (!cap_raised (current_cred ()->cap_permitted, arg3) || !cap_raised (current_cred ()->cap_inheritable, - arg3))) + arg3) || +issecure (SECURE_NO_CAP_AMBIENT_RAISE )))return -EPERM ; new =prepare_creds ();Signature · 7 lines
2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Andrew G. Morgan
Acked-byRe: [PATCH v2 2/2] capabilities: Add a securebit to disable PR_CAP_AMBIENT_RAISE
Thanks
Quoted 86 lines · Serge E. Hallyn
Quoted 18 lines · Andy Lutomirski
Per Andrew Morgan's request, add a securebit to allow admins to disable
PR_CAP_AMBIENT_RAISE. This securebit will prevent processes from adding capabilities to their ambient set.For simplicity, this disables
PR_CAP_AMBIENT_RAISEentirely rather than just disabling setting previously cleared bits.Requested-by Andrew G. Morgan <[email protected]>Cc Kees Cook <[email protected]>Cc Christoph Lameter <[email protected]>Cc Serge Hallyn <[email protected]>Cc Andy Lutomirski <[email protected]>Cc Jonathan Corbet <[email protected]>Cc Aaron Jones <[email protected]>CC Ted Ts'o <[email protected]>Quoted 8 lines
Cc Andrew G. Morgan <[email protected]>Cc Mimi Zohar <[email protected]>Cc Austin S Hemmelgarn <[email protected]>Cc Markku Savela <[email protected]>Cc Jarkko Sakkinen <[email protected]>Cc Michael Kerrisk <[email protected]>Signed-off-by Andy Lutomirski <[email protected]>Interesting - at first I thought this wouldn't please Andrew as he'd want the inverse, but I guess this way keeps the pure-capabilities mode (with
SECURE_ALL_BITSset) ambient-free which I suppose is really the important thing.Acked-by Serge Hallyn <[email protected]>Quoted 51 lines
--- include/uapi/linux/securebits.h | 11 ++++++++++- security/commoncap.c | 3 ++- 2 files changed, 12 insertions(+), 2 deletions(-)include/uapi/linux/securebits.h +10
-1@@ -43,9 +43,18 @@#define SECBIT_KEEP_CAPS (issecure_mask(SECURE_KEEP_CAPS))#define SECBIT_KEEP_CAPS_LOCKED (issecure_mask(SECURE_KEEP_CAPS_LOCKED)) +/* When set, a process cannot add new capabilities to its ambient set. */ +#define SECURE_NO_CAP_AMBIENT_RAISE 6 +#define SECURE_NO_CAP_AMBIENT_RAISE_LOCKED 7/* make bit-6 immutable */ + +#define SECBIT_NO_CAP_AMBIENT_RAISE (issecure_mask(SECURE_NO_CAP_AMBIENT_RAISE)) +#define SECBIT_NO_CAP_AMBIENT_RAISE_LOCKED \ + (issecure_mask(SECURE_NO_CAP_AMBIENT_RAISE_LOCKED)) +#define SECURE_ALL_BITS (issecure_mask(SECURE_NOROOT) | \ issecure_mask(SECURE_NO_SETUID_FIXUP) | \ - issecure_mask(SECURE_KEEP_CAPS)) + issecure_mask(SECURE_KEEP_CAPS) | \ + issecure_mask(SECURE_NO_CAP_AMBIENT_RAISE))#define SECURE_ALL_LOCKS (SECURE_ALL_BITS << 1)#endif /* _UAPI_LINUX_SECUREBITS_H */ security/commoncap.c +2
-2@@ -983,7 +983,8 @@ int cap_task_prctl(int option, unsigned long arg2, unsigned long arg3,if (arg2 ==PR_CAP_AMBIENT_RAISE && (!cap_raised (current_cred ()->cap_permitted, arg3) || !cap_raised (current_cred ()->cap_inheritable, - arg3))) + arg3) || +issecure (SECURE_NO_CAP_AMBIENT_RAISE )))return -EPERM ; new =prepare_creds (); --2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Quoted 8 lines · Andy Lutomirski
This adds ambient capabilities. See the individual patch changelogs for details.
Preliminary userspace code is here:
I'll follow up with a rough draft of a man-pages patch.
Just as a note: I'm going to hold off on v3 until Kees and/or Serge can take a look, since so far the only changes I want to make to the kernel part are some comment cleanups and a possible rearrangement of the pE' stuff that will provably have no effect.
--Andy
Quoted 21 lines
Changes from v1:
- Lots of cleanups to the ambient cap code.
- The securebit is new.Andy Lutomirski (2):
capabilities: Ambient capabilities
capabilities: Add a securebit to disablePR_CAP_AMBIENT_RAISEfs/proc/array.c | 5 ++- include/linux/cred.h | 8 ++++ include/uapi/linux/prctl.h | 6 +++ include/uapi/linux/securebits.h | 11 +++++- kernel/user_namespace.c | 1 + security/commoncap.c | 88 ++++++++++++++++++++++++++++++++++++----- security/keys/process_keys.c | 1 + 7 files changed, 108 insertions(+), 12 deletions(-)--
2.1.0
Signature · 2 lines
Andy Lutomirski AMA Capital Management, LLC