personal root accounts

[Larry Hart]

Downloading sudo
7.1.5. Installing Superuser Do (SUDO) Software
Sudo is a program designed to allow a sysadmin to give limited root privileges to users and log root activity. The basic philosophy is to give as few privileges as possible but still allow people to get their work done.

7.1.5.1. Download SUDO Software from: http://www.courtesan.com/sudo

7.1.5.2. After download Sudo software on hard drive, you need to unzip the file by typing the command:
gunzip -c sudoxxxxxx.tar.gz | tar vxf -
7.1.5.3. Type cd sudoxxxxxx
7.1.5.4. Type ./configure
7.1.5.5. Type make install


Configuring sudo to work

7.2.10. Restrict non-root users from using sudo su to root
7.2.10.1. Type cd /usr/local/sbin and then type ./visudo to edit the file sudoers. Add the following lines on the sudoers file:

# User privilege specification
???userID??? ???hostname???=NOPASSWD:/usr/bin/su ??? oracle, /usr/bin/su ??? root

For example:
julia asepttdb=NOPASSWD:/usr/bin/su ??? oracle, /usr/bin/su - root

7.2.10.2. Edit /etc/skel/.profile (which is the default .profile) or /etc/profile file, and change the PATH statement and add mesg :

mesg n
# Change PATH=$PATH:. For SUDO do the following for C2
PATH=/usr/local/bin:$PATH:.

7.2.10.3. Edit /home/???userid???/.profile for any user already created and add/change the following lines:

mesg n
# Change PATH=$PATH:. For SUDO do the following for C2
PATH=/usr/local/bin:$PATH:.


------

I hope this helps

[Mark Fenton]

Jim,

another thought, did you consider creating a group, wheel perhaps, to which any user would have to belong before they could su to root?

This was used on a system (I think it consisted mostly of SUN servers) for which I had responsibility some years back. As you envisioned, the user logged in with his own credentials, and when he attempted to su to root, had to present another personal password to get to the root password prompt.

The system allowed direct login as root only on the console.

[Scott Van Kalken]

Jim,

I've seen similar functionality to what you describe but it was using a third party product known as eTrust.

It was quite good.

We would log in as ourselves and "sesu" to root. This would gifve us root priveleges but we would still have an effevtice ID of our own user account.

We only ever logged in directly as root from the console and only if necessary.

Scott.

[Jimmy Rogers]

I do this all the time on my systems. I also believe that an account password shared by users will end up sticky-padded all over the place. Here are my details:

1. My systems are behind a firewall.
2. My systems are trusted. Password rules are enabled and enforced.
3. I have complete trust in the the persons that get this access and their skills. Also in their ability to have a strong password, rather than a trivial one.
4. I have my OS/mirror dd over to disks weekly, so if all of roots files do get deleted, I can swap disks and boot right back up.
5. All of the UID 0 users have the same home, /root.
6. Each one generates their own history file, such as /root/.history.jdroot
7. A user that has their personal root account can have their own password, and will not write them down.
8. If one of the users do leave the company, their personal root account is simply deleted, without the need to notify other root users of a new password, which can also be hazardous security-wise. When the account is deleted, I tell it not to delete the files.
9. The password to the actual root account is known only to me and one other person.
10. I use the /etc/securetty file.
11. I use extensive IP filtering in the /var/adm/inetd.sec file.
12. I create the account in SAM, assign UID 0, and ignore the warning.
13. There is no necessity to share an account. If there are multiple users logged in to one root account, you can tell who su-ed when, but not who actually typed the command that killed you. Sharing the same account is also a big security no-no, esp. root. I'm not the only SA responsible for these servers, so multiple root access is a necessity. I think this offers the most comprehensive protection for the threats I'm likely to run into.

As you can see, there are many trade-offs regarding security. You have to prepare for the most likely threat. Almost every security class I've taken points out the biggest threat is internal users, whether it's accidental or intentional/vindictive. I have to agree. I consider our systems to be pretty safe from external threats, esp. with IP filtering. It's the internal threats that happen frequently.

Good Luck!

[Kent Arnott_1]

assumption = if someone wants to they can cover their tracks...

we do the following
Only one root account and can only login via the console. The admins can su to root and when they do that the following happens in root's .profile:
HISTFILE=$HOME/.sh_history_`/root/.wr`
echo "`/usr/bin/date`" >> $HISTFILE

The contents of /root/.wr
#!/usr/bin/perl -w
my $w = getlogin || (getpwuid($<))[0];
print "$w";

That way when admina su's to root a history file called /root/.sh_history_admina is created and the date logged in the file.

When adminb su's to root a history file called /root/.sh_history_adminb is created and the date appended to the file and logs all the commands executed.

[jim bidebo]

jimmy rogers:
In your enviroment is it possible to login directly as one of the uid 0 users? or are the uid 0 accounts restricted to specified users?

what i want to achive is that you have to login as user0 and from that point su to user0-root. user1 shouldnt be able to su to user0-root and it shouldnt be possible to login as user0-root directly (via telnet for instance)

is that what you have done? please tell me how.

[Jimmy Rogers]

No, I don't have anything like that implemented.

The security I do have to keep an internal user from trying to hack a root account is the account will be disabled if there are 5 bad attempts to log into that account. Also, there is a 5 second delay between login attempts to disrupt automated password cracking.

Finally, I have a shell script that mails me everyday regarding existing disabled accounts, successful login attempts, su log, files with 777 perms, etc.

[Jim Turner]

Jim,

Email me (jturner@hertz.com), and I'll put you in touch with our Information Security Guru. He can discuss with you how we implemented CA's eTrust Access Control (was SeOS) to achieve exactly what you want.

You'll have to deal with CA's product and support (major suckage there), but it will get you where you want to go.

Cheers,
Jim