[Top][All Lists]

[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 12:34:15 -0400

We are getting a little off-topic for the list, but it might depend on which
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.

-----Original Message-----
From: PAUL WILLIAMSON [mailto:address@hidden 
Sent: Friday, May 27, 2005 12:23 PM
To: address@hidden; address@hidden
Cc: address@hidden
Subject: RE: Solaris cron audit problem

When I enabled UseLogin Yes, I got booted right back out from 
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.


>>> "Luke Youngblood" <address@hidden> 05/27/05 12:12
PM >>>
Sorry, this is bad advice.

When auditing is enabled, the .au file is required in order for crond
execute a cron job.  The reason for it is this:

Hypothetically, let's say a root user wants to execute malicious
but doesn't want an audit trail pointing to them as the one that
the commands.  Without the .au file, the root user could edit any
crontab, hiding the malicious commands.  Then, cron would execute those
and the audit trail would point to the innocent user.  The .au file
the UID of the person that actually ran "crontab -e", as well as a
indicating when it was edited.  That way, when cron runs the job, it
update the audit trail with the correct UID of who actually requested
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.
order to fix this, you have to set "UseLogin Yes" in your sshd_config.

2. Editing crontabs manually with any method, such as cfagent
does not update the .au token properly, which causes cron to throw

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
the crontab command.


-----Original Message-----
From: address@hidden 
Behalf Of Baker, Darryl
Sent: Friday, May 27, 2005 10:22 AM
Cc: 'address@hidden'
Subject: RE: Solaris cron audit problem

I believe the other way around it is to remove the .au files from the
crontab directory and restart cron whenever cfengine makes an edit to
crontab file.

Darryl Baker
Senior Unix Specialist
gedas USA, Inc.
Operational Services Business Unit
3800 Hamlin Road
Auburn Hills, MI 48326
phone   +1-248-754-5341
fax     +1-248-754-6399

> -----Original Message-----
> From: address@hidden 
> [mailto:address@hidden
> Sent: Friday, May 27, 2005 12:29 AM
> To: address@hidden 
> 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
> address@hidden 

reply via email to

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