Re: Electrolysis security

On Aug 18, 2009, at 6:55 PM, Zack Weinberg wrote:

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

I'm not too familiar with file descriptor security issues (as that's  
generally a domain of local elevation of privilege exploits and  
traditionally more of an OS-security problem), but it seems like we  
have a few area of concern here:

a) file descriptors have been at the root (no pun intended) of several  
local escalation of privilege vulnerabilities, such as:
http://www.net-security.org/advisory.php?id=2593
http://www.securiteam.com/unixfocus/5SP0N157FK.html
http://www.derkeiler.com/Mailing-Lists/Full-Disclosure/2007-01/msg00344.html

b) file descriptors can be implemented differently on different  
platforms; exposing it directly means we give up control and are at  
the mercy of platform implementations (and I'm not sure how we'd even  
do that on Windows).  There has been enough recent work around  
properly securing file descriptors to make me pretty nervous:
http://udrepper.livejournal.com/20407.html (I don't think his browser  
and plugin example is super relevant but the point is file descriptors  
are tricky from a security standpoint)
http://www.nsa.gov/research/_files/selinux/papers/module/x92.shtml#FDPERMSCHANGES

c) defense-in-depth and minimizing privilege: we should not expose low- 
level OS primitives to content processes where avoidable; in  
particular for filesystem access where paranoia is advisable.    In  
particular I'm not clear on how a process could receive permission to  
access a specific file without also exposing the rest of the OS to  
attack either directly or via low-level disk writes.  Given one of the  
primary goals of electrolysis security is to protect the filesystem  
from remote content we shouldn't over-optimize here.

Since we are serializing graphics constantly it seems like a minimal  
performance hit to serialize all file I/O as well.  Doing so will  
reduce platform-specific code in the content process, provide  
significant defense in depth and might even provide performance and  
stability benefits (since the chrome process will be in a better  
position to clean up any open files and other resources left behind a  
crashed content process).


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

If we serialize all file I/O we will need to provide some sort of file  
ID back to the content process; my point is that ID should be tied to  
the content process and not brute-forceable.

> zw