[redhat-lspp] LSPP Development Telecon 01/16/2006 Minutes

[Stephen Smalley]

On Fri, 2006-01-20 at 09:29 -0600, George C. Wilson wrote:
> Self-Test
> ---------
>   GW:  Posted TSOL Security Target self-test statement.
>   Don't help us much.
>   So we're going to need some sort of integrity verification, perhaps tripwire.
>   SG:  RH stopped shipping tripwire.
>   Would need to teach about prelink and xattrs.
>   We all need to learn more about prelink; not well documented.
>   Xattrs are well documented.
>   KW:  Tripwire may be too heavyweight; but it may the most efficient way to
>     implement it.
>   SG:  Mandrake security tool may be adapted as well.
>   RC:  Might look at sxid from Debian as well.
>   KW:  Prelink itself can tell you if a binary has been modified by something
>     besides prelink.
>   RC:  Only helps in finds accidental damage, not malicious damage.
>   KW:  Intention of RBACPP is to check that nothing was corrupted, not IDS.
>   SG:  Not protected from malicious admins.
>   KW:  It is questionable that for that particular requirement additional
>     security is added.
>   RC:  RPM -v wouldn't work because there are non-rpm files we want to check.
>   KW:  Fail to secure state if corrupted; goal it to end up in secure state, not
>     fullblown IDS.
> 
>   SG:  Checksums of binary policy files?
>   Stephen said creating checksum would be easy if there is a requirement.
>   Need to follow up on that work to see if is should be done.
>   Ask Stephen.

What do you want to checksum?  Options include:
1) The individual policy module files provided by RPM packages like (but
not limited to) the selinux-policy-* packages.  rpm -V should handle
checking of the package files, but they are not used at runtime.  Those
files are then installed into the policy module store via semodule(8),
which uses libsemanage to install them.

2) All of the files in the policy module store, including both policy
module files and other configuration files (e.g. boolean settings, port
contexts, netif contexts) used in the generation of the final kernel
binary policy file.  libsemanage provides a way to specify verification
programs as part of its semanage.conf configuration that will be run at
certain stages of a commit (before linking the modules together, after
linking them together, and after generating the final kernel binary
policy file), so you could conceivably leverage that support (but note
that ultimately we also want to use that support for running checkers on
the policy modules and final policy to check specific properties).

3) The installed binary policy file.  This is the file that is loaded by
init and load_policy; it is created by libsemanage by copying the
generated file from the module store to a temporary path in the target
directory and then renaming it into place upon a commit, so it should
always match the generated file in the store.  Thus, you could simply
compare it with that generated file.

4) The binary policy memory image loaded into the kernel.  This is a
mmap'd copy of the installed binary policy file, possibly slightly
munged by load_policy to preserve any active boolean settings if they
differ from the saved settings.  This is what has been discussed in the
past.  The SELinux module could certainly measure this at load time and
make the checksum available via selinuxfs, but understand that the
checksum only corresponds to the load time memory image, nothing else.
Thus, any tool that uses this information and tries to compare checksums
would need to take that into account.

5) The dynamic data structures used at runtime by the SELinux module
that were populated from the binary policy image at load time.
Measuring these structures and mapping them to anything stable and
meaningful would not be trivial.

-- 
Stephen Smalley
National Security Agency