SU_ROOT_GROUP and immediate notifications

[Rick Garland]

Hi all:

Working with HPUX 11.00 and 11.11 on various types of HW.

Setup the /etc/default/security file with 'SU_ROOT_GROUP=sysadmin' and have 5 user accts that are permitted to become root.

I have the config working, I am parsing the sulog to see who/when becomes root, etc. What I am looking for now is how to have an immediate notification if someone else tries to become root.

I know sudo can do this but sudo will not prompt for a password when becoming root. I like the 2 layer password requirement.

(So to become root, you need to know my password as well as the root password. This is assuming I am in the sysadmin group.)

How to get the immediate notification if someone else is trying to become root?

Many thanks!

[Brian Bergstrand]

You could write a small wrapper script (or binary) around su and then replace the default su. Something like

REALSU=/sbin/realsu

code=`$REALSU $*`
if [ $code -eq $BADSU ]; then
mailx -s "BAD SU" root < /dev/null
fi

Where $BADSU is the code su returns for a failed su because the user is not allowed.

You could also have a shell script that looks for a bad su log run every minute and mail you when it find an entry. Not immediate, but pretty close.

HTH.

[Keith Buck]

One option would be to use a tool like HIDS (a.k.a. IDS/9000) to monitor the sulog for changes.

Another option is to setup auditing on the su system call in SAM (requires conversion to trusted mode).

Tools like Openview can also be used to monitor log files and generate alerts.

A cron job to tail sulog | grep may be just simple enough to satisfy your needs.

If you like any of those suggestions, write back and maybe someone can provide more detail. I've not done this specifically, but there are lots of folks in this forum who probably have.

Setting up a script to call the realsu is a good idea, but there are a few gotcha's to watch out for:
1. SUID scripts are not a good idea in general.
2. if you leave 'realsu' SUID, then the attacker can simply bypass the script
3. a patch to 'su' will overwrite your changes.
4. What you really want to monitor is the su system call, which can be executed by any user-space C program. So the wrapper script isn't really keeping all the gates locked.

-Keith

[Brian Bergstrand]

I don't think the script would need to be SUID, just realsu. Although without it be SUID, I don't think you could prevent anyone from bypassing the script and just using realsu. Something to think about.

I'd also make sure to explicitly set PATH to /usr/bin:/sbin/:/usr/sbin so you don't have to worry about trojans.

Your note about being overwritten during an upgrade is also true. I guess you'd just have to remember to put the script back in place after an upgrade and move the new su to realsu.

As for systemt accounting on a trusted system, there are two things that jump out at me.

1) These logs can grow very fast, so make sure you have a lot of space.

2) You'd still need some kind of script to parse the accounting logs and then e-mail you. So the immediate notification goes out the window with this option too. (Plus the acct logs are binary which make parsing a bit more difficult.)

HTH.