[cap-talk] [Apparmor-dev] [ANN] FastRPC, a continuation of imsep

[Mark Seaborn]

Crispin Cowan <crispin at novell.com> wrote:

> John McCabe-Dansted wrote:

> > A common requirement for GUI apps is that they must be able to access
> > any document opened in the file open dialog box. The traditional way
> > of doing this is to allow to all apps to access all files in
> > ~/Documents/ (or even ~/). As with Polaris, Plash only gives access to
> > those files opened in the file open dialog box. Unlike Polaris, Plash
> > works by passing in a FD for the files rather than copying files
> > around. This has obvious advantages for large files and concurrent
> > access.

> That is an interesting example. You are providing very tight confinement
> to the specific application, and very loose confinement to the GUI for
> opening things (assuming the GUI is a process and not a library).

Yes, the file chooser dialog box is implemented in a trusted process.
This kind of file chooser is known as a powerbox, by the way.

> On the other hand, AppArmor can achieve a different tightness of
> security by permitting the spreadsheet application to only be able to
> open /home/*/**.xls and the word processor to open /home/*/**.doc. The
> GUI could not do this, unless it had deep application awareness and knew
> to only delegate .doc files to the word processor and .xls files to the
> spreadsheet application.

This is not very useful for a program like a mail client, which you
might use to send any type of file as an attachment.  Then it has to
have access to all my files -- not great for a program that is
routinely exposed to data downloaded from the Internet.


> > We know that this "bug" cannot be
> > exploited, because if the process that fopen()ed the file was
> > untrustworthy, we are already lost*.
> I roll to disbelieve this claim ...
> 
> Process A is my mail client. Process B is my word processor. Now suppose
> that there is a vulnerability that permits arbitrary FD delegation in
> the mail client, and that the word processor is something like MS Word 6
> and is completely vulnerable to macro malware. Dr. Evil sends me a mail
> such that, without protection, causes the mail client to open the
> address book, pass the FD to the word processor, which runs the macro
> malware and spams everyone in my address book with the virus.

I don't see why the word processor has to be involved.  The mail
client has enough authority -- access to your address book and the
ability to send out e-mails -- to do these things.  If the mail client
has a vulnerability (e.g. buffer overrun) that lets malware take over
all its authority, the malware would not need to exploit the word
processor.


Are you talking about a case where the e-mail client opens the address
book file and forgets to either mark the FD as close-on-exec or close
it explicitly before invoking execve() to launch the word processor?

In this case, it goes back to the first question I asked, which was:
are you trying to protect against accidental or deliberate delegation
of file descriptors?  This is an example of accidental delegation.

In this case, a better solution would be to fix the mail client so
that it does not delegate excessive authority.

In my opinion, it was a mistake in Unix's semantics for file
descriptors not to be marked as close-on-exec by default.  It would
make better security sense to have to explicitly list the FDs that
*are* to be passed across execve(), rather than those that aren't.

It's too late to fix that now, but we could fix the mail client's
behaviour by making it invoke the word processor via a wrapper program
which closes all FDs except std{in,out,err}.


> If I use static privileges, I can create a static profile for the mail
> client that permits it to only access ~/Mailbox and ~/tmp, and create a
> special helper profile for the word processor when run as a child of the
> mail client. The helper profile is only permitted to read and write in
> ~/tmp. When I open Dr. Evil's mail and then open the attached .doc file,
> I save it into ~/tmp and then open the word processor in the helper
> profile. The word processor runs the macro virus, tries to get to the
> address book, but cannot because the helper profile has no access to
> ~/Mailbox.
> 
> If I used delegable FDs, then the attack against the mail client can
> cause an FD to be delegated to the word processor that gives the word
> processor access to my address book, permitting massive spread of the virus.

Why doesn't the attacker just get the mail client to copy the address
book into ~/tmp, where it can be read by the word processor?

Cheers,
Mark