lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 13 Aug 2009 23:15:11 -0500 From: Will Drewry <redpig@...aspill.org> To: linux-kernel@...r.kernel.org Cc: James Morris <jmorris@...ei.org>, linux-security-module@...r.kernel.org, morgan@...nel.org Subject: [RFC][PATCH 1/1] support optional non-VFS capability inheritance without disabling file caps Capabilities marked as inheritable (+i) are inaccessible when inherited by a child process (after exec()) with CONFIG_SECURITY_FILE_CAPABILITIES enabled unless the VFS entry of the child also provides the capability (or cap_setpcap) in the permitted/effective sets. This change adds a securebit, SECURE_INHERIT_CAPS, which enableѕ inherited capabilities to be propagated to the permitted set of the child process. If it doesn't conflict with VFS_CAP_FLAGS_EFFECTIVE, it will also mark the capabilities effective. This bit and change only take effect when SECURE_NOROOT is set. The securebit guard is used because this change violates the following constraint: pP' = (X & fP) | (pI & fI) With bit-6 enabled, the constraint becomes: pP' = (X & fP) | (pI) and pE' varying based on VFS bits and if there are any file-based capabilities. This allows for a purely runtime capabilities-based environment without requiring every file to be annotated with an extended attribute. This also means that SECURE_NOROOT process trees using capabilities become more accessible, especially for filesystems without extended attribute support - or in mixed FS environments. For example, a daemon like dhcpcd may be launched with cap_net_raw by a more privileged daemon. Once dhcpcd drops the cap_net_raw privilege, it will not be able to regain it. Even if a local user runs dhcpcd manually, the capability will not be granted because the capability was not derived from the filesystem. However, the calling capability manager could either gain its permissions from init or by having a file-based capability set. Nb, I may be missing something obvious - any insights will be appreciated, and there is a good bit of flexibility in what can be done here. Signed-off-by: Will Drewry <redpig@...aspill.org> --- include/linux/securebits.h | 12 +++++++++++- security/commoncap.c | 7 +++++++ 2 files changed, 18 insertions(+), 1 deletions(-) diff --git a/include/linux/securebits.h b/include/linux/securebits.h index d2c5ed8..ed50b80 100644 --- a/include/linux/securebits.h +++ b/include/linux/securebits.h @@ -27,6 +27,15 @@ #define SECURE_KEEP_CAPS 4 #define SECURE_KEEP_CAPS_LOCKED 5 /* make bit-4 immutable */ +/* When set, any capabilities inherited from a parent process will + start in the permitted, and possibly effective, capability set + if SECURE_NOROOT is set. + pP' = (X & fP) | (pI & fI) + becomes + pP' = (X & fP) | (pI) */ +#define SECURE_INHERIT_CAPS 6 +#define SECURE_INHERIT_CAPS_LOCKED 7 /* make bit-6 immutable */ + /* Each securesetting is implemented using two bits. One bit specifies whether the setting is on or off. The other bit specify whether the setting is locked or not. A setting which is locked cannot be @@ -36,7 +45,8 @@ #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_INHERIT_CAPS)) #define SECURE_ALL_LOCKS (SECURE_ALL_BITS << 1) #endif /* !_LINUX_SECUREBITS_H */ diff --git a/security/commoncap.c b/security/commoncap.c index 48b7e02..9b4590d 100644 --- a/security/commoncap.c +++ b/security/commoncap.c @@ -508,6 +508,13 @@ int cap_bprm_set_creds(struct linux_binprm *bprm) } if (new->euid == 0) effective = true; + } else if (issecure(SECURE_INHERIT_CAPS)) { + /* Only enable permitted-to-effective inheritance if it doesn't + * override VFS_CAP_FLAGS_EFFECTIVE behavior. */ + if (!effective && cap_isclear(new->cap_permitted)) + effective = true; + new->cap_permitted = cap_combine(new->cap_permitted, + new->cap_inheritable); } skip: -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists