10:03 a.m.
On 10/3/05, Steve Grubb <sgrubb(a)redhat.com> wrote:
I've been doing an analysis of what all we need to do to get the
audit system
up to par for LSPP. The actual work list for all of LSPP is bigger, I am
extracting just the ones that are aimed primarily at the audit system. This
is the essential requirements:
Hey Steve-
Thanks for doing this work. For the of completeness, can you reference
the section of the LSPP/RBAC specification where each of these came
from? Just looking at a few these, I'm a little confused where the
requirement comes from.
10.0 Postfix
10.1 Add loginuid code to set it when delivering local mail
Also, I'm pretty sure that we removed Postfix from the Security Target.
:-Dustin
10:15 a.m.
New subject: LSPP Requirement Specifically for Auditing
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?
Sure, I omitted that for easier reading. I'll add them since its just a copy &
paste and resend. I also accidently omitted something in section 13, and
needed to send that anyways.
> 10.0 Postfix
> 10.1 Add loginuid code to set it when delivering local mail
Also, I'm pretty sure that we removed Postfix from the Security Target.
It may not be on your security target, but its still an entry point daemon. It
needs to set the loginuid during local delivery so that if it executes any
$HOME/.forward file or anything else under the local user's account, the
actions are properly attributed to the user instead of root/mail.
-Steve
2:58 p.m.
New subject: LSPP Requirement Specifically for Auditing
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. 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
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
3 Kernel - Audit related
3.1 Create new audit record types for: rlimit violations, lspp subject, lspp
object, crypto, anomolies, and response to anomolies.
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
7.7 assignment of user to role/se linux user is auditable. (R/FAU_GEN.1)
9 Self Test
9.1 RBAC requires that a suite of tests be available that demonstrates that
the machine is correctly operating. (R/FPT_TST.1)
9.2 Authorized users shall also be able to verify the integrity of data and
executables called out in security target. (R/FPT_TST.1)
9.3 Tests shall produce audit records indicating that it was run and any
failures. (R/FPT_TST.1)
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
12.0 Udev
12.1 No hotplug events shall label devices. It can only make sure they are
unlabeled. (L/FDP_ETC, FDP_ITC)
13.0 initscripts
13.1 Shutdown needs hwclock call moved to before killing the audit daemon
5:29 p.m.
New subject: LSPP Requirement Specifically for Auditing
On 10/3/05, Steve Grubb <sgrubb(a)redhat.com> 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. If there are no parenthesis, I
did not find it in the specs.
Kudos! Just what I was looking for :) Thanks for taking the time, Steve.
:-Dustin
10:33 a.m.
New subject: LSPP Requirement Specifically for Auditing
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
2:19 p.m.
New subject: LSPP Requirement Specifically for Auditing
On Thursday 06 October 2005 11:33, Amy Griffis wrote:
For the things that aren't mentioned in the specs, could you
explain
in more detail why you think they are needed?
To round out the system. If there's questions about anyone in particular,
please ask about it.
> 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?
Its part of the keying infrastructure. Each key is a block of memory take is
presumably stuffed with a key.
Could you explain why it's needed?
Because its something that programs perform operations on, therefore its an
object. In another thread last week, I demonstrated that you can stuff the
whole passwd file into a key. This means that there is a need to control
access to it and possibly audit its use since it could become a covert
channel.
> 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?
Based on current audit useage. With keys, we may need to audit based on it.
Not sure yet how that will look or if syscall auditing alone will handle it.
As for networking, we have labled networking. We may need to track machines
regardless of what dhcp does to them. This has to be investigated and if we
are completely sure its not needed, we can discard it. I'd rather have it on
the list and cross it off than completely overlook it.
> 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?
All audit messages have a record type so that they can be searched for. This
is basically saying that we need to allocate blocks of numbers for these
types of messages.
(Nit) Creating a new record type is an implementation detail and
shouldn't be listed as a requirement.
This is something someone has to do. Until its done, I need to track it.
> 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?
Looking at my system, cupsd is running as root. It therefore has the
capability needed to send audit messages.
> 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?
Both. All changes to system time must be recorded.
-Steve
5:12 p.m.
New subject: LSPP Requirement Specifically for Auditing
>>7.6 newrole made into suid program so that it can send audit
messages
>>
>> Isn't this also an issue for trusted printing?
Looking at my system, cupsd is running as root. It therefore has the
capability needed to send audit messages.
I seem to recall Matt thinking that we need to be able to post audit
events by components of cups other than cupds.
Matt, am I remembering this correctly?
-- ljk
4:39 p.m.
New subject: LSPP Requirement Specifically for Auditing
Linda Knippers wrote:
>>>7.6 newrole made into suid program so that it can send
audit messages
>>>
>>>Isn't this also an issue for trusted printing?
>
>
>Looking at my system, cupsd is running as root. It therefore has the
>capability needed to send audit messages.
I seem to recall Matt thinking that we need to be able to post audit
events by components of cups other than cupds.
Matt, am I remembering this correctly?
Yes, however it looks like they shouldn't be problem here.
Other than auditing the print job's label, and auditing the overriding
of those labels, the remaining auditable events are actions that the
system administrator would take. Specifically, changing the label range
of the output devices, and going between printing unlabeled and labeled
information over an output device. Capabilities will be needed for
those actions, and will be sufficient to generate the audit events
covering them.
-matt
7012
days inactive
7019
days old
linux-audit@lists.linux-audit.osci.io
7 comments
6 participants
participants (6)
-
Amy Griffis -
Dustin Kirkland -
Dustin Kirkland -
Linda Knippers -
Matt Anderson -
Steve Grubb