some questions about audit

Wayne Salamon wsalamon at
Fri Oct 21 13:35:40 GMT 2005

On Oct 16, 2005, at 10:58 PM, panxj wrote:

> Currently  login doesn't set the audit masks if the auditing state  
> if off, so all the child process will not, even if it is created  
> when the auditing is turned on. And if you modify the login program  
> only, could there be other problems? For example, if the  
> audit_control file is not in the default directory, then the  
> problem remains.

You point on some interesting interactions between login and and the  
current audit state. For the auditing OFF condition, some thought is  
required. I seem to recall a discussion we had a while back where, if  
a process starts up under a no-audit condition, it is grandfathered  
in if auditing is enabled (which means all child processes are also  
exempt from auditing). However, the administrator could run a utility  
to change the masks for those processes. A similar situation occurs  
if the masks for a user are changed once auditing is enabled: Do we  
change the existing processes running on behalf of that user? Again,  
that's probably an admin decision.  I'll have to examine other  
systems and see what they do.

In the case of audit configuration files not being in the expected  
location, that's a bit more difficult, and the solution depends on  
what we choose for the above case. If auditing is OFF, then we could  
let the login proceed even if we can't set the user's mask. If  
auditing is ON, then we could query the auditing condition, and if we  
are not allowed to permit auditable events to proceed without  
auditing, we deny the login and scream loudly. Otherwise, again we  
allow the login and scream not so loudly. I'd hate to get into a  
situation where nobody could login, although the solution would be to  
boot into single user mode and fix the audit configuration.

Corrupted audit configuration files have implications in other areas  
as well. For example, the audit daemon depends on the heavily, and  
I'm sure error handling in the daemon isn't what it should be. A  
front-end tool to check the condition of the config files, and other  
things, before starting auditing would be useful (does bsmconv do  
that on Solaris?)

Suggestions are welcome.


Wayne Salamon
wsalamon at

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

More information about the trustedbsd-audit mailing list