Documentation of standards for root user

[TwoProc]

Does anyone have a document for setup of the admin users who will access root? I've got an auditor here who is suggesting that all admins each have an account with userid of zero, "so there can be some accountability." I told her that is generally not acceptable, and and in fact most auditors would consider it a violation. She persists. I need documentation, can anyone point the way?

[James R. Ferguson]

Hi John:

Well, the *last* thing you want to do is have multiple superuser accounts!

Consider what happens if we defined user=john with a UID=0. Now, one day you leave the organization and user=susie takes over. She decides to remove your account and all its files, so she does:

# find / -user john | xargs rm -rf

...well, "john" is uid=0, so Susie just removed all files and directories owned by root!

One better choice is to limit root logins to the console (via '/etc/securetty' as described in the manpages for 'login') and force all users to login as themselves and then 'su' to root.

Regards!

...JRF...

[Steven E. Protter · Accepted solution]

Shalom,

You are better off with nobody using the UID zero account and only have one of them.

You can use sudo to provide needed functionality to these persons individual user accounts.

The system proposed by your auditor provides the opposite of accountability. Anybody with user id zero can do what they wish, erase a few log files and there is no accountability at all.

The bottom line is you must trust those users with user id equal to zero, at least to some degree.

Saying that, the practice here is to do what the auditor says. The .sh_history file is kept only for a short time.

I think however this is what you really want to see:

SOX rules
http://wp.bitpipe.com/resource/org_982350567_190/9086_UNIX_Linux_edp.pdf?site_cd=sel&src=bpde_sel_topics

http://www.s4software.com/sup_gdfaq.htm

http://www.passgo.com/datasheets/compliance/Sarbanes_Oxley.pdf

There is more.

Bottom line, I think your auditor is wrong. Management hired you permanently, speak with them and perhaps they'll make her go away on this issue.

SEP

[Rick Garland]

As the replys state, only 1 account with UID=0.

If they want some more accountability, the sulog will give info as to who became root. You can install the rootsh utility and in conjunction with sudo you will get all the information you need for the auditors.

Note, not to be offensive to anybody, myexperience with auditors is that they have very little knowledge of UNIX systems. What they are requesting is typically outside the bounds of best practices.

[Jeff_Traigle]

Every audit I've ever seen (and tools they use) check to make sure only one account has UID 0 assigned and alerts if it finds more than one. Accountability is maintained by only allowing su access to the root account (or direct console access) and other logged methods of access.

Management can declare common best practice is acceptable and that her suggestion won't be implemented. Auditors are basically hired to make suggestions. It's up to the business to decide what's viable and reasonable based on their own needs and document those approved deviations the auditors flagged. (Though, if I had any auditor insisting on such a thing as this, I'd express great reservations to management about ever using that firm again.)

[TwoProc]

Thanks all for your responses. Naturally, I feel the same way you all do, however, I have to (for some reason) get this auditor to review her stance on this. If I can do it now, instead of having to go toe-to-toe with everyone later, it will save me a lot of effort.

Thanks SEP for the doc reference. Rick, can you tell me more about what rootsh does, and where I can get it?

Thanks much all of you.

I'm still looking for other documentation too!

John

[TwoProc]

SEP, thanks for the reply - the bottom two links seem to be broken. Can you double-check those, please?

Thanks,

John

[Patrick Wallek]

John,

All of SEP's links worked fine for me.

[John Dvorchak]

Our CIS ( Corporate Information Security ) department at AT&T forces us to limit root access to only one account. We must us an /etc/securetty file with console as the only entry to force those with the root password to logon as usual and su - root to gain root access. Here is the snipet from the root .profile that we use to track what all root users do and we save/archive the sulogs. As for the document it is Company private and I am not at liberty to post it.

#############
# sets .sh_hist file to id of user

if [ "`tty`" = "/dev/console" ]
then
REAL=console
else
REAL=`logname`
fi

HISTFILE=$HOME/.sh_$REAL
export HISTFILE
export HISTSIZE=10000

[Geoff Wild]

For accountability - convert to a Trusted System or install a 3rd party app (like Unix Control from Fox Technologies).

For root, no direct login (unles console) and set up this in .profile:

# Set up logging
HISTFILE=${HOME}/.sh_history_`who am i|awk '{ print $1}'`
date >>$HISTFILE
export HISTFILE
HISTSIZE=5000
export HISTSIZE

This creates a root history file for each person who su - to root as well as time stamps when they su'ed.

Cron:

# date stamp sh_history
0 0,6,12,18 * * * /usr/local/bin/datestamp-root-history > /tmp/datestamp-root-history.log 2>&1

#!/bin/sh
#
# script to add a date stamp to the /.sh_history_$USER
# for those su'ed to root
# Only run from cron once a day
# gwild 2004-10-15 with help from jkittle

#===================================================================
# initialize some variables
#===================================================================
ULOG=/tmp/datestamp-user.log
cat /dev/null > $ULOG



#===========================================================
# Function: TimeStamp
# Description: timestamp the /.sh_history_$USER
# Arguments: none
# Returns: none
#===========================================================
function TimeStamp {
# point to their .sh_history file
# time stamp it
echo "HISTFILE is $HISTFILE"
(export HISTFILE=${HOME}/.sh_history_$UNIQUSER; echo "HISTFILE is $HISTFILE"; print -s "### `/usr/bin/date` $UNIQUSER still logged in as root...###")

unset HISTFILE
echo "HISTFILE after unset is $HISTFILE"
}




#===================================================================
# BEGIN MAIN CODE
#===================================================================

# find parent process of all users signed in as root
for i in `ps -ef |grep "\-sh"|awk '{print $3}'`
do
# just grab the user name
for USER in `ps -ef |grep $i |grep -v root|awk '{print $1}'`
do
echo $USER >> $ULOG
done
done

# get each user only once
for UNIQUSER in `cat $ULOG |sort|uniq`
do
TimeStamp
done

exit 0



Also see this thread:

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=718395&admit=-682735245+1143086677446+28353475


As far as a document - I'll take a look when I get to work in the morning...


Rgds...Geoff

[Yogeeraj_1]

hi john,

please find attached the document at the 2nd link that you are having problems


For the 3rd, try:
http://www.passgo.com/datasheets/compliance/Sarbanes_Oxley.pdf

(note that SEP's url does not come out as display on this page when you click)


hope this helps!

kind regards
yogeeraj

[Steven E. Protter]

I thought I was pretty good at copy link location pasting.

My link works just fine for me in firefox. Don't know what to say. Sorry about the trouble.

If you disable direct root logon, you can provide accountablity as follows

H1=$(who am i | awk '{print $1}'
HISTFILE="$H1roothistory"
export HISTFILE

I'm sure it can be done with one command, but have no time to test it.

SEP

[TwoProc]

Thanks all for the responses. SEP sorry, the problem was/is on my side then. We'll see how it goes today.

[Rick Garland]

Rootsh is a wrapper for shells which logs all echoed keystrokes and terminal output to a file and/or to syslog. It's main purpose is the auditing of users who need a shell with root privileges. They start rootsh through the sudo mechanism.

Additional info on this thread.
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=945592

The source depot for HPUX is at http://sourceforge.net/project/showfiles.php?group_id=110309&package_id=125148

[TwoProc]

Cool,

The documentation did the trick in the meeting with the auditor.

Thanks all for the help (what a great bunch of folks!).

[TwoProc]

Thanks all!