topic Re: at question. in Operating System - HP-UX

at question.

brian_31 — Fri, 19 Jul 2002 15:04:13 GMT

Hi Team:

We have an at job running on our box but we could not determine who runs it. We have a shared root program running and there are about 15 people who can login as root. Is there a way i can find the way who runs that. I tried w command but only reports if the person is logged in and since this is an "at" job we are unable to find out. Also at -l just lists the jobs. Can someone help please.

Thanks
Brian.

Re: at question.

Bill McNAMARA_1 — Fri, 19 Jul 2002 15:08:07 GMT

who -R
(IP's and terminal)

similarly

last -R

to show logins (IP etc), syslog should have history of su's.

Later,
Bill

Re: at question.

James R. Ferguson — Fri, 19 Jul 2002 15:10:19 GMT

Hi Brian:

See 'var/adm/cron/log' for a history of tasks.

Regards!

...JRF...

Re: at question.

Rodney Hills — Fri, 19 Jul 2002 15:12:22 GMT

I don't think you can. Once it is launched, the process has no association to who requested it.

You may want to not give multiple people root login, especially if you can't trust what they are doing.

If they need root access for specific tasks, then you can install "sudo".

Once the users have their own unique id's then you can control if they can schedule jobs, and if they are allowed, the launched jobs will have their uid assigned to the process.

-- Rod Hills

Re: at question.

A. Clay Stephenson — Fri, 19 Jul 2002 15:12:23 GMT

Hi Brian:

If I understand your question, you would like to distinguish user 'root' from user 'root'. That dog won't hunt. Moreover, the person who actually submitted the at job may have logged off days ago.

Re: at question.

Devbinder Singh Marway — Fri, 19 Jul 2002 15:21:40 GMT

when you do an at -l , it shows the user =
field . this is the user who set the at job to run. Don't you get this ?
what Os are you running ?

Re: at question.

Martin Johnson — Fri, 19 Jul 2002 15:26:12 GMT

Maybe you should set up pseudo root accounts (unique username with UID=0). They are easier to track.

Another advantage of a pseudo root account is if the root account disabled, a pseudo root account can be used to enable it without having to resort to booting in single user mode.

HTH
Marty
Marty

Re: at question.

Shannon Petry — Fri, 19 Jul 2002 16:16:52 GMT

Pseudo root accounts (ID's with UID=0) are as bad or worse of an Idea as shared root access.
Why as bad? Simple: The system returns usernames on some commands, but only tracks and runs with UID. Only us stupid humans use words, puters user numbers.
Why worse? A bit more involved. I have seen many applications that try to run with a username, but certain pieces use UID to get username. Now 1/2 the process for an app run as root, the other 1/2 as the user, and for obvious reasons the applications fail. Poor programing? Not really, UNIX was not intended to have users equivalent to root. If you need root you are root!

Look at Sudo, an awsome package that logs, tracks, and controls normal ID's access to root privaleges. Get people off of root and on their own ID, but have access to the commands they need. At the same time, let the sys-admin keep/maintain root access because they are responsible for the system.

Regards,
Shannon

Re: at question.

A. Daniel King_1 — Mon, 22 Jul 2002 14:40:29 GMT

It sounds like you've got some detective work to do.

Wrap the 'at' command. Have it send you an e-mail or log 'at' usage with the ip-address or (other information) used by the individual. (Example below.)

It would be helpful as well if folks were logging in as themselves and su'ing to root, rather than logging in directly. This provides a better audit trail. Sudo is also very, very good (http://www.sudo.ws/)

Example:

1) Rename 'at' to 'at_org'.

2) Put in place of at a shell script:

#!/usr/bin/ksh

date=`/sbin/date`
who=`/usr/bin/who -mTR`
whoami=`/usr/bin/whoami`

echo $0 ; $date ; $who ; $whoami | /usr/bin/mailx -s at root@localhost

/usr/bin/at_org $*

Re: at question.

Frank Slootweg — Tue, 23 Jul 2002 11:38:24 GMT

Why isn't your problem solved?

JRF pointed you to /var/adm/cron/log, but you only gave him 4 points.

The maximum points you gave is 7, which implies that your problem is not solved.

Why? I.e. please describe why the information given does not solve your problem or/and give a better description of your problem.

BTW, this is what an at(1) job looks like in /var/adm/cron/log:

> CMD: 1027427844.a
> franks 5621 a Tue Jul 23 14:37:24 METDST 2002
< franks 5621 a Tue Jul 23 14:37:24 METDST 2002

".a"/"a" indicates that it is an at(1) job. 1027427844 is the job number. franks is the user. 5621 is the process ID and the dates/times are the start (">") and ending ("<") times.

Re: at question.

brian_31 — Tue, 23 Jul 2002 12:51:51 GMT

Hi Team:

Sorry for the delay. I am not sure if danile's script would help as the job is already scheduled as root. Here is what i found in /var/adm/cron/log

CMD: 1027112863.a
root 15314 a Fri Jul 19 17:07:43 EDT 2002
CMD: 1027138073.a
root 483 a Sat Jul 20 00:07:53 EDT 2002

The PPID of the both the process is cron. With this info can i do something.Please help.

Thanks
Brian.

Re: at question.

Darren Prior — Tue, 23 Jul 2002 13:18:06 GMT

Brian,

This is the information you currently have:

* root specified the at job
* many people can login as root

here's what you don't know:

* when the job was specified
* which person was logged in as root

Without knowing the time the job was specified you cannot hunt through the output of last or syslog to see from which host the user came from.

Have you tried asking the people with root access whether they have set up any at jobs?

My feeling is that you won't be able to define who ran the job. I think you need to accept that and instead investigate the options that other users have suggested to help prevent this situation happening again.

Re: at question.

James R. Ferguson — Tue, 23 Jul 2002 13:33:00 GMT

Hi (again) Brian:

You can attempt to map the login place to the history in the 'var/adm/cron/log'. Since you have the time of the event, see if you can match it to a login session:

# last -R root

This too, was already suggested (by Bill M.)

Note that the addition of the '-R' option adds the hostname of the user of the session.

Regards!

...JRF...

Re: at question.

brian_31 — Tue, 23 Jul 2002 15:11:35 GMT

Hi:

Thanks All. I already tried to match it to a see with no avail. Anyway thanks a lot folks.

Thanks & Regards
Brian.

Re: at question.

MANOJ SRIVASTAVA — Tue, 23 Jul 2002 15:44:03 GMT

Hi Brian

We track it by a simple script in /etc/profile , which doesnt aloow anyone to login as root direclty , all SA's or authorised people login as themsleves and then su to root , this makes the system keep a su log and record who logged in and su'ed to root

the script is as :

loginid=`who am i | awk '{print $1}'`
echo $loginid
if [ $loginid = oracle ]
then
exit
fi

echo $loginid
if [ $loginid = root ]
then
exit
fi

this prevent both root and oracle to login direclty and also we get a sulog for the logging.

Manoj Srivastava

Re: at question.

Frank Slootweg — Wed, 24 Jul 2002 12:38:41 GMT

Other people have already explained why shared root accounts and pseudo root accounts are a bad idea, and have given pointers to sudo, which is (in my opinion) the best approach.

If you can not switch to sudo, then there *may* be another solution:

If you are *only* interested in at(1) jobs *which have not yet finished*, i.e. are scheduled or running, you can do a "ll -rt /var/spool/cron/atjobs" to get the dates/times when the jobs were submitted. You can then match these dates/times with the information from last(1) (see for example Bill's response), and perhaps /var/adm/sulog (see su(1)), to see who did what.

Of course that won't work if people change the dates/times of the "*.a" files, i.e. it won't work for 'hackers', but "everybody is root" doesn't work for hackers anyway, so that is a moot point.

I hope this helps. If not, please explain why not.

Re: at question.

Frank Slootweg — Thu, 25 Jul 2002 10:39:29 GMT

Again, you assigned 'only' 7 points. Does that mean that your problem is still not solved? If it is not solved, then why not, i.e. what is still missing?

Note: You do not *have* to assign 8 or more points, for example like in this case where a poster (me) has already gotten some points and you think (s)he does not 'deserve' more points. However in that case, please *say* so, i.e. by adding an extra response, and say that the problem was solved and how. Thanks.

Re: at question.

Shannon Petry — Thu, 25 Jul 2002 13:30:00 GMT

Like Frank said, many people have pointed out options to keep you safer. It is very hard after the fact (lots of us learn the hard way) that shared root access is not a good idea.

Remember the old saying "An ounce of prevention is worth a pound of cure". Wow, does this ever hold true on production servers!

I think it mute at this point to try and figure out who ran the at job. If the user was logged in for a time period before launching the job, and someone else logged in as root during that time then it is really not traceable. at only tracks the user, not the accounting information for the user (I.E. logged in from, su from, etc..)

I'd say remove root access from the users and use sudo. More food for thought...
Even if you force users to su to root, if several users are su'd at the same time and one launches an at job you still can not pin it on any of the several. The mystery remains
If you have to run at jobs as root, then sudo is the only way I know of to capture everything.
With sudo you can create your own command so that atroot runs at jobs as root. Sudo will log and can email that "john_doe ran atroot with date/time, etc..." Now you can see excactly who does what on the system.
I support more than 70 production workstations and 20 production servers. Fat chance that anyone other than the SA in charge of a server and me have root access!

Regards,
Shannon

Re: at question.

brian_31 — Thu, 25 Jul 2002 14:41:14 GMT

Thanks all of you. Decided to go for sudo.

Thanks
Brian.