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.
-a
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
