Messages in this thread | | | Date | Mon, 11 Jan 2010 09:58:52 +1100 (EST) | From | James Morris <> | Subject | Re: [PATCH 2/3] Security: Implement disablenetwork semantics. (v4) |
| |
On Sun, 10 Jan 2010, 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?
Unexpected failure modes for privileged apps using security interfaces has already proven to be a problem (e.g. the sendmail capabilities bug), so it seems prudent to try and mitigate that as well. I don't think we need to look at this as an either-or situation -- it seems we can do both, and get something useful in its own right from the mitigation.
-- James Morris <jmorris@namei.org>
| |