6 messages in org.freebsd.trustedbsd-auditsome questions about audit| From | Sent On | Attachments |
|---|---|---|
| panxj | Oct 12, 2005 9:33 am | |
| Wayne Salamon | Oct 12, 2005 11:25 am | |
| xuej...@ios.cn | Oct 15, 2005 6:21 am | |
| Wayne Salamon | Oct 15, 2005 7:47 pm | |
| panxj | Oct 17, 2005 2:57 am | |
| Wayne Salamon | Oct 21, 2005 1:35 pm |
| Subject: | some questions about audit | |
|---|---|---|
| From: | Wayne Salamon (wsal...@computer.org) | |
| Date: | Oct 15, 2005 7:47:50 pm | |
| List: | org.freebsd.trustedbsd-audit | |
On Oct 15, 2005, at 2:21 AM, xuej...@ios.cn wrote:
The following is what my mentor and I would do in the next few months: (1) Add object?s security level to the audit trail
Can you describe where this security level is maintained? Is there a program running that will submit the label to the kernel for inclusion in the audit trail?
(2) Add the event of overriding of human readable output markings
I'm not sure what you mean here.
(3) Try to provide more choices when the audit trail overflow happens. At present there are only two policies available: drop records, or panic. Maybe rotating to the oldest file could be another choice.
By "audit trail overflow", I assume you mean out of disk space. This condition is different than when the audit log is full, where the kernel keeps writing anyway.
There are more choices, depending on the implementation of the /etc/ security/audit_warn script. This script is executed from the audit daemon when it receives a low disk space trigger, or a no disk space trigger. The script could clear some disk space, for example.
The behaviors you describe (drop records or panic) are performed by the kernel, while audit log management is done by the audit daemon. Your proposed behavior of rotating the log file should be done by the audit_warn script, and agent of the daemon, and not by the kernel.
(4) We want to add a command to dynamically adjust the state of auditing while a user's process are active, as audit_config does on solaris with the -setpmask options.
A command similar to the Solaris auditconfig command would be nice to have. The system call is in place (auditon()) to change a process' audit masks, as well as many other audit settings.
Besides, after analyzing the code carefully, I have some more detailed questions (a)The AUE_WAIT4 event is not correctly dealt with in the kaudit_to_bsm() function. So the unfriendly warning "BSM conversion requested for unknown event 370" jumps every now and then. Maybe it's a bug? (b) Why is the terminal ID always 0? Can we assign something more meaningful?
I'll look at these two problems shortly.
(c) The A_SETPOLICY cmd of auditon system call sets audit policy flags. Currently, only AUDIT_CNT and AUDIT_AHLT are implemented. But why they can occur at the same time? Maybe it?s confusable.
The interaction of these flags are a bit confusing, and I'll have to examine the behavior in more depth. Right now, the CNT flag controls whether the kernel should panic or continue when an audit record couldn't be written because the file system containing the audit trail has fallen below the free block count. The AHLT flag is used to control whether the kernel should panic when the record write failed for any other reason (file error, record conversion, etc.).
These failure modes are one area of the kernel where more code review and testing needs to be done. I'm sure there's some things that should change there.
(d) The ai_mask of child process is copied from parent without any modification. So, if a user login while auditing is disabled, then none of his action would be recorded, even after auditing is enabled. I think it?s necessary to do some checking in function audit_proc_fork(). If the auditing condition has been changed, then the children?s mask will be recomputed.
The login command sets the audit masks of the user that logs in. By "auditing is disabled" do you mean "disabled because the masks for the process are cleared" or "disabled because the auditing state is OFF"? In the second case, having login set the audit masks should allow for the auditing of a user's process commence once auditing is turned ON.
(e) Some global variables are not be initiated in audit_init(), such as audit_in_failure, audit_fail_stop, audit_panic_on_write_fail.
Thanks for pointing those out. I'll fix them.
Wayne
------------------------ Wayne Salamon wsal...@computer.org
To Unsubscribe: send mail to majo...@trustedbsd.org with "unsubscribe trustedbsd-audit" in the body of the message