help-cfengine
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Solaris cron audit problem


From: Luke Youngblood
Subject: RE: Solaris cron audit problem
Date: Fri, 27 May 2005 11:57:46 -0400

Hey Paul,

I ran into this exact issue before...  We must have very similar
environments.  Please see the attached messages describing how to workaround
this issue.

HTH,

Luke

-----Original Message-----
From: help-cfengine-bounces+lyoungblood=phonechargeinc.com@gnu.org
[mailto:help-cfengine-bounces+lyoungblood=phonechargeinc.com@gnu.org] On
Behalf Of PAUL WILLIAMSON
Sent: Friday, May 27, 2005 12:29 AM
To: help-cfengine@gnu.org
Subject: Solaris cron audit problem

More fun...

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



_______________________________________________
Help-cfengine mailing list
Help-cfengine@gnu.org
http://lists.gnu.org/mailman/listinfo/help-cfengine
--- Begin Message --- Subject: Solaris BSM auditing with editfiles Date: Wed, 4 May 2005 14:50:53 -0400

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

 

Attachment: ATT00010.txt
Description: Text document


--- End Message ---
--- Begin Message --- Subject: Re: Solaris BSM auditing with editfiles Date: Wed, 4 May 2005 22:01:19 -0400

On Wednesday 04 May 2005 02:50 pm, Luke Youngblood wrote:
> Consider the following section of code:
>

control:
         AddInstallable  = ( reload_crontab )


>
> editfiles:

>   { /var/spool/cron/crontabs/root

>   AutoCreate
>   DeleteLinesContaining "cfwrap"
>   AppendIfNoSuchLine "0,30 * * * * /usr/local/sbin/cfexecd -F"
     DefineClasses "reload_crontab"
>   }
>

shellcommands:
  reload_crontab::
    "/usr/bin/crontab /var/spool/cron/crontabs/root"


>
> 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> http://www.phonechargeinc.com
>

>
>


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]