David Malcolm <[EMAIL PROTECTED]> 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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list