Re: Electrolysis security

Lucas Adamski <[email protected]> wrote:
> 
> Doesn't the model above require file access privileges for the
> content process?  It seems like a restricted process shouldn't be
> able to write to the FS even with a valid handle as that would seem
> to imply low-level access to the underlying FS.  

I don't know from Windows, but in Unix, a read-only file descriptor
passed over a local socket to a process with otherwise restricted
access to the file system can't be used for anything but reading that
one file.

("Otherwise restricted access to the file system" is the hard part,
unfortunately.  chroot() and setuid() are privileged operations, and
taking away access to /lib and /dev will break basic stuff.  Linux
(specifically) lets you deduce the *name* of a file from its file
descriptor number if you can get at /proc, and you might be able to
guess the names of other files in the same directory and gain access to
them, from that.)

> At minimum it seems
> to invite escalation of privilege attacks.  A better model might be
> for the broker process to handle the file I/O on behalf of the
> content process using a randomly generated file reference that is not
> an underlying file descriptor; something strongly coupled to that
> particular content process (to prevent rogue processes from trying to
> brute force other file references).

This doesn't make a whole lot of sense to me given that file
descriptors are meaningful only in the context of a particular process.
You can't brute force them.

zw