some questions about audit

[Wayne Salamon]

On Oct 15, 2005, at 2:21 AM, xuejian03 at 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
wsalamon at computer.org

To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-audit" in the body of the message