Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

Serge E. Hallyn
2006-04-19T11:53:44Z

Quoting Kyle Moffett (mrmacman_g4@mac.com):
> On Apr 18, 2006, at 21:48:56, Casey Schaufler wrote:
> >--- James Morris <jmorris@namei.org> wrote:
> >>With pathnames, there is an unbounded and unknown number of
> >>effective security policies on the system, as there are an
> >>unbounded and unknown number of ways of viewing the files via
> >>pathnames.
> >
> >I agree that for traditional DAC and MAC (including the flavors
> >supported by SELinux) inodes is the only way to go. SELinux is a
> >traditional Trusted OS architecture and addresses the traditional
> >Trusted OS issues.
>
> Perhaps the SELinux model should be extended to handle (dir-inode,
> path-entry) pairs. For example, if I want to protect the /etc/shadow
> file regardless of what tool is used to safely modify it, I would set
> up security as follows:

Perhaps linux should keep it's momentum toward p9-ish and implement a
factotum service.

Note what we're trying to do:
1. make the mount tree as dynamic as possible, per-process.
So my /var/spool can be completely different from yours,
on the same machine.
2. but to let process p5 authenticate as root, privileged code
trusts info stored in hardcoded pathnames in p5's current mount
tree.
In other words, we want to prevent just a few pathnames from being
replaced through a bind mount/pivot_root/whatever.

Would make much more sense to have one thread running in an initial
private fs namespace, using pathnames it knows it can trust to dole
out privs.

I recall at last year's OLS Eric Van Hensbergen led a talk to discuss
problems involved in allowing unprivileged user mounts, where this
idea came up. But of course no one (that I know of) has been crazy
enough to try it.

-serge