On Tue, 2021-11-30 at 11:06 -0500, Stefan Berger wrote: > From: Denis Semakin <denis.semakin@xxxxxxxxxx> > > Use integrity_admin_ns_capable() to check corresponding capability to > allow read/write IMA policy without CAP_SYS_ADMIN but with > CAP_INTEGRITY_ADMIN. > > Signed-off-by: Denis Semakin <denis.semakin@xxxxxxxxxx> > --- > security/integrity/ima/ima_fs.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/security/integrity/ima/ima_fs.c > b/security/integrity/ima/ima_fs.c > index fd2798f2d224..6766bb8262f2 100644 > --- a/security/integrity/ima/ima_fs.c > +++ b/security/integrity/ima/ima_fs.c > @@ -393,7 +393,7 @@ static int ima_open_policy(struct inode *inode, > struct file *filp) > #else > if ((filp->f_flags & O_ACCMODE) != O_RDONLY) > return -EACCES; > - if (!ns_capable(ns->user_ns, CAP_SYS_ADMIN)) > + if (!integrity_admin_ns_capable(ns->user_ns)) so this one is basically replacing what you did in RFC 16/20, which seems a little redundant. The question I'd like to ask is: is there still a reason for needing CAP_INTEGRITY_ADMIN? My thinking is that now IMA is pretty much tied to requiring a user (and a mount, because of securityfs_ns) namespace, there might not be a pressing need for an admin capability separated from CAP_SYS_ADMIN because the owner of the user namespace passes the ns_capable(..., CAP_SYS_ADMIN) check. The rationale in https://kernsec.org/wiki/index.php/IMA_Namespacing_design_considerations Is effectively "because CAP_SYS_ADMIN is too powerful" but that's no longer true of the user namespace owner. It only passes the ns_capable () check not the capable() one, so while it does get CAP_SYS_ADMIN, it can only use it in a few situations which represent quite a power reduction already. James
