Messages in this thread | | | Date | Mon, 28 Dec 2009 01:07:59 -0500 | From | Michael Stone <> | Subject | Re: RFC: disablenetwork facility. (v4) |
| |
Pavel Machek wrote: > "I can't see" is not strong enough test, I'd say. > > For example, I can easily imagine something like pam falling back to > local authentication when network is unavailable. If you disable > network for su... > > It would be also extremely easy to DoS something like sendmail -- if > it forks into background and then serves other users' requests.
Pavel,
I spent some time this afternoon reflecting on the scenarios that you sketched above. This reflection resulted in three concrete responses:
1. Anyone depending on their network for authentication already has to deal with availability faults. disablenetwork doesn't change anything fundamental there.
2. Anyone able to use disablenetwork to block a privilege escalation via su or to influence sendmail will be able to disrupt the privilege escalation or mail transfer by manipulating the ancestors of su or sendmail in plenty of other ways including, for example, via ptrace(), kill(), manipulation of PATH, manipulation of X11 events and IPC, manipulation of TTYs, and so on.
3. As I pointed out before, disablenetwork _is_ controlled by a build-time configuration option, its use _is_ still subject to any existing MAC policy, and it _is_ easy to control for simply by talking to a known-unrestricted process over an unrestricted IPC channel like a Unix socket.
and a short meta-response:
As I see it, the whole point of isolation facilities like disablenetwork is to convert _nasty_ faults like secrecy and integrity faults into _local_ availability faults. Consequently, it is completely unsurprising that we can't meet stringent availability goals via isolation without either relaxing our other security goals or falling back to strong assumptions about the state of our initial environment.
However, we should not therefore ignore the bottom line which is that the additional isolation enabled by disablenetwork represents an excellent security risk/reward tradeoff for many people and should be made more widely available to these people on these grounds.
Regards,
Michael
P.S. - Thanks again for your assistance in thinking through these scenarios and in refining the security case for the disablenetwork feature.
| |