[redhat-lspp] LSPP work items

[Klaus Weidner]

On Tue, Oct 04, 2005 at 05:46:52PM -0400, Steve Grubb wrote:
> 1.1 Objects shall include: files, named pipes (fifo), sockets, devices, shared 
> memory, message queue, semaphores. New object: kernel keys

Kernel keys add many additional requirements for documentation, audit,
and testing. I think it would be far easier to have a way to switch off
the kernel key functionality for the evaluated config.

I'm not objecting to adding SELinux support to the keys, but I think it's
an optional feature that shouldn't be needed for an initial pass for
meeting the PP.

> 4.3 When role data base is offline, corrupt, or unaccessable, the system shall 
> preserve a secure state (R/FPT_FLS.1)

I would interpret this in a straightforward way - a corrupt role data
base is one that can't be loaded due to syntactical or other fundanmental
errors. The point here is that the system handles a load error in a fail
secure way and doesn't just continue with a partial or empty data base.

I don't see this as implying a requirement to detect unauthorized
modification.

> 4.4 RBAC stipulates that after a failure or service discontinuity, the machine 
> shall enter a maintenance mode whereby the machine can be restored to a 
> secure state. Maybe config param for rc.sysinit (R/FPT_RCV.1)

How about something similar to creating a "bad-system-state" file on boot
that's removed only on a clean shutdown? If the file exists on boot, the
system enters single user mode.

This would work together with the existing auditd features to enter
single user mode on audit failure, and something similar could be done
for the SELinux policy loader.

> 11.0 Postfix
> 11.1 Add loginuid code to set it when delivering local mail (L/FIA_USB.1)
> 
> 12.0 Procmail
> 12.1 Add loginuid code to set it when delivering local mail (L/FIA_USB.1)

I'd still consider this to be optional, an alternative is to disable user
defined program execution via .forward files. Admins can still create
global program aliases if needed.

> 21 Turing Complete Programs
> 21.1 Review all Turing complete programs to see if they need augmentation: 
> sed, awk, rpm, bash, tcsh, perl, python, postscript, m4, cpp

What is this all about? The system's security features (kernel + trusted
programs) need to be be sufficient to implement the requirements, and
programs that aren't security enforcing shouldn't need to be touched. 
I don't see a reliable way to make this list complete, and what keeps
users from installing their own copy of a programming language?

-Klaus