[Plash] Re: Plash 1.16 - possible security hole

[Mark Seaborn]

Richard Thrippleton <address@hidden> wrote:

> In related news, I think there's possibly another bug relating to hostile 
> local
> users + compromised sandboxed applications. It relates to hardlinks, and has
> been verified in 1.17.
> The hostile local user creates a hardlink in /tmp pointing to ~victim/.bashrc 
> .
> The victim's confined application, though it has little access to files in ~,
> can compromise ~/.bashrc via the hardlink. It's reasonable that a confined
> application can read/write tmp, and that a hostile local user can hardlink to
> the victim's .bashrc; homedir's without world-search permission are rare.
> 
> Can you confirm?

Interesting.  Yes, that is a vulnerability.  Thanks for spotting it.

I think the answer, as far as /tmp goes, is to map /tmp to a
freshly-created empty directory, rather than to the real /tmp.  I have
been meaning to do that for a while, but this is a good reason to
implement it now.  I'll add a "--tmp" option to pola-run (which would
be implied by "-B"), to be used instead of "-fw /tmp".

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.

I can see several options for how the implementation could be changed
to handle this case:

1) Give a warning or an error when granting access to a directory
that's writable by other non-root users.  A warning is probably too
weak.  This would happen at the point of mapping the directory into a
namespace, which isn't really the right place.  We wouldn't be able to
check the subdirectories.

2) Give an access error at the point of traversing the directory tree
to a directory that's writable by other non-root users.  This is
simple to implement.  However, if Plash is running as root, this would
disallow access to all directories owned by normal users, which is not
desirable.

3) Allow access to directories writable by other non-root users, with
the exception of disallowing access to files within them that would
not be accessible by the users that can write to the directory.  How
would this handle groups?  Is it possible to implement this without
race conditions?  Normally the restriction would only apply to files
but we would have to extend it to subdirectories on exotic filesystems
that allow directories to be hardlinked as well.


This hard-linking issue is also a problem in Unix in the presence of
quotas: A malicious user can hard link another user's files, tying up
space and thereby exhausting their quota.  (This is easy to do if the
files were deliberately shared, otherwise the malicious user has to
guess filenames.)  Here is one discussion about this:
http://lists.grok.org.uk/pipermail/full-disclosure/2003-November/014108.html

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?


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.

Incidentally, Plash should not have an analagous problem to Unix.
Under Plash, if you have read-only access to a file, you cannot hard
link it into a directory to which you have write access.  This happens
as a natural consequence of the object model that wraps filesystem
accesses.  The read-only file is a read_only_proxy object (which has a
reference to an underlying file object).  If you try to hard link this
into a real_dir, the real_dir simply won't recognise the
read_only_proxy; it won't try to unwrap it.

Mark