Solaris BSM auditing with editfiles

[Luke Youngblood]

Consider the following section of code:

 

editfiles:

  { /var/spool/cron/crontabs/root

  AutoCreate

  DeleteLinesContaining "cfwrap"

  AppendIfNoSuchLine "0,30 * * * * /usr/local/sbin/cfexecd -F"

  }

 

When the Sunshield BSM (basic security module) is enabled on a Solaris box, the above code will no longer function properly.  After Sunshield BSM is enabled, any time a user edits their crontab using “crontab –e”, the audit subsystem will write to a file called /var/spool/cron/crontabs/$username.au.  This file contains about 50 bytes of binary data, indicating the true UID (who logged in originally, not the UID of an account they may have su’d to) and date/timestamp when the crontab was edited.  The purpose of this is to provide an audit trail for cron jobs.  If this wasn’t the case, it would be trivial for any user that has become root to “hide” jobs they want to run in another user’s crontab, and there would be no real audit trail back to the original root user.

 

The effect is this:

 

1. cfagent edits the user’s crontab.
2. crond reads the new crontab, sees that the crontab has been manipulated manually without properly updating the .au token.
3. crond throws an error and refuses to run the new cron job that was added, since there is no audit token tying it back to a user that added the cron job.

 

Has anyone on this list run into this issue before?  If so, how was it resolved?  Did you do something like use addinstallable to detect if there is a new cron, and then execute “crontab filename” to install it?

 

Any advice or tips would be greatly appreciated.

Luke Youngblood
Senior System Administrator
PhoneCharge, Inc.
(203) 732-7639 x279
http://www.phonechargeinc.com