audit 1.0.5 released
by Steve Grubb
Hello,
I've just released a new version of the audit daemon. It can be downloaded
from http://people.redhat.com/sgrubb/audit It will also be in rawhide
tomorrow. The Changelog is:
- ausearch can now search on SE Linux contexts
- added aureport program to analyze logs
- aureport added report option for each log's start and end time
- increased random number selected for initial seq number in auditd
- add new user space defines to libaudit.h
- add add standard logging functions to libaudit
This release concentrates on new features. The main addition is aureport. This
program does an analysis of the audit logs. Try -r option to get a summary
report. It is a work in progress and is 2/3 of the way done.
Please let me know if there are any problems.
-Steve
19 years, 1 month
Re: LSPP Requirement Specifically for Auditing
by Emily Ratliff
I inadvertently responded only to Steve Grubb with comments on one LSPP
Requirement. My email is below with his response following. I did get his
permission to forward his email to this mailing list.
Hi Steve,
> 2 Audit User Space
> 2.1 Events shall contain unique session identifier and/or terminal
We can confirm with the evaluators, but I don't think that the above
correctly captures the requirement. Are you are referring to FAU_SAR.1 in
RBACPP? It says "FAU_SAR.1.1 The TSF shall provide the set of authorized
RBAC administrators with the capability to read the following audit
information from the audit records: ... (e) The User Session Identifier or
Terminal Type". FAU_SAR.1 stands for Selectable Audit Review.
In the Common Criteria specification, part 2, FAU_SAR.1 states "Audit
review provides the capability to read information from the audit records."
Which means that if the field is in the audit record, the administrator
must have the capability to read the information, not that the field has to
be in every audit record. If it had to be in every audit record, then it
would have been specified in an FAU_GEN requirement.
The key for this requirement is the capability to read.
Klaus? Anyone from HP care to comment on your evaluator's interpretation?
Emily
*****
On Monday 03 October 2005 11:06, you wrote:
> We can confirm with the evaluators, but I don't think that the above
> correctly captures the requirement. Are you are referring to FAU_SAR.1 in
> RBACPP?
Yes. The one you quoted (2.1) is in the user space section which should
generally have a terminal associated with it.
> Which means that if the field is in the audit record, the administrator
> must have the capability to read the information, not that the field has
to
> be in every audit record. If it had to be in every audit record, then it
> would have been specified in an FAU_GEN requirement.
Makes sense. We can strike the one in 3.6 and keep the one at 2.1. I listed
it
twice in case we decided not to keep the one in the kernel.
> Klaus? Anyone from HP care to comment on your evaluator's interpretation?
I think you only sent the mail to me. I would like to get an official
reading
on this just so we can put it behind us.
-Steve
Emily Ratliff
IBM Linux Technology Center, Security
emilyr(a)us.ibm.com
19 years, 1 month
Re: LSPP Requirement Specifically for Auditing
by schaufler-ca.com - Casey Schaufler
On Monday 03 October 2005 10:03, Stephen Smalley wrote:
> Have you considered moving the audit generation into a helper program
to
> avoid having to directly make newrole suid (and to avoid having to
> directly allow newrole in policy to access the netlink audit socket)?
Our experiance with helper programs was that they
are not very helpful from an assurance perspective.
Sure, you isolate the priviliged code, but you still
have to demonstrate that the unprivileged program
that invokes it does so correctly. In this case you
still have to trust newrole, even though it isn't
setuid, because it would invoke a helper that is.
Steve's suggestion that he'll use capabilities to
reduce the exposure is very sensible.
------------------------
Casey Schaufler
casey(a)schaufler-ca.com
650.906.1780
19 years, 1 month
LSPP Requirement Specifically for Auditing
by Steve Grubb
Hello,
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:
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
2.2 The ability to search on subject and object labels
2.3 The ability to search based on type of access and role that enabled access
2.4 The ability to search based on subject and object role
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
3.3 Subject & Object information must be labeled in events
3.4 Role must be identified in events
3.5 For access control actions, the role that made access possible has to be
recorded.
3.6 Audit events shall contain unique session identifier and/or terminal
3.7 Audit events can be filtered by Object or Subject labels
3.8 Audit events can be filtered by host identity, event type, users belonging
to certain role, and access types.
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.
5 Kernel Export/Import of Data
5.1.6 Hard Copy
5.1.6.2 admin shall be able to specify label associated with the data.
Overrides are an auditable event.
5.2.3 devices used to import data without labels cannot do so if previously
allocated to importing data with labels without a manual state change that is
auditable
7 User Space SE Linux
7.6 newrole made into suid program so that it can send audit messages
9 Self Test
9.1 RBAC requires that a suite of tests be available that demonstrates that
the machine is correctly operating.
9.2 Authorized users shall also be able to verify the integrity of data and
executables called out in security target.
9.3 Tests shall produce audit records indicating that it was run and any
failures.
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
If I've missed anything, please let me know. Let's discuss...
-Steve
19 years, 1 month
