Thread (57 messages) 57 messages, 7 authors, 2017-09-05
STALE3312d

Revision v3 of 13 in this series.

Revisions (13)
  1. v3 [diff vs current]
  2. v3 [diff vs current]
  3. v3 [diff vs current]
  4. v3 current
  5. v3 [diff vs current]
  6. v3 [diff vs current]
  7. v3 [diff vs current]
  8. v3 [diff vs current]
  9. v3 [diff vs current]
  10. v3 [diff vs current]
  11. v4 [diff vs current]
  12. v4 [diff vs current]
  13. v5 [diff vs current]

[PATCH V3 05/10] capabilities: use intuitive names for id changes

From: luto@kernel.org (Andy Lutomirski)
Date: 2017-08-25 15:06:24

On Wed, Aug 23, 2017 at 3:12 AM, Richard Guy Briggs [off-list ref] wrote:
quoted hunk ↗ jump to hunk
Introduce a number of inlines to make the use of the negation of
uid_eq() easier to read and analyse.

Signed-off-by: Richard Guy Briggs <redacted>
---
 security/commoncap.c |   26 +++++++++++++++++++++-----
 1 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/security/commoncap.c b/security/commoncap.c
index 36c38a1..1af7dec 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -483,6 +483,15 @@ static int get_file_caps(struct linux_binprm *bprm, bool *effective, bool *has_f

 static inline bool root_privileged(void) { return !issecure(SECURE_NOROOT); }

+static inline bool is_real(kuid_t uid, struct cred *cred)
+{ return uid_eq(cred->uid, uid); }
OK I guess, but this just seems like a way to obfuscate the code a bit
and save typing "->uid".
+
+static inline bool is_eff(kuid_t uid, struct cred *cred)
+{ return uid_eq(cred->euid, uid); }
Ditto.
+
+static inline bool is_suid(kuid_t uid, struct cred *cred)
+{ return !is_real(uid, cred) && is_eff(uid, cred); }
Please no.  This is IMO insane.  You're hiding really weird,
nonintuitive logic in an oddly named helper.

Also, this is going to cause massive confusion and severe bugs: given
the same, the only remotely sensible guess as to what this function
does is uid_eq(cred->suid, uid).  So NAK to this.
quoted hunk ↗ jump to hunk
+
 void handle_privileged_root(struct linux_binprm *bprm, bool has_fcap, bool *effective, kuid_t root_uid)
 {
        const struct cred *old = current_cred();
@@ -493,7 +502,7 @@ void handle_privileged_root(struct linux_binprm *bprm, bool has_fcap, bool *effe
         * for a setuid root binary run by a non-root user.  Do set it
         * for a root user just to cause least surprise to an admin.
         */
-       if (has_fcap && !uid_eq(new->uid, root_uid) && uid_eq(new->euid, root_uid)) {
+       if (has_fcap && is_suid(root_uid, new)) {
e.g. this.  The logic used to be obviously slightly dicey.  Now it
looks sane but doesn't do what you'd naively expect it to do, which is
far worse.
quoted hunk ↗ jump to hunk
@@ -519,6 +528,13 @@ void handle_privileged_root(struct linux_binprm *bprm, bool has_fcap, bool *effe
        !cap_issubset(cred->cap_##target, cred->cap_##source)
 #define cap_full(field, cred) \
        cap_issubset(CAP_FULL_SET, cred->cap_##field)
+
+static inline bool is_setuid(struct cred *new, const struct cred *old)
+{ return !uid_eq(new->euid, old->uid); }
+
+static inline bool is_setgid(struct cred *new, const struct cred *old)
+{ return !gid_eq(new->egid, old->gid); }
Please don't.  This logic is fragile, and these helpers are pretending
it's not fragile even though it's still fragile.
--
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help