On 8/20/09 4:40 PM, Lucas Adamski wrote: To clarify a few things:
I have been using "file descriptor" loosely. On Windows I mean a HANDLE, and on *nixy systems an actual file descriptor. (On Windows a POSIX file descriptor is a wrapper around a HANDLE). > 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 File descriptors are a core part of OS operation. The IPC mechanism works at all by opening a socketpair file descriptor in the parent process and sending that to the child process, and then file descriptors for additional sockets/pipes/anonymous memory mappings are duplicated to the child process so that it can communicate with the parent. I'm not sure that we should, or can, try to guard against this style of OS security breach. > 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) We do have to guard against unintended file descriptors being available to the child process, but that's beside the point of whether we intentionally grant the child process access to files by duplicating a fd/handle to it. The child process doesn't fork additional processes, so there is not a chance of it leaking fds to other processes. > 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. How not? On Windows, access checks are performed at the time you create/open a HANDLE. So to grant access to a specific file, the chrome process creates the handle with appropriate permissions (readonly access) and then duplicates that handle to the child process. The same basic mechanism is used on Linux/Mac with unix domain sockets. > 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). We are not going to "serialize graphics constantly". We are going to use anonymous mapped memory (based on file descriptors or handles) to ship large network and graphics data between processes. Granting access to specific other handles isn't going to be more risky. Since the file handle is managed by the OS, a crashed process won't hold a file open. >>> 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. What ID? You mean like the actor ID of the messages going back and forth? Those are just integers assigned to particular message endpoints. I don't see how that's any more or less random/guessable than a handle or file descriptor. And the guessability shouldn't matter anyway, since you're only "leaking" information that you're already intentionally granting to the process. --BDS _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
