Messages in this thread | | | From | (David Wagner) | Subject | Re: [PATCH 2/3] Security: Implement disablenetwork semantics. (v4) | Date | Mon, 11 Jan 2010 01:21:08 +0000 (UTC) |
| |
Michael Stone wrote: >Pavel's position is that disablenetwork is likely to permit some attacker >somewhere to deny network access to some setuid app some day in a way that >violates some security policy. > >He has mentioned specific concern over scenarios like: > > Alice configures PAM auth to 'fail open' by checking login credentials > against a restrictive LDAP server and, if the server is unavailable, against > a very permissive files database. > > Alice updates her kernel to a version with disablenetwork. > > Mallory calls disablenetwork, calls su -, and vanquishes all. > >My position is that better isolation facilities like disablenetwork will >prevent far more grievous security faults than they (theoretically) cause. > >What is your perspective on the matter?
I agree with you. As I've mentioned before, I think it's an unconvincing objection. If Alice sets such a poorly thought-out security policy, then there are probably many other ways to attack the system, even if you don't introduce disablenetwork. (Example atttack #1: Use rlimit to set the number of file descriptors that can be opened very low, then call su -. Example attack #2: DOS the LDAP server, and then call su -. There are probably many more.)
But it's also true that it's possible to achieve many of the benefits of disablenetwork in a way that avoids introducing the potential risks that Pavel is concerned about. If that's the political compromise that it takes to get disablenetwork into the kernel, that's still a step forward. It'd be better than what we have today.
| |