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

[John McCabe-Dansted]

On 1/14/07, David Hopwood <address@hidden> wrote:
> # 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?

I understand that Plash does not attempt to confine anything, Plash
does not limit the app's ability to communicate over IP. Rather, Plash
only limits access to the local file system. Confinement does not seem
to be a priority of current Plash development, although one could
probably use systrace to work around this problem.

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

Yes. Also I fear that the AppArmor behavior is not correct in this
regard. If we simply disallow access to inodes that have 2 or more
hard links, we are still vulnerable to a data leak if someone hard
links a confidential file into a shared directory and waits for the
original to be deleted.

I would like to sketch a proposal that is somewhat over-engineered,
but should allow links to work the way cap people think they should,
without breaking too many existing programs or needing a kernel patch:

We start by always making note of by which authority a link is made.
E.g. say I type
  ln -s X Y
Then we add a entry to ~/.authorised_links. It is the responsibility
of the user to ensure this, perhaps by adding an LD_PRELOAD to their
.bashrc.  Whenever I run "plash Y", plash follows the link Y because
plash is acting on my authority and thus trusts my links. Furthermore,
if a constrained program that has full rw authority to path X, then
again we add this entry to ~/.authorised_links. IF, OTOH the program
has only read (or write) access to path X, then the link is still
added to ~/.authorised_links but with a restriction that it can only
be used to grant read (or write) access.

Furthermore, links are always trusted by the processes that create
them, and by child processes that start with strictly less rights.
Optionally, an application FooBar can store links it considers trust
worthy in ~/.foobar/.authorised_links.

Handling hardlinks is tricky, we'd either have to identify files by
inode (which is fragile if you need to do a backup/restore) or making
another hardlink for every file.

The file .authorised_links is also updated appropriately whenever a
link or directory is moved.

--
John C. McCabe-Dansted
PhD Student
University of Western Australia