modify systems "su" for monitoring reasons?

[Manuel Contreras]

I received a request to capture additional info from every su command on a system.

I initially started thinking of the following script, which appeared to work fine until I started looking at crontab entries...

---------------------------------------------------
#!/bin/sh
#the production su is moved to su.hp
#this script takes it's place, and is initiated when an su is called.
#user/requestor information will be captured each time it is initiated.

fileD=`date '+%b%d-%Y'`

if test $2
then
echo "at `date '+%b%d-%Y %H':'%M'` the following user initiated the su command :" >> /root/Security/$fileD-SU.log
echo "`id`" >> /root/Security/$fileD-SU.log
echo "command = su $1 $2" >> /root/Security/$fileD-SU.log
echo "" >> /root/Security/$fileD-SU.log
/usr/bin/su.hp $1 $2
exit
fi

if test $1
then
echo "at `date '+%b%d-%Y %H':'%M'` the following user initiated the su command :" >> /root/Security/$fileD-SU.log
echo "`id`" >> /root/Security/$fileD-SU.log
echo "command = su $1" >> /root/Security/$fileD-SU.log
echo "" >> /root/Security/$fileD-SU.log
/usr/bin/su.hp $1
exit
fi

echo "at `date '+%b%d-%Y %H':'%M'` the following user initiated the su command :" >> /root/Security/$fileD-SU.log
echo "`id`" >> /root/Security/$fileD-SU.log
echo "command = su " >> /root/Security/$fileD-SU.log
echo "" >> /root/Security/$fileD-SU.log
/usr/bin/su.hp
exit
------------------------------------------------


I would like some input on changes that would accommodate su requests like the following:

/usr/bin/su -c user "/home/is/user/scripts/daily.sh" > /apps/is/user/logs/daily.log 2>&1

or

/usr/bin/su -c user /home/is/user/scripts/daily.sh > /apps/is/user/logs/daily.log 2>&1

my system is NOT trusted, and I am beginning to think that implementing this to track additional info may NOT be the best way to accomplish this...

your input is appreciated,
manuel

[Patrick Wallek]

For what you want to do, I'd look at using SUDO instead. It has built in logging and it can log to syslog.log or a different log file.

http://www.courtesan.com/sudo

[RAC_1 · Accepted solution]

How about modifying the script as follows.

if [[ $# -gt o ]]
then
arg_list=$*
echo "at `date '+%b%d-%Y %H':'%M'` the following user initiated the su command :" >> /root/Security/$fileD-SU.log
echo "`id`" >> /root/Security/$fileD-SU.log
echo "command = su $1 $2" >> /root/Security/$fileD-SU.log
echo "" >> /root/Security/$fileD-SU.log
/usr/bin/su.hp $*
exit
fi

if [[ $0 = "su" ]]
then
echo "at `date '+%b%d-%Y %H':'%M'` the following user initiated the su command :" >> /root/Security/$fileD-SU.log
echo "`id`" >> /root/Security/$fileD-SU.log
echo "command = su $1 $2" >> /root/Security/$fileD-SU.log
echo "" >> /root/Security/$fileD-SU.log
/usr/bin/su.hp
exit
fi

Anil

[Manuel Contreras]

Anil,
Sweet...after a quick "o" change your idea is looking quite promising :)


Patrick,
Sudo is quite the life saver, has helped me a great deal w/providing access to support personnel.
Highly recommended...


I guess additional su monitoring is common in non-trusted envs?

thanks for the input,
manuel

[Patrick Wallek]

Make absolutely sure you have a backup of your modified su somewhere.

IF/WHEN you install patches, and if/when a patch happens to modify 'su', then your modified su script will be overwritten by the patched su. If you forget and don't check after EVERY patch install, then the information you require will not get logged.

I don't like replacing system executables for exactly that reason.

[Manuel Contreras]

Already done, for exactly that reason...good look'n out!

manuel

[Florian Heigl (new acc)]

manuel,

at one site they also ran a modified version of su, and from my experience there I can just say You're right about that this is a less-than-optimal way.

usually, every su to root generates a syslog entry anyway, so You might be better off dedicating a cheap (but raid-supporting) pc box as a central loghost with no external access.

also, using a trusted system will pay off in the long term, unless You find the process of writing a wrapper script about everything that out to be monitored very intriguing :)

[Mic V.]

I'd also suggest sudo. I've used it for a long time and found it very valuable. I've also used restricted SAM to give certain people certain tasks (I wrote my own stuff for SAM to call).

If it's been requested to track su work because problems are occurring, perhaps a non-technical solution is in order. What I'm wondering is "why monitor now?" If it's because people are su'ing and not cooperating nicely, perhaps management needs to get together and work out the problem -- in addition to something like sudo or your script.

Just my $.02.

Mic