Re: permissive vs. restrictive issue and solutions...

From: Casey Schaufler (caseyat_private)
Date: Fri Jun 01 2001 - 10:09:30 PDT

  • Next message: jmjonesat_private: "Re: permissive vs. restrictive issue and solutions..."

    Crispin Cowan wrote:
    
    > Another option we discussed in a meeting this afternoon was "kick capabilities
    > out".  All of the security modules we (WireX) understand are "restrictive",
    > and only capabilities is "permissive". If we kick capabilities out of the
    > picture, LSM gets simpler.
    
    A fundimental part of any security policy is the conditions
    under which it may be violated. This never shows up in the
    policy definition, but is the first thing that application
    developers (and the 0th thing sysadmins) ask about. If you
    kick out capabilities (that would interfere with Casey's
    Evil Plan for World Domination, BTW) you're going to have
    just as much fun replacing it with some other "general"
    scheme. If you like, you can (and some of y'all do)
    look at the capable() call as the vangard of the LSM effort. 
    
    > "Kick capabilities out" also comes in two flavors.  One is to leave it in the
    > kernel, rather than make it an LSM module.
    
    Since any privilege mechanism is going to be tightly
    tied to the policy (you don't need to have privilege
    in the "everything succeeds" policy) the LSM is the right
    place for it, be it Superuser, capabilities, time of day,
    or dual key override.
    
    > The other is to kick it right out
    > of Linux, because the POSIX standard has failed,
    
    It's made its way, more or less, into every commercial U2X
    system available today. All it needs is the requisite O'Reilly
    Book to be an acknowledged success.
    
    > support for Capabilities in Linux is lame,
    
    True today. With extended attributes available Real Soon Now
    that issue can be addressed. 
    
    > and we think it sucks anyway :-)
    
    And setuid doesn't :---o 
    
    > As with some other options,
    > this may be a hard sell.  But I think it deserves serious consideration.
    
    You're right. I say that getting it into LSM provides the
    best mechanism for making any decisions implementable,
    from nuke it to complete it.
    
    -- 
    
    Casey Schaufler				Manager, Trust Technology, SGI
    caseyat_private				voice: 650.933.1634
    casey_pat_private			Pager: 888.220.0607
    
    _______________________________________________
    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 Jun 01 2001 - 10:11:38 PDT