Re: Electrolysis security

If you have a good reference for the Windows file security model I'd  
love to read up some more on it, as I haven't haven't found too many  
conclusive references on the risks/implications of passing file  
handles, esp. among processes of dramatically different privilege  
levels (other than kernel -> userland, which is where we've actually  
seen bugs with stdin/stdout/stderr).

Regarding the point below, I said there it would reduce platform- 
specific code in the content process, which means we don't end up with  
multiple copies of that around.  Regarding context switching, we are  
already serializing so much stuff across IPC (pretty much all security  
sensitive stuff EXCEPT file access) that serializing file uploads will  
not have a significant impact.  It would remove a lot of potentially  
tricky platform-specific code from the content process which is a good  
thing.

In some respects I feel like we're trying to address the same problem  
from different angles.  From a defense-in-depth standpoint, we want to  
prevent access to natives files, sockets, libraries, and other  
sensitive resources by content processes except where explicitly  
permitted by the chrome process.  Since the proposed model involves  
passing native file handles/descriptors, it requires the content  
process to have access to all of the usual file I/O libraries and  
prevents us from trying to whole-sale break those, and rely instead on  
ensuring that content processes can't load anything by direct or  
indirect references, can't import libraries that would allow them to  
do so, etc.  Now it may not be possible to disable these wholesale  
because, as Zack mentioned, a bunch of libc assumes access to certain  
public files.  But its a worthy goal. :)

My take-away from the chrome security model is that identifying and  
patching the various libraries to prohibit access to bad stuff is a  
painful game of whack-a-mole.
   Lucas.

On Aug 20, 2009, at 10:46 PM, Rob Arnold wrote:

> On Thu, Aug 20, 2009 at 4:40 PM, Lucas Adamski <[email protected]>  
> wrote:
>
> 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
>
> These are all unix file descriptors - NT uses a common object  
> manager for checking permissions and ensuring the validity of  
> handles to operating system objects. I'm not saying that there are  
> no security holes, but given that the code path is used quite  
> frequently (moreso than unix file descriptors), I would be surprised  
> if there are still OS level issues that cannot be solved by more  
> careful application-level checks (ex: sharing access to symlinks).
>
> 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
>
> I'm not a fan of reinventing the wheel. Again, for what it's worth,  
> those papers deal with unix file descriptors which operate  
> differently that Windows handles. We may need to take separate  
> approaches (what does Chrome do?).
>
> I suggest that you read up on the Windows file APIs/kernel design -  
> it's quite informative. Files are a type of Executive (kernel if you  
> will) objects. Processes access objects through handles - each  
> process has its own handle table. Handles can be duplicated (similar  
> to dup) with a different set of permissions from one process to  
> another (including itself). A child process can also inherit its  
> parents handles if both of the following apply:
> a) the handle is marked as inheritable (most code defaults to false  
> here, including ours)
> b) The child process is created with a flag that says it gets to  
> inherit handles.
>
> We would most likely be using the first method (DAC), opening the  
> file in the content process as readonly, then duplicating the handle  
> to the child, stripping all rights except for reading (the child  
> process can close the handle, but the object is refcounted in the  
> kernel).
>
> I don't know how you'd perform that on unix-based systems but in the  
> event we cannot, we shouldn't penalize performance on the OS with  
> the largest Firefox marketshare to workaround those limitations.
>
> 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.
>
> It's not clear to me how an operating system can let a process use a  
> file descriptor to a file to scribble over or read from the entire  
> disk and claim to be stable/secure - we should not support such  
> systems.
>
> On Windows, it is not possible to perform low level disk writes  
> without being an Administrator - a UAC prompt may even be involved.
>
> I'm not sure how we would consider denial of service attacks via  
> disk I/O from the content process - do you know of any papers on this?
>
> 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).
>
> Giving the child process a native file descriptor lets us avoid  
> excessive context switching and context switches are not cheap. I  
> don't see how there's a reduction in platform specific code - it's  
> either in the content process or the master process. This  
> indirection will actually add more code. Why not let the OS do it's  
> job? I'm not convinced that we should try to rewrite the wheel when  
> there are existing solutions to this problem.
>
> 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.
>
> If we go that route, then yes. Why not mimic what the OS does for  
> file descriptor numbers or process ids? OpenBSD is particularly  
> paranoid and uses a secure random numbe
>
> -Rob