[Plash] Re: Plash 1.16 - possible security hole

[Richard Thrippleton]

On Thu Jan 04 13:45, Mark Seaborn wrote:
> 
> In general though, it's not safe to grant access to directories that
> are writable by other non-root users.  As a minimum, the documentation
> should mention that.
Are there other issues to do with shared writable directories beyond the
hardlink problem? Restricting or discouraging use of shared directories might
break some use case of applications trying to share a limited set of data (I'll
let you know if I think of a concrete example).
 
> For Plash this is more serious, because it leaks authority rather than
> space.
> 
> We could prevent the situation from arising by changing Unix to
> disallow hard linking other users' files.  That seems reasonable.
> Would it break any important use cases?
Currently unsure, but I favour the conservative approach of not breaking unix
semantics unless absolutely necessary; somebody somewhere could rely on that
function simply because it's a guaranteed part of Unix that doesn't necessarily
always break the desired security properties. Importing a filesystem (say, NFS)
from a machine that didn't have these guarantees would also foil us, and it
becomes additional effort for an administrator to decide that their whole
NIS/NFS workstation system has to conform to new constraints. Finally, I think
it would be elegant if plash could carry on doing everything it did without
requiring a kernel patch.

> This is interesting because it shows the problem of mixing two
> security models.  Unix's security model is based on object labelling
> (largely disregarding the path of access).  Plash's model, like the
> capability model, is based on path of access (disregarding labels on
> objects).  It looks like we will need to check object labels as well.
AppArmour* dealt with a similar problem - they observe that there is not a one
to one mapping between a path and an object, yet they still use paths for their
access controls. Their (fairly logical, imo) solution is to enforce the
assumption that there is a one to one mapping by crying foul when a file with a
link count > 1 is being dealt with; this link count implies that there are
other paths to the same object which might have more restricted access
permissions on them. I'm not entirely sure just how they fail when objects like
this are found, but a sane solution would be to assume no rights unless the
unix access specifiers gives those rights to world. A more 'correct' solution
would be to crawl the entire filesystem looking for all paths to an object
(probably inode trickery?) and apply the most restrictive privilege, though
this is probably infeasible!
Copying AppArmour's solution would probably be your best approach if you can
find a non-racey way of checking and then acting upon the link count (AppArmour
had the benefit of being in the kernel). This should deal with the hardlink
problem in a very fundamental way, rather than having to deal with each
consequence of path/object non-equivalence as it gets thought up (like my
earlier report).

(* - or I could be getting confused with an earlier Linux RBAC)

Richard