Re: [patch] CONFIG_SECURITY_NETWORK

sdsat_private

> 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
calls.

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
point.

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
sdsat_private

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