|Subject:||some questions about audit|
|From:||Wayne Salamon (wsal...@computer.org)|
|Date:||Oct 21, 2005 1:35:18 pm|
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 wsal...@freebsd.org
To Unsubscribe: send mail to majo...@trustedbsd.org with "unsubscribe trustedbsd-audit" in the body of the message