Messages in this thread | | | Date | Thu, 20 Apr 2006 06:40:10 -0500 | From | "Serge E. Hallyn" <> | Subject | Re: [RFC][PATCH 4/11] security: AppArmor - Core access controls |
| |
Quoting Al Viro (viro@ftp.linux.org.uk): > > > +static int _aa_perm_dentry(struct aaprofile *active, struct dentry *dentry, > > + int mask, const char **pname) > > +{ > > + char *name = NULL, *failed_name = NULL; > > + struct aa_path_data data; > > + int error = 0, failed_error = 0, path_error, > > + complain = PROFILE_COMPLAIN(active); > > + > > + /* search all paths to dentry */ > > + > > + aa_path_begin(dentry, &data); > > + do { > > + name = aa_path_getname(&data); > > + if (name) { > > + /* error here is 0 (success) or +ve (mask of perms) */ > > + error = aa_file_perm(active, name, mask); > > + > > + /* access via any path is enough */ > > + if (complain || error == 0) > > + break; /* Caller must free name */ > > + > > + /* Already have an path that failed? */ > > + if (failed_name) { > > + aa_put_name(name); > > + } else { > > + failed_name = name; > > + failed_error = error; > > + } > > + } > > + } while (name); > > Is that a joke? Are you really proposing to do _that_ on anything resembling > a hot path? > > BTW, the problems here really have nothing to do with namespaces or > lazy umount, seeing that it's whitelisting. Moderate amount of bindings > will kill you here. So much that I suspect that one-time overhead of > creating a namespace and umounting / remounting noexec / etc. on > execve() will be cheaper than all this crap.
I guess this would require per-vfsmount flags (i.e. mount --bind -o ro) to be implemented, but IIUC the suggestion is
given a policy
/bin/stty { /bin/stty r }
during execve AA would unshare(CLONE_NEWNS), remount / readonly and noexec, and mount /bin/stty into place with exec privs. I guess getting /bin/stty into place shouldn't be much of a challenge (i.e. just do the operations in the order mkdir /.tmp123 mount --bind -o ro,noexec / /.tmp123 mount --bind /bin/stty /.tmp123/bin/stty mount --bind /.tmp123 / ) but implementing the 'ux' exec permission which apparmor currently has (i.e. giving the ability for stty to then execute /bin/login without restrictions) could be more challenging.
This also might beg for sys_unshare() (and corresponding code in clone) to have it's own security_vfs_unshare() hook, rather than being globbed in with CAP_SYS_ADMIN.
-serge - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |