Re: Single home directory type for all roles.

On Thu, 2004-12-09 at 13:18 -0500, Stephen Smalley wrote:
> On Thu, 2004-12-09 at 13:12, Russell Coker wrote:
> > Last time I mentioned this I was informed that it is impractically
> > difficult for the kernel code to differentiate between an application
> > such as ls calling readlink(2) and the kernel code calling it as part of
> > a file open operation.
>
> Not sure who said that, but there are two separate LSM hooks on those
> code paths, security_inode_readlink() vs. security_inode_follow_link().
> They just happen to perform the same check in SELinux presently.
> Whether or not it is legitimate to separate them in the access control
> model is another question; if you don't want the admin following the
> link, why do you want an application he runs to rely on the information
> returned by readlink?

You are correct that there are cases of applications calling readlink(2) for the purpose of canonicalising a path which would be vulnerable to race conditions after such a change. However writing an application that does such things in a manner such that it is not vulnerable to any race conditions is really difficult and it seems likely that most such applications can be attacked in other ways (which will be more difficult to implement).

But it would catch the majority of attacks and make it more difficult for an attack to leave a file system. Some of the attacks might work if the attacker found a symlink in a directory that they could rename - but the attacker would need to discover the contents of the sym-link which should be impossible.

> In any event, we could apply different permission checks - it just
> requires defining a new permission in the lnk_file class and modifying
> the selinux_inode_follow_link() hook function to use it. Trivial patch,
> anyone could do it (but then you would need to identify all the places
> in the policy where you would need to add it).

Fixing the policy should be easy enough.

> > The solution then would be to have a separate domain for the
> > administrator to run ls which can read all sym-links while other
> > programs the administrator may run (rm, cp, mv, etc) will be denied
> > access to read many types of sym-link. Is this a good idea?
>
> Seems painful.

Yes. But it would give a practical use for ls_exec_t. ;)

> > Can we break the tradition of having only /home/$USER in this regard?
> > There are several other categories of files that are relevant to
> > security that could benefit from similar treatment if we go down that
> > path.
>
> For MLS, we'll need multiple home directories per user anyway, although
> they could all be rooted under /home/$USER and polyinstantiated
> directories could be used to transparently redirect to the right member
> subdirectory.

That's an entirely different issue.

If we have both strict policy in it's current form and MLS then we would have two ways of categorising the files (role and level). I think that probably the best thing to do for MLS is to polyinstantiate /home per MLS level. Anything else seems to get too confusing too fast.

I hope that we don't plan on supporting polyinstantiation for MLS over NFS.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.