Re: [PATCH] Version 4 (2.6.23-rc8-mm2) Smack: Simplified Mandatory Access Control Kernel

[Casey Schaufler <casey@schaufler-ca.com>]

--- Al Viro <viro@ftp.linux.org.uk> wrote:

> On Wed, Oct 03, 2007 at 12:51:08PM -0700, Casey Schaufler wrote:
> > > > Because you throw "simple" out the window when you require userland
> > > > assistance to perform this function.
> > > 
> > > Any more than having /tmp replaced with a symlink?
> > 
> > Yes. By the way, there's nothing that really requires that you
> > use a /smack symlink if you don't want to. /tmp can still be a
> > real directory, a mount point, a symlink to /var/tmp, or whatever
> > else you want it to be if that suits your needs better. For the
> > simplest scenarios /tmp -> /smack/tmp -> /moldy/<label> has every
> > other scheme I've seen throughly beaten.
> 
> And your point is?  If you don't use it, you get exact same complexity
> in both setups.

Thank you for your patience. Let me see if I can get my point across.

The intended Smack scenario:

1. Create /moldy at "_"
2. For each label you care about
   2a. Create /moldy/<label>
   2b. Set the label of /moldy/<label> to <label>
3. ln -s /smack/tmp /tmp

All processes are now redirected into the appropriate place
regardless of how they come into being. It doesn't matter if
the "session" starts from busybox, login, sshd, xdm, crontab,
or out of an init script.
  
> > > _What_ userland intervention?  Mounting stuff under /smack/tmp and not
> under
> > > your /moldy?
> > 
> > Who said anything about mounting under /moldy? I never did.
> 
> Sigh...  So put the binding into fstab and be done with that.

Are you suggesting that /smack/tmp.link below is a mount point,
and that appropriate directories get mounted there? 

1. Create /moldy at "_"
2. For each label you care about
   2a. Create /moldy/<label>
   2b. Set the label of /moldy/<label> to <label>
   2c. mount --bind /moldy/<label> /smack/tmp.link/<label>
3. ln -s /smack/tmp.link /tmp
  
> > > Having /tmp replaced with symlink to /smack/tmp.link instead
> > > of replacing it with a symlink to /smack/tmp?
> > > 
> > > Absolute paths in that kind of thing are _wrong_.  You know where the
> things
> > > are on your fs.  You don't know if anything else will be visible, let
> alone
> > > whether it will be at the same place in all chroots or namespaces.  And
> no,
> > > you _can't_ make sure that fs is visible only in one place.  No fs can or
> > > has any business even trying.
> > 
> > Is the objection that there is a default value coded in?
> 
> Right now the main objection is about your lack of ability to read.

Now you sound like my daughter. :-)

> Which
> part of "it can be mounted in different chroots/namespaces, therefore
> having absolute paths doesn't work" is too hard to understand?

It's the content of a symlink, and that can be just about anything
and is not required to point to anything, which is one reason why
I made that choice. If you don't have a /tmp, or can't write to the
/tmp that exists, or have a /tmp that's a dangling symlink under
any circumstances you may have an issue. That's true regardless of
the presence or absense of /smack. All of the traditional mechanisms
for dealing with /tmp in a chrooted or namespaced environment remain.

> No, it's not about having a default.

Nuts. That would have made addressing your concern easy.

> It's about keeping an absolute pathname in virtual fs,

It's in a symlink on the filesystem, and it doesn't have to be an
absolute pathname, although since it's a symlink and the semantics
for a symlink allow that be be absolute, relative, or dangling I
don't see any reason to restrict it from being absolute.

> having all instances autosoddingmatically sharing it _and_
> having change attempt in any instance automatically affect all of them.
> If you have that kind of sharing, don't pretend that your mechanism really
> allows absolute pathnames.

Could allowing multiple distinct mounts and symlink assignments
of /smackfs address those issues? I think it would, but as you pointed
out earlier, my lack of ability to read may be clouding my understanding.

Thank you.


Casey Schaufler
casey@schaufler-ca.com
-
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/