Re: Call-return interface for file choosers? (and: security using powerboxes)

[Mark Seaborn <mseaborn onetel com>]

David Malcolm <dmalcolm redhat com> wrote:

> How about a slightly different interface where you work with
> buffers/memory mapped files/file handles/something other than filenames?
> This way the application doesn't need to be able to open the user's
> files for reading/writing; the trusted executable can do this for it.
> 
> A naive interface might be something like this:
> gboolean foo_open_file (void **return_buffer, size_t *return_size);
> gboolean foo_save_file (void *content, size_t size);
> which could internally handle the necessary IPC; though obviously this
> needs work so that it doesn't block the application's redraws etc etc.

Yes, this is similar to how Plash works internally.  Plash has file
objects, and you can pass a reference to a file object between
processes.  Plash implements the POSIX API in terms of these file objects.

A file object has an "open" method which returns a file descriptor for
reading or writing the file.  The interface you're suggesting removes
the need for passing file descriptors.  That would be advantageous
because kernel-level file descriptors are not revokable (which could
be fixed if the kernel provided a way to create revokable proxies for
FDs).  On the other hand, it might have worse performance, but this
probably wouldn't be serious if it was limited to a
read_whole_file()/write_whole_file() style interface.

The reason for using filenames is just that programs are written to
use filenames.  I'm trying to get programs to use the powerbox with
the minimum changes possible.

Later on, it would be good if programs were changed to use object
references for files instead of filenames.  This can help solve some
problems.  It makes it easier to determine when the right to access a
file should be transferred to another process.

Using object references is better when you're trying to write a
program that must deal with requests on behalf of multiple
mutually-untrusting parties.  This is why setuid programs have
traditionally been hard to write correctly: When a setuid process uses
a filename, the OS checks whether the process as a whole has
permission to access the file, not whether the filename came from a
source which could access the file.  So you can often fool a setuid
program into misusing its authority.  This is known as the "Confused
Deputy" problem.  It can be solved if you use object references for
files where the right to access the file is bundled with the object
reference.


> Have you also thought about drag and drop from file managers?  When
> someone drags a file to your untrusted application, the application
> receives a URL, but it needs some kind of permission to read the file as
> well.

Yes, eventually doing drag-and-drop with a file should transfer the
right to access the file.  Drag-and-drop is a really good user
interface for transferring authority.

There are some complications though.  I think the X drag-and-drop
protocols rely on X's lack of security.  We're going to have to limit
applications' ability to send X messages to each other.  It may be
necessary to create a new drag-and-drop protocol, and change apps or
libraries to use it.  Or it may be possible to handle this entirely in
an X proxy, if that is how X access control is going to be achieved.


> > Suppose you run Gnumeric to view a spreadsheet you downloaded from the
> > Internet.  Gnumeric might not be a malicious program, but suppose it
> > has a buffer overrun bug (quite possible considering it's written in
> > C), and the spreadsheet exploits that bug.
> 
> IMHO Evolution is a better example; it's constantly working with data
> from the network, and you rarely need to deal with arbitrary
> user-readable files (creating attachments is one of the few cases)...
> and it's written in C.

Good point.

Cheers,
Mark