[redhat-lspp] LSPP work items

[Steve Grubb]

On Wednesday 05 October 2005 15:12, Klaus Weidner 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.

Its a syscall interface. Presumably, people will be doing both CAPP and LSPP 
evals. How do you prevent this in CAPP? I think that with the amount of time 
that the next OS has for development, you may not be able to ignore it. 
Something important may be using it by then.

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

That depends on what apps do with it. It might be required by the time RHEL5 
is released.

> > 4.3 When role data base is offline, corrupt, or unaccessable, the system
> > shall preserve a secure state (R/FPT_FLS.1)
>
> I don't see this as implying a requirement to detect unauthorized
> modification.

Right, the consistency test does though. Is policy not a trusted database?

> > 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? 

Can you not do a clean shutdown without fixing the problem?

> If the file exists on boot, the system enters single user mode.

Yes. This sounds reasonable. Just shouldn't be removed unless the utility 
fixes the database or the admin deletes it.

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

What account do they run under? 

> > 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 agree, but I think I am going to hold on to these until enough of the system 
is implmented to determine if this is needed. This is more of a reminder to 
check this when we are about done.

-Steve