linux-kernel - Re: TOMOYO Linux Security Goal

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200712291243.HFE05726.MFOJOVLQFFOtSH@I-love.SAKURA.ne.jp>
Date:	Sat, 29 Dec 2007 12:43:24 +0900
From:	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To:	serue@...ibm.com
Cc:	linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: TOMOYO Linux Security Goal

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 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/