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


    \
     
     \ /
      Last update: 2010-01-11 02:23    [W:4.290 / U:0.060 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site