lkml.org 
[lkml]   [2010]   [Jan]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: RFC: disablenetwork facility. (v4)
    Date
    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!


    \
     
     \ /
      Last update: 2010-01-02 07:31    [W:0.027 / U:0.364 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site