[PATCH V3 09/10] capabilities: fix logic for effective root or real root
From: serge@hallyn.com (Serge E. Hallyn)
Date: 2017-08-24 16:29:46
Quoting Richard Guy Briggs (rgb at redhat.com):
Now that the logic is inverted, it is much easier to see that both real root and effective root conditions had to be met to avoid printing the BPRM_FCAPS record with audit syscalls. This meant that any setuid root applications would print a full BPRM_FCAPS record when it wasn't necessary, cluttering the event output, since the SYSCALL and PATH records indicated the presence of the setuid bit and effective root user id. Require only one of effective root or real root to avoid printing the unnecessary record. Ref: 3fc689e96c0c (Add audit_log_bprm_fcaps/AUDIT_BPRM_FCAPS) See: https://github.com/linux-audit/audit-kernel/issues/16 Signed-off-by: Richard Guy Briggs <redacted>
Reviewed-by: Serge Hallyn <serge@hallyn.com> I wonder whether,
quoted hunk ↗ jump to hunk
--- security/commoncap.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-)diff --git a/security/commoncap.c b/security/commoncap.c index eb2da69..49cce06 100644 --- a/security/commoncap.c +++ b/security/commoncap.c@@ -540,7 +540,7 @@ static inline bool is_setgid(struct cred *new, const struct cred *old) * * We do not bother to audit if 3 things are true: * 1) cap_effective has all caps - * 2) we are root + * 2) we became root *OR* are root
For clarity, what do you think about adding "(because fcaps were not used)"?
quoted hunk ↗ jump to hunk
* 3) root is supposed to have all caps (SECURE_NOROOT) * Since this is just a normal root execing a process. *@@ -553,8 +553,8 @@ static inline bool nonroot_raised_pE(struct cred *cred, kuid_t root) if (cap_grew(effective, ambient, cred) && !(cap_full(effective, cred) && - is_eff(root, cred) && - is_real(root, cred) && + (is_eff(root, cred) || + is_real(root, cred)) && root_privileged())) ret = true; return ret;-- 1.7.1
-- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html