Re: [Plash] Re: Plash 1.16 - possible security hole

[David Hopwood]

Richard Thrippleton wrote:
> On Thu Jan 04 13:45, Mark Seaborn wrote:
> 
>>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).

It seems to me that the best way of resolving this is to find a way to express
Unix's security model within the object-capability model. I have some ideas on
how to do that, but I'll send this now since the details may take some time to
work out.

>>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 don't think that this solution is consistent with an object-capability 
analysis
of the problem. The original scenario was:

# 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.

There are two independent issues here:

1. The application is supposed to be confined, so why does it have access to
   mutable state that is also writable by a hostile local user?

2. The hostile local user doesn't have access to ~victim/.bashrc, and so 
shouldn't
   be able to transfer a permission that it doesn't have to the app (regardless
   of whether the latter has been successfully confined).

-- 
David Hopwood <address@hidden>