Re: [RFC][PATCH] Add LSM sysctl hook to 2.5.59

From: Russell Coker (russellat_private)
Date: Mon Jan 20 2003 - 04:52:17 PST

  • Next message: Crispin Cowan: "Re: [RFC][PATCH] Add LSM sysctl hook to 2.5.59"

    On Mon, 20 Jan 2003 03:51, Crispin Cowan wrote:
    > >I don't think that would do for my chroot environments.  I want to have
    > > root owned processes running in a chroot with no ability to escape or to
    > > affect the outside environment (and proc is mounted in the chroot).
    >
    > Christoph's objection is that each module would have to list all the
    > sysctl variables. Can the hook be modified so that a module need only
    > decide whether or not the subject process can call sysctl?
    
    That would be a bare minimum of functionality, it would suffice for some tasks 
    but not for others.  You could just as easily say "could we have file system 
    access controls that need only decide whether the subject process can write 
    to disk"...
    
    As for listing all the sysctl variables.  It's not necessary to list them all, 
    just list those that require special attention.  EG Make them all read-only 
    by default and then list the ones that need different access levels.
    
    > Or, somewhat more fine-grained, could we use the approach of opaque
    > security blobs and pushing work back onto modules that want stuff. If a
    > module wants to get more particular about what kinds of sysctl
    > operations are permitted, let that module embed that information in the
    > per-process opaque blob, and block the sysctl if it is not appropriate.
    
    That idea sounds like it might do what I need.  Steve will have to comment on 
    the practicalities of implementing it of course.
    
    For SE Linux we want to be able to control different sysctl options 
    separately.  So a UID=0 process should be able to have write access to one 
    sysctl, read-only access to another, and no access to a third.
    
    Your message was not entirely clear to me, but I get the impression that it 
    means just providing all relevant information to the security module (SE 
    Linux in this case) and letting it decide what to do next.  But how does that 
    really differ from what we have now?
    
    -- 
    http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
    http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
    http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
    http://www.coker.com.au/~russell/  My home page
    
    _______________________________________________
    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 : Mon Jan 20 2003 - 04:53:46 PST