Re: Basic questions about LSM architecture.

From: rhys tucker (rhystuckerat_private)
Date: Sun Nov 25 2001 - 07:36:37 PST

  • Next message: Greg KH: "Re: Basic questions about LSM architecture."

    I'm very grateful for your replies, I think that I'm getting there now. 
    
    It seems that LSM initially has a dummy security module that the global
    security_operations structure points to, and which enforces traditional
    superuser logic. The first security module overrides the dummy module by
    redirecting security_operations to itself. Security modules may
    implement different security polcies and may be stacked i.e. SELinux,
    capabilities and DTE security modules may be in effect at the same time
    (although I don't know if such a configuration is sensible).
    
    More simple questions -
    
    Does the 'Primary Security Module' refer to a particular and specialised
    security module or simply to the first security module to be loaded?
    
    Does LSM use the traditional LKM mechanism i.e. are security modules
    simply LKMs that interact with the LSM framework or are they something
    different? 
    
    thanks again
    
    rhys
    
    
    Chris Wright wrote:
    > 
    > * rhys tucker (rhystuckerat_private) wrote:
    > >
    > > 1. What security configuration does the base kernel have under LSM?. Is it nothing or is it the traditional root and others?.
    > 
    > as crispin mentioned, the base kernel is left with the traditional mode
    > bit tests, which include a test for an override mechanism.  the default
    > override mechanism is a simple {e,fs}uid == 0 test.  so an LSM kernel
    > with no security modules loaded enforces simple mode bit + root user
    > tests.
    > 
    > > 2. The LKM mechanism has a dummy LKM representing the statically-linked base kernel. Is LSM's initial module intended to be the first loaded module after
    > > this dummy LKM.?
    > 
    > if the module is compiled into the kernel, it will be loaded/initialized
    > in link order along with the rest of the do_init_calls() stuff.  if it is
    > actually compiled as a module, it will be loaded whenever the admin says
    > so (i'd expect this to be as early as possible during bootup).  note:
    > expect to see changes here as the 2.5 boot sequence should give better
    > control over do_init_calls ordering, and more pervasive use of initrd.
    > 
    > > 3. What does LSM's initial LKM  achieve?
    > 
    > when lsm is initialized (see security_scaffolding_startup()
    > in init/main.c::start_kernel() for exactly when this happens) it
    > sets the kernel's security_operations pointer to an initial value.
    > at this point the kernel enforces mode bit + root user access checks
    > (as mentioned above).
    > 
    > the lsm project has more than just the initial "dummy" security
    > module implemented.  in particular, we have a POSIX.1e capabilities
    > implementation, the domain and type enforcement module from serge hallyn,
    > some pieces of the Openwall kernel patch ported to LSM, and NSA has
    > ported SELinux to LSM.
    > 
    > > 4. How are system-calls affected?. How many additional system calls are implemented in the base kernel for LSM support? Do LSM modules implement more
    > > system-calls?
    > 
    > see crispin's description ;-)  if you are familiar with the
    > sys_socketcall(), we use the same multiplexing mechanism to give LSMs as
    > many system calls as needed through the one sys_security() multiplexor.
    > 
    > cheers,
    > -chris
    >
    
    _______________________________________________
    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 : Sun Nov 25 2001 - 07:36:43 PST