Hello.
Serge E. Hallyn wrote:
> > > > * namespace manipulation. (i.e. mount()/umount()/pivot_root())
> > >
> > > do you track mounts namespace cloning?
> > >
> > Yes. TOMOYO can recognize mount operation with the following flags.
> >
> > --bind --move --remount
> > --make-unbindable --make-private --make-slave --make-shared
>
> No, I mean clone(CLONE_NEWNS) and unshare(CLONE_NEWNS). Without
> tracking those, it seems like a convoluted sequence of mounting,
> unmonting, and mount sharing and unsharing could potentially confuse
> your policy or your admins...
Oh, I see. TOMOYO doesn't track clone() and unshare().
> I haven't fully thought it through. But at least if an admin makes a
> policy update with an expectation that all processes have the same mount
> trees the result could be unsafe.
TOMOYO doesn't expect that all processes have the same mount trees.
But TOMOYO expects that the mount trees won't change unless one of mount()/
umount()/pivot_root() are called.
Does a process get different mount trees by just calling clone() or unshare()?
My understanding is that clone() or unshare() disables propergation of
mount tree changes when somebody calls mount() or umount() or pivot_root().
> > Speak of bind mounts, there comes vfsmount problem.
> > AppArmor has been proposing patches to pass "struct vfsmount" parameter to
> > VFS helper functions and LSM hooks so that AppArmor/TOMOYO can determine
> > which pathname was requested in the bind-mounted environment.
> > Without the vfsmount patches, we can't calculate pathname without the risk of
> > AB-BA deadlock (if namespace_sem held) or crash (if namespace_sem not held).
> > I think we should start discussing how the vfsmount patches can be merged.
> > I'm sad to see no response for AppArmor's posting
> > at http://lkml.org/lkml/2007/12/20/182 .
>
> If the patches solve your problem, and you respond saying "TOMOYO needs
> these patches too", it just might get the thread going.
>
I'll say it when I submit patches.
Regards.
--
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]
