Giving root permissions or su-ing?

[Nicolas_17]

Hello all you sysadmins out there,

Today, I'm not looking for an answer to a problem. I'm seeking advice really. This concerns the eternal issue of root access on a system.

The stage: mid-sized company, a few rp7410's, XP128's and such hardware...

The protagonists: two admins, a junior (that's me!) and an experienced one, a supervisor with an occasionnal need for root access, three dba's and a manager who use the root account everyday.

The Plot: too many people using root, no way to monitor who does what and when, nor to know precisely who is on the system.

The set: pbrun is installed, but not really used. Everyone mentionned above has their own account but never uses it...

Tell me what think. How do you deal with root access? Do you use software such as sudo and pbrun? Do you have a few accounts with UID 0?

Thanks in advance to all who will be a part of the play!

[Deoncia Grayson_1]

Since I've worked in a government site,then you can only imagine the security restraints that were place on the system. We used sudo to track everyone who su'd to root. No one was allowed to login as root from their desktop. I've no experienced with pbrun. We don't have any accounts with the uid of 0. I think you guys need to get some security in place before the "blame" game starts up.


Good Luck.

De

[Sanjay_6 · Accepted solution]

Hi,

We use sudo to control the root access since it is free and can be customised to even allow root access to a user / group for one or more commands.

powerbroker is a good choice, but costly because of the $$ involved. However it provides central logging and that is good for audit purposes to know who did what and when. You can even replay a particular session if neccessary to see that was the output of the commands that were ran in that session.

Choice is between more logging (using powerbroker, but $$) or less logging (sudo & free).

We use sudo on the boxes on which we do not want to audit a lot, but use powerbroker on those system which need extensive logging & monitoring.

Hope this helps.

Regds

[Patrick Wallek]

Only the 2 admins should have root access.

The DBA's have absolutely no need for root. They may think they do, but anything they need to do they should be able to do with a database ID.

I ican't imagine why a manager would need root.

I would definitely set up something like sudo and force each individual to use it to do what they need.

I have just been through that on several systems here. Folks didn't necessarily like it, but they are living with it and I haven't had any problems with them to this point.

You've definitely got to get control of root somehow.

If one of the other's with root access happens to do something to crash the machine, guess who would get blamed, at least initially ---- the admin(s).

[Bill Hassell]

Never, ever use multiple UID 0 accounts. This is one of the first ways a hacker will use to break into a system--by creating an dumb user with UID=0. Run the command:

logins -d

on every system and proceed slah-and-burn all the accounts with UID=0 as well as other 'shared' UID values.

sudo works well and can be used to lock down commands as well as the parameters they are allowed to use. This means that a particular group of users are allowed to mount or umount /cdrom but no other device file or mountpoint.

I totally agree with previous comments about root access. Two admins, *NEVER* any DBAs, and definitely no managers. Now if management is worried about the proverbial beer truck running over the system administrators, you can use the old passwords-in-a-sealed-envelope technique. The envelope is locked away can only be given to certain people on the demise of the sysadmin.

Security must be ruthless to start with, especially when there is sloppy root management already in place. There will be lots of complaints but remember that the 'official' sysadmin gets all the blame for any and all problems. As far as the manager who needs root every day, transfer the manager back to being a sysadmin. All of these suggestions come with real examples of security and reliability nightmares to backup the rules.

[A. Clay Stephenson]

Whatever you do, multiple UID 0 users is state-of-the-art stupid; so, avoid that one.
Remember 0 = 0 = 0 so nobody did nothing and it sure wasn't me.

I would never let DBA's have root access; they really don't need it although you may have to do a few tasks for them. Just imagine that your DBA might need to "tweak" the kernel or that he needs that disk or LVOL that you aren't using. Hey, dbf didn't show it.

Managers don't need no root access neither unless they are truly knowledable and familiar with your systems. Ultimately, you and your fellow admins are responsible for whatever happens and the only way that can work is if root access is severely restricted.

It sounds like you guys need to have what in the southern part of the US is called a "Come to Jesus" meeting. It's where some serious preaching needs to be done.

And finally, you don't need root access neither -- exceptin' when you really need it. What I am telling you now is that root should never be a routine login. Always login as a regular user and su to root. It's just too easy to be your own worst enemy when you are root.

Sudo and/or specialized setuid program can do just about anything extraordinary that might be required. Oh, don't never, ever use root setuid shell scripts. They are a security breach waiting to happen.

[bhavin asokan]

hi,

see the following link
this can be used for preventing the direct root login from terminals other than console and specified terminals.

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=34616

regds,

[Steven E. Protter]

We are a really small shop.

My dba is my backup.

So he does have root access.

But he knows I'm watching. He is forbidden to use root login and then su to his dba account. If I see that happening I walk down the hall.

He is required as I am to log all system changes to a public folder and tripwire will catch unlogged changes when its installed.

Operations has root access because the sudo project has received low priority and they need to do two root tasks regularly.

Ideally. Only real sysadmins get root password. But I need vacations once in a while. Operations does not get root password, they get sudo for selected commands and functions.

Life isn't ideal. Shoot for it, it will make your life easier.

The good news with my situation is the only thing operations does is reset user accounts and adds new ones. They are good about not doing anything else.

I agree with Bill and A. Clay on many things, but especially the idea of only one root account with uid zero. Period. End of story. REALLY REALLY agree!

Regards,

SEP

[Jeff Lightner_1]

I'm with the rest of the thread. The root account should be restricted to SAs. Even SAs should always be required to login as themselves first then su to root. (Even better is to set up your root profile so that each person that su's gets a separate .sh_history file - gives a little bit of logging when there questions about which SA did what.)

Pbrun is not something I'm familiar with. I highly recommend the use of sudo. It does adequate logging for most purposes. If you do use something like sudo (or pbrun if it runs commands as root) make sure you:
1) Don't give access to commands like vi that have shell escapes. Once invoked as root the shell escape goes to a root prompt.
2) Don't give access to scripts that can be edited by anyone other than root. Someone can void the security by simply inserting a "su -" in the script.

At my prior job we took root away from DBAs and despite their protestations beforehand actually saw little impact from doing it. There were some complaints about a script they ran that was designed to shutdown multiple environments on a single server. We solved that by setting up ssh trusts from the Oracle account to the individual environment accounts. Still a bit of a security hole but it is limited to application level. (You should make DBAs login as themselves and do sudo su - oracle for similar reasons as mentioned above for SAs.)

[Victor BERRIDGE]

Hi Nicolas,
I work for local gov. so we are quite a lot of sysadmins... and policies varies depending the platforms. But No DBAs have root passwd I have stopped that a long time ago...
When they install and have to execute commands/script as root, they ask a sysadmin to do the task with them (mainly because they dont even look at what the script is trying to do...).
The most current is:
No one can log in as root except at the console, all sysadmins can do su2 or sudo (depending which is installed on the boxes).

Why does the manager use the root account?


All the best
Victor

[Nicolas_17]

Thanks to all of you for your quick and pertinent responses!!

To answer a few questions:

The manager is actually a previous sysadmin, he hasn't quite accepted, though it's been a few years, that he shouldn't be hands on anymore. So that's why he uses root...

The dba's have the same kind of problem, because the head dba is the most knowledgable person in the department concerning all the scripts and jobs that run everywhere. He's been here for a long time and is very respectfull of us, sysadmins. He always asks us to do tasks that have to do with the system instead of doing it himself.

Another thing we have to take in account, is that we are all on call, including the dba's.

I'm taking a deeper look into powerbroker today...any advice is welcome!

Thanks again to all of you!

[Claudio Martin_1]

Hi Nicolas:
another idea is use "sam -r" for a particular user or particular group.

Good luck.

[Paul F. Carlson]

We use sudo here, but all admins are required to use a wrapper script we wrote that goes around sudo.

The script is called broot. When it gets run, it calls sudo with a script called .beroot, which in turn calls su - root. The big difference here is that it also starts a script session which logs every command that is typed, along with the output. When the shell is exited, the script session is closed. The script session is saved according to the user's actual login name in a seperate filesystem (the script logs can get pretty big).

This value of this method is two fold: It can be used for auditing purposes, and is also a good tool for cataloging work that is done.

Note that sudo is set up so that ONLY admins have access to sudo to root via this method. A caveat here is that although it is company policy to use this tool only to access a root shell, it is also based on the honor system. There is nothing stopping an admin from logging in as root via broot and modifying the sudoers file or changing the root password (with the exception of the consequences of going against the policy).

[Fred Ruffet]

Rule #1 : Only Sys-Admin have root access.
Rule #2 : If someone need something to be done as root he asks Sys-admins.

This is what things should look like. Now, of course there are some problem that need some changes...

First of all : DBAs. I am a DBA and I *never* use root for my DBA job. (I don't use sys oracle account to do my sys admin job)

For your manager... This is politics... Up to you to make him understand about everybody's role. If he tells you he agree, but continue using root, you can change root's password. This is probably the most difficult part of this "fight for root".

Supervisor supervises with supervising tools. No need for root (excpet maybe for tool installation, but you have to be with him).

UID 0 is a non-sense and I try not to use sudo except when a lot of people are involved and this is not the case.

Regards,

Fred

[Michael D. Zorn]

I'll add my confirmation of what the others have said. I'd modify Fred's Rules:

Rule #1: Only the SysAdmin and his backup get the root password.
Rule #2: If anybody else needs it, see Rule #1.

There's an implied Rule#3: Change the root password every N days (we have 180, and 360 would probably work for you) or whenever anyone with the password leaves.

You might try getting together with the other SysAdmin and seeing if you can agree that unrestricted root access is not a good idea, and that you should try to put out a Company Policy to that effect.

And anybody who needs to do rootly things should log on in their account and then su to root.

Another good idea already suggested is to go in and restrict root logons to the console and the admins' terminals.

(Three dba's????? You must be running Oracle. . . . . . . .)

[Nicolas_17]

Thanks to all that responded!

I was reading this thread again, 8 months later, you wouldn't believe all the things that have change since then...;)