Re: [PATCH] remove sys_security

From: Valdis.Kletnieksat_private
Date: Fri Oct 18 2002 - 08:14:14 PDT

  • Next message: Christoph Hellwig: "Re: [PATCH] remove sys_security"

    On Fri, 18 Oct 2002 14:05:43 BST, Christoph Hellwig said:
    > All three are actually very good examples on how your "Security"
    > modules work around problems instead of fixing thev actual cause.
    
    OK.. I'll grant that a lot of things done here are fixing the fact that
    there are some really fundamental botches in the Linux kernel, such as
    the fact that there isn't a long history of Posix-capability flavor
    separation (so processes need to start as root just so they can bind
    a low-number port - blech).
    
    Would fixing *ALL* of that history (and all the userspace crap that has
    grown on top of it) be *LESS* invasive/disruptive than what LSM does?
    
    Do you have a projected timeline of when this mythical "all the warts in the
    kernel are fixed and all the userspace cruft is cleaned up" world will happen?
    I'd like some sort of reasonable estimate, so I know whether this will be
    before or after I retire. (While we're at it, can we reverse the definition
    of the 'r' and 'x' permissions on directories, so 'umask 037' doesn't result
    in directories with borked permissions?  I'm actually somewhat serious here -
    this is the sort of thing that will need to be cleaned up and fixed all over
    the place...)
    
    > Instead of adding hacks for tempfile races you rather want to
    > give each user a private namesapace and it's own /tmp (IMHO
    > we should also get rid of symlinks entirely, but they're in too wide
    > use nowdays unfortunately).
    
    Symlinks are in too wide use, and too much code knows about them - yes,
    it might be nice if we threw symlinks out the window and replaced them with
    a union-mount scheme.  But would that be any less disruptive than what LSM does?
    
    > And ptrace _really_ _really_ needs to be replaced by a sane debug
    > interface,  like the plan9 procfs-based debugging.
    
    Yes.  But would that be less disruptive than what LSM does?
    
    > But instead of attaking these causes security folks like wirex just
    > implement fuzzy busword mechanisms that are selable to managers.
    
    The part you're missing here is that the "fuzzy buzzword mechanism" is
    deployable *NOW*, and will provide *real benefits* *NOW*, rather than having
    to wait for the 2.7 or 3.1 or whatever kernel.
    
    And before you go off on the "but a lot of these can be circumvented" tangent,
    I'll point out that almost *NOTHING* is totally secure.  Yes, there are a
    number of ways to defraud my bank.  This doesn't mean that my bank is remiss
    in making sure that *one class* of attacks (for instance, physical attacks
    on ATM machines) isn't sufficiently protected against.  Yes, my signature
    can be forged - but my bank still has a signature card on file.
    
    Which is more easily sellable to managers:
    
    1) "We could deploy extended attributes and ACLs, except that they're not
    supported yet on the filesystem that would otherwise be most suited.  Once
    they're integrated into that filesystem it will be great, but we're not sure
    which release of the kernel it will happen in, or when that will be. And once
    it DOES get supported, we don't have any guarantee that some clever person
    won't find a way around the permissions that the kernel maintainer(*) isn't
    allowed to explain to us, like we've seen at least once already that we know
    of.  Oh, and if the facilities provided don't match our business model,
    we're stuck maintaining local patches or changing our business model".
    
    2) "We could deploy an LSM module, that will work no matter WHAT filesystem
    we're using. It's there for the current kernel, and although there's always
    the chance that some clever person will find a way to end-run our module and
    bypass it, it's equally likely that the same clever person will find some
    OTHER silly bug elsewhere in the kernel that lets them bypass everything.
    Oh, and we can tailor the restrictions to fit *OUR* business model and the
    threats *we* feel are important."
    
    (*) Apologies to Alan Cox here - I actually think he did The Right Thing, and
    the actual bugs weren't his fault. The point here is that we've seen a *LOT*
    more security problems caused by simple *BUGS* than we have by any hypothetical
    "the LSM model doesn't secure 100% of the cases, so it's breakable and totally
    useless" problems.
    
    -- 
    				Valdis Kletnieks
    				Computer Systems Senior Engineer
    				Virginia Tech
    
    
    
    

    _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module



    This archive was generated by hypermail 2b30 : Fri Oct 18 2002 - 08:15:52 PDT