LSPP Requirement Specifically for Auditing

[Amy Griffis]

Hi Steve,

Thanks for your hard work on this list.  I have a few questions I hope
you can clear up for me.

On Mon, Oct 03, 2005 at 03:58:33PM -0400, Steve Grubb wrote:
> On Monday 03 October 2005 11:03, Dustin Kirkland wrote:
> > For the of completeness, can you reference the section of the LSPP/RBAC
> > specification where each of these came from?
> 
> OK, This is amended. I put R for RBAC and L for LSPP. Some things
> are not in the specs, like 3.1, 3.11, or 3.12. But I think these are
> items that we want coverage on to make sure the system is solid. 

For the things that aren't mentioned in the specs, could you explain
in more detail why you think they are needed?  I'll try to note
specific items I have questions on below.

> If there are no parenthesis, I did not find it in the specs.
> 
> -Steve
> 
> 
> 1. Basic
> 1.1 Objects shall include: files, named pipes (fifo), sockets,
> devices, shared memory, message queue, semaphores. New object:
> kernel keys

What is a kernel key?  Could you explain why it's needed?

> 
> 2 Audit User Space
> 2.1 Events shall contain unique session identifier and/or terminal 
> (R/FAU_SAR.1)
> 2.2 The ability to search on subject and object labels (L/FAU_SEL.1)
> 2.3 The ability to search based on type of access and role that enabled access
> (R/FAU_SAR.3)
> 2.4 The ability to search based on subject and object role (R/FAU_SAR.1)

> 2.5 There shall be a method to audit based on keys
> 2.6 There shall be a way to audit based on network address

Which requirement are these derived from?

> 3 Kernel - Audit related
> 3.1 Create new audit record types for: rlimit violations, lspp
> subject, lspp object, crypto, anomolies, and response to anomolies.

Other than lspp subject/object, I'm not sure which requirements these
items are tied to.  Could you explain that?

(Nit) Creating a new record type is an implementation detail and
shouldn't be listed as a requirement.

> 3.2 All Subjects and Objects shall be labeled - Network and kernel keys
> needed (L/FAU_GEN.1)
> 3.3 Subject & Object information must be labeled in events (L/FAU_SAR.3)
> 3.4 Role must be identified in events (R/FAU_GEN.1)
> 3.5 For access control actions, the role that made access possible has to be
> recorded. (R/FAU_GEN.1)
> 3.6 Audit events shall contain unique session identifier and/or terminal 
> (R/FAU_SAR.1 - This item may not be needed.)
> 3.7 Audit events can be filtered by Object or Subject labels (L/FAU_SEL.1)
> 3.8 Audit events can be filtered by host identity, event type, users belonging 
> to certain role, and access types. (R/FAU_SEL.1)
> 3.9 There shall be a method to audit based on keys
> 3.10 There shall be a way to audit based on network address
> 3.11 Loading MAC policy is auditable event
> 3.12 Changing policy booleans is auditable event
> 3.13 Service discontinuity is auditable event. (R/FPT_RCV.1)
> 
> 5.1.6 Hard Copy
> 5.1.6.1 hard copy data must be labeled on every page (FDP_ETC)
> 5.1.6.2 admin shall be able to specify label associated with the
> data. Overrides are an auditable event. (FDP_ETC)
> 
> 7 User Space SE Linux
> 7.6 newrole made into suid program so that it can send audit messages

Isn't this also an issue for trusted printing?

> 10.0 Postfix
> 10.1 Add loginuid code to set it when delivering local mail
> 
> 11.0 Procmail
> 11.1 Add loginuid code to set it when delivering local mail

<snip>

> 13.0 initscripts
> 13.1 Shutdown needs hwclock call moved to before killing the audit daemon

Are these changes necessary for LSPP, or just fixes that need to be
made to the current functionality?

Thanks,
Amy