Solaris cron audit problem
PAUL WILLIAMSON
I finally have 2.1.14 running for the most part. When I set cfagent to
make an entry
to the crontab, I get this in my /var/cron/log:
!cron audit problem. job failed (x/x/x) for user root
After doing some googling, I've tracked it down to a combination of
Solaris, BMS (audit/security), and openssh. Apparently my only
options are to turn off auditing or making crontab entries via
the console. Neither of which are an option. Any ideas?
Switching to linux is sounding better and better...
I'm not having these problems with those boxes...
Paul
Baker, Darryl
crontab directory and restart cron whenever cfengine makes an edit to a
crontab file.
_____________________________________________________________________
Darryl Baker
Senior Unix Specialist
gedas USA, Inc.
Operational Services Business Unit
3800 Hamlin Road
Auburn Hills, MI 48326
US
phone +1-248-754-5341
fax +1-248-754-6399
Darryl...@gedas.com
http://www.gedasusa.com
_____________________________________________________________________
> _______________________________________________
> Help-cfengine mailing list
> Help-c...@gnu.org
> http://lists.gnu.org/mailman/listinfo/help-cfengine
>
PAUL WILLIAMSON
it is a solution I guess I'll have to live with until a better solution
comes along...
...thinking....
Is there some way I can tell cfengine to not restart cron from
cfagent.conf
if there is not a modification to the crontab? Or, do I just push out
a cfagent.conf without a line to restart cron?
Is there a reserved command to restart cron, or would I need to
do something like:
make the edits to cron (under editfiles:)
remove the resulting edit file from
/var/spool/cron/crontabs/root_*cfsaved
remove the root.au file from /var/spool/cron/crontabs
restart cron ("cron" restart "/usr/sbin/cron")
This seems like an incredibly ugly way to accomplish a fairly simple
task.
Am I missing some steps, or is this one of those times when it just has
to
be that way because I'm not using PAM authentication and need to undo
the audit/security stuff employed by Solaris?
Paul
>>> "Baker, Darryl" <Darryl...@gedas.com> 05/27/05 10:21 AM >>>
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:
- cfagent edits the user’s crontab.
- crond reads the new crontab, sees that the crontab has been manipulated manually without properly updating the .au token.
- 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
Luke Youngblood
When auditing is enabled, the .au file is required in order for crond to
execute a cron job. The reason for it is this:
Hypothetically, let's say a root user wants to execute malicious commands,
but doesn't want an audit trail pointing to them as the one that executed
the commands. Without the .au file, the root user could edit any user's
crontab, hiding the malicious commands. Then, cron would execute those jobs
and the audit trail would point to the innocent user. The .au file stores
the UID of the person that actually ran "crontab -e", as well as a timestamp
indicating when it was edited. That way, when cron runs the job, it can
update the audit trail with the correct UID of who actually requested the
job to be run (edited the crontab).
There are a couple of things that break this:
1. On Solaris 8, OpenSSH doesn't seem to update the .au files properly. In
order to fix this, you have to set "UseLogin Yes" in your sshd_config.
2. Editing crontabs manually with any method, such as cfagent editfiles,
does not update the .au token properly, which causes cron to throw those
errors.
Deleting the .au files will ensure that your cron jobs never run. Also, it
might even keep crond from starting properly on a reboot.
The only way to properly update crontabs when auditing is enabled is to use
the crontab command.
Luke
PAUL WILLIAMSON
logging in. Do I need to enable something else? I thought about
setting up ldap with central user authentication to deal with this,
but it doesn't seem to be doing the job either.
Paul
>>> "Luke Youngblood" <lyoun...@phonechargeinc.com> 05/27/05 12:12
PM >>>
Luke Youngblood
version of OpenSSH you're running. I'm running OpenSSH 3.9p1, from
SunFreeware. It works fine on several Solaris 2.6, 7, and 8 boxes. The
Solaris 8 boxes are the only ones I have to do the "UseLogin yes". When
this flag is set, OpenSSH actually executes /bin/login, rather than using
it's own login sequence.
FYI, we're not running LDAP on most servers. We have a couple
authentication gateway servers that are LDAP clients. Once you get through
there, it's all authenticating from local passwd and shadow files.