Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.

[Crispin Cowan]

Casey Schaufler wrote:
> --- Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx> wrote
> > Casey Schaufler wrote:
> >     
> > > The question of protections on the object named /etc/passwd came
> > > up time and time again. The notion that /etc/passwd could be a
> > > symlink to /home/smalley/heeheehee really gave evaluators the
> > > whillies. As did the chroot environment, where /roots/crispin/etc/passwd
> > > could magicly become /etc/passwd.
> > >       
> > Why do people continue speaking symlinks and chroots?
> >     
> Because on any given Linux system you could have an arbitrarily
> large number of different things that might be accessed by the
> name "/etc/passwd" and a different, but similarly large number
> of names other than "/etc/passwd" that can be used to access them.
>   
But that's not quite true.

"/etc/passwd" can indeed point anywhere, but it can only point to a 
single place at a time. I've alluded to this several times in pointing 
out that labels and names have dualistic many:one and one:many 
relationships to actual files.

This is Tetsuo's point: if you symlink or chroot /etc/shadow to point 
some place strange, then the redirection will be resolved *before* 
AppArmor and TOMOYO consider the security question of whether access 
should be allowed. Therefore, the fact that you re-directed it is 
irrelevant to security.

> > To avoid the effect of symlinks and chroots, AppArmor and TOMOYO Linux
> > derive pathnames from dentry and vfsmount.
> > If /etc/passwd was a symlink, the derived pathname will be
> > /home/smalley/heeheehee.
> > If accessed from inside a chroot, the derived pathname will be
> > /roots/crispin/etc/passwd.
> >     
> Which doesn't hold up under hard links, which I had carefully
> avoided and that both AppArmor and TOMOYO Linux have to place
> restrictions on for the systems to make sense.
>   
Hard links are indeed handled differently, but they are handled. I don't 
know what TOMOYO does. What AppArmor does is exploit the fact that you 
cannot hard link a directory, so the target of a hard link must be a 
file. From there, we can use the    dentry to disambiguate which file. 
So again, even though more than one name points to the inode, the name 
that was actually  used to get to this inode is unique, and we recover 
it and then consider the security question of whether you get to access 
that name.

> > It is true that namespace may differ between processes,
> > but I think that that is the matter of how to restrict namespace manipulation
> > operations.
> > As I said, a system can't survive if namespace is madly manipulated.
> >     
> That's hardly the viewpoint of those who would have every
> user mount their own version of /tmp.
>   
Well, AppArmor and TOMOYO don't do well if the namespace is madly 
manipulated. They remain secure, because they prohibit name space 
manipulations by confined processes. If what you wanted to do was lots 
of  name space manipulations, it makes (at least AppArmor) a poor choice 
for you.

> > It is true that the pathname may change while traversing up the
> > dentry/vfsmount trees.
> > But the change does not occur infinitely.
> > As I said, a system can't survive if files and directories are madly renamed.
> > The possible changes are bounded by the policy.
> >
> > At least, I want people not to speak symlinks and chroots when talking about
> > AppArmor and TOMOYO Linux.
> >     
> The issues with links, symlinks, chroots and mounts in the
> context of a name based access control scheme will always
> need to be addressed, just as the issues of unlabeled filesystems
> and /tmp will have to be in label based scheme.
>   
Agreed. Duality abounds in this space.

Crispin

--
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin
The Olympic Games: Symbolizing oppressiiion and corruption for over a
hundred years

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/