Comments | udrepper: Secure File Descriptor Handling

udrepper

Secure File Descriptor Handling

Aug 01, 2008 16:24

During the 2.6.27 merge window a number of my patches were merge and now we are at the point where we can securely create file descriptors without the danger of possibly leaking information. Before I go into the details let's get some background information.

A file descriptor in the Unix/POSIX world has lots of state associated with it. One bit ( Read more... )

programming security linux

Comments 2

Example? anonymous August 3 2008, 21:48:40 UTC

Hi, I'm a bit confused about how the vulnerability here is supposed to work. Could you provide a small example schedule of concurrent syscalls that would illustrate the problem? Thanks in advance!

Re: Example? udrepper August 4 2008, 15:55:54 UTC

I'm a bit confused about how the vulnerability here is supposed to work. Could you provide a small example schedule of concurrent syscalls that would illustrate the problem?

I thought I explained it sufficiently. Apparently not. There are two scenarios, both of which can and do happen widely. Most obviously is the multi-thread code:

Thread 1Thread 2 New process

fd = open(...)
fork()
fcntl(fd, F_SETFD, FD_CLOEXEC)
execve(...)

The new process inherits all the open file descriptors without close-o-exec set. Just look at, for example, your web browser. This scenario probably happens dozens of times a day in there.

But one doesn't need threads. It can happen in a single-threaded application as well.

Normal CodeIn Signal handler New Process

fd = socket(...)
fork()
fcntl(fd, F_SETFD, FD_CLOEXEC)execve(...)

fork() is a signal-safe function and can be called from a signal handler. Therefore the above can at any point in time happen. And just because your program doesn't use it doesn't mean it cannot happen: a ( ... )