Quoting Al Viro ([email protected]):
>
> > +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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
