Re: Electrolysis security

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

Also you can't downgrade a read-write fd to read-only, but we wouldn't
be opening files read-write in the first place when we only want to
read them.

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

---

I really don't think we have to worry about passing bare fds to
content processes on Unix.  Assuming no kernel bugs -- and we have to
assume no kernel bugs, or all bets are off anyway -- there just isn't
that much that can be done with a read-only file descriptor on a
regular file.

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.

zw