From: Stephen D. Smalley (sdsat_private)
Date: Tue Jan 28 2003 - 06:40:12 PST

  • Next message: Casey Schaufler: "Re: c2 (or c2-like) auditing for Linux"

    > First pass this looks fine to me.  I've compiled both with and w/out
    > CONFIG_SECURITY_NETWORK, although I haven't booted the kernels.
    I've built and booted a SELinux kernel with and w/out
    CONFIG_SECURITY_NETWORK, and it functioned as expected, i.e. only
    differing in the absence of the socket and networking access controls
    w/out the option.
    > this isn't necessary.  "depends on SECURITY" is sufficient.
    Ok, I was just following the same convention as the other entries in 
    security/Kconfig.  Should we change them all?
    > this does embed some framework functionality in the dummy module.  any
    > reason not to put it in the static inline in security.h before the call
    > to the module?
    security.h can't dereference pointers to struct sock and struct
    open_request without including net/sock.h and net/tcp.h, but both of
    those header files need to include security.h since they contain hook
    Also, notice that we don't truly need these initializations as part of
    the base framework; they don't provide anything that can't be done in
    the module.  A security module should always just set foo->security
    when the alloc_security hook is called and not try to use any existing
    value (which may be garbage).  The fact that the SELinux alloc_security
    helper functions currently test foo->security to see if it is already
    set is a residue of the old precondition function approach, where it
    was possible to have a race on the allocation of the security blob for
    a kernel object that had been allocated before the security module
    initialized and was subsequently caught by a precondition function.
    Those tests can be removed from SELinux now that the precondition
    functions have been eliminated (except for network devices due to the
    difficulties in "hooking" all of their initializations).  Even if we
    were still using precondition functions, the test is unnecessary in the
    case where the alloc_security hook function is directly called by the
    kernel, since we know that we can just set foo->security at that
    So, other than the security/Kconfig cleanup, any other changes that
    need to be made prior to committing?  Also, I have an equivalent patch
    for lsm-2.4; does it need to be posted for discussion or can it just be
    committed at the same time?
    Stephen Smalley, NSA
    linux-security-module mailing list

    This archive was generated by hypermail 2b30 : Tue Jan 28 2003 - 06:33:44 PST