Messages in this thread | | | From | (David Wagner) | Subject | Re: RFC: disablenetwork facility. (v4) | Date | Sat, 2 Jan 2010 06:28:04 +0000 (UTC) |
| |
Eric W. Biederman wrote: >daw@cs.berkeley.edu (David Wagner) writes: >> When you talk about DOS, let's be a bit more precise. disablenetwork >> gives a way to deny setuid programs access to the network. It's not a >> general-purpose DOS; it's denying access to the network only. And the >> network is fundamentally unreliable. No security-critical mechanism >> should be relying upon the availability of the network. > >The audit daemon should not rely on netlink?
auditd is not a setuid-root program. It is launched at boot time. (If that's what you're referring to.)
I'm personally not very worried about attacks on a setuid-root program that leave it unable to log messages to the audit log. I personally find it hard to get very concerned about that scenario. And if there is a setuid-root program where it is absolutely vital that the log messages get through, then the setuid-root program probably ought to be checking return values and acknowledgements anyway, regardless of whether disablenetwork is in place or not.
>For me the case is simple. I have seen several plausible sounding >scenarios that get most of the way there. I know I am stupid when >it comes to security and that people exploiting problems are going >to be looking harder than I will. Therefore I think there is >a reasonable chance this will introduce a security hole for someone.
OK. I'm not opposed to introducing some way to disable setuid execution, to give folks a greater comfort level. I still am not convinced it's necessary (I personally suspect it to be unnecessary), but if it is the necessary political compromise to enable the Linux kernel to better support privilege separation and sandboxing, so be it. Whatever it takes to get that support in place is worthwhile. So, thank you for working out how to implement such a mechanism!
| |