Messages in this thread | | | From | (David Wagner) | Subject | Re: [PATCH 2/3] Security: Implement disablenetwork semantics. (v4) | Date | Mon, 11 Jan 2010 01:29:43 +0000 (UTC) |
| |
Pavel Machek wrote: >Scenario 2: > >Mallory calls disablenetwork, calls sendmail as the first user after >boot; sendmail can't deliver anything (its network is disabled), but >starts forking and taking requests for other users, DoSing the mail >delivery.
On my system, sendmail is started by trusted boot scripts before a "Mallory" would have a chance to do that, so the premise does not apply. I cannot guarantee this is the case on every system, but I'm not familiar with any important exceptions.
>Scenario 3: > >Mallory calls disablenetwork, then keeps hammering on su, knowing that >su can no longer send data to audit subsystem and so he will not get caught.
And then what? I don't see how this gets Mallory very far. She can keep hammering on su and keep getting denied access to root, and it's not going to help her much.
(Note: If root's password is guessable, then there's a fair chance you're screwed even without disablenetwork. If root has a guessable password, then Mallory can keep trying until she guesses right, then when she gets it right, go and retroactively edit the logs to eliminate the log entries if necessary -- if those log entries are ever looked at, which is often dubious. It's very difficult to build a secure system if the root password is guessable. So in my opinion, the root password must be unguessable if you want to have a secure system, and we should analyze disablenetwork under the assumption that sysadmins have done so. And if the system administrators do choose an unguessable password, then your Scenario 3 doesn't seem to help Mallory.)
The impact here seems pretty minor.
>You can trivialy make disablenetwork disable setuid exec, too. That >will introduce better isolation facilities, but not introduce any new >security problems.
Yup, this is probably the compromise that must be made, for political reasons, to get this into the kernel.
But I just want to document that it's not clear to me that this decision is well justified on technical grounds.
| |