Re: Electrolysis security

On Thu, Aug 20, 2009 at 11:49 PM, Zack Weinberg <[email protected]>wrote:

> Rob Arnold <[email protected]> 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).
>
> The statement that NT file handles are used "more [frequently] than
> Unix file descriptors" seems very implausible to me.  If anything I
> would have expected it to be the other way around; you can't hardly do
> anything in the Unix kernel-level API without a file descriptor,
> whereas the lower level NT APIs (to the extent that I understand them)
> have dozens of different kernel objects that they hand around.


I meant that NT object handles are used more frequently than file
descriptors. NT uses objects for more things than just files and file-like
objects: events, desktops, threads, processes, etc... You can't do that much
without them, most services use an (A)LPC object to communicate with
processes.

The access checks for obtaining handles and using them is centralized too,
so I think that would mean it's been fairly well tested.

> 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.
>
> This is *exactly* the nature of Unix file descriptors, except that fds
> are inheritable by default -- that's what Drepper's stuff is about,
> ensuring that every fd can be non-inheritable from the moment of its
> creation.  This is a concern only if the chrome process is the parent
> of the content processes, which it doesn't have to be; there could be a
> separate manager process that is the parent of both.  Which would
> probably be a good idea anyway.


Agreed. That should significantly lessen the risk of leaking file
descriptors and other resources.


> > 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.
>
> The equivalent is to open the file read-only and then transmit it to
> the content process with a SCM_RIGHTS (iirc) message on a local domain
> socket.


Thanks. Is there a good source of documentation on these APIs? I'm looking
for an equivalent to MSDN. Bonus points if it covers other unixes.


> I'd be much more worried about finding ways to disable
> socket(AF_INET, ...) and friends, and to cut off access to most absolute
> paths without breaking the C library.


Right. This is a challenge on Windows (XP only I think) too. Once all the
shared libraries are loaded, is there any reason that we can't chroot the
child process (on unix...Windows doesn't have chroot)?

-Rob