Andrew Lentvorski wrote: > James G. Sack (jim) wrote: >> from a lwn link, this is interesting stuff about security aspects of >> file descriptors. The scenario painted by Drepper about a browser plugin >> is a convincing justification of recent kernel changes and recommended >> practices regarding use of close-on-exec. >> >> Ulrich Drepper (udrepper) wrote, >> @ 2008-08-01 16:24:00 >> Secure File Descriptor Handling >> http://udrepper.livejournal.com/20407.html > > Okay, that's a bit scary. > > I know that they say they've closed this, but doesn't this mean that > every single UNIX out there is susceptible to this? > > In addition, I hate to say it, but doesn't this really indicate that the > whole fork/exec/signals system is architecturally broken with respect to > security and that you simply *shouldn't use them at all* if you can? > > Finally, the solution requires active effort to move from "default > shared" to "actively unshared". It is always a bad idea to be "insecure > by default". There should be a system call that is "Only share the > resources I choose to give you." Does that exist? > > I wonder how the OpenBSD guys are going to react to this? It looks like > they made FD_CLOEXEC changes several years ago; however, this really > looks like a far-reaching architectural issue. >
Your questions seem like they deserve answers! And/or should we audit every fork to check that unneeded fds are immediately closed? Regards, ..jim -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
