Remove Root access for administrators 2

[dUbbsNIX]

THIS IS ALSO POSTED IN THE SECURITY & HACKERS FORUM BUT HAD NO RESPONSE>

Hi,

Senior management wish to remove root access for everyone, including the sys admin team of which I am a member. We have,already, in recent weeks removed super-user access for the DBAs and using sudo has allowed us to do the same for the operators.

The problem we are having is trying to find a sensible way we can prevent us (the sys admins)having routine root access but still be able to manage, support and adminster the systems. They are all using Solaris 8 or 9.

Does anyone else work at a place that has managed to achieve this to any exent.

This has to happen, the directive to remove root for everyone, has come the very top! Due to a sys admin at another bank being wrongly acused of stealing but no logs to prove his innoncence!

 

[xkjdhdg]

You should be able to do that with premissions. You will have to put yourselves in another group. Only give them the level of premissions needed to do their job. Then you will have the trust ones for root access. This will have to a management decision.

 

[forbush]

The proper way to manage access is to use RBAC, role based access control. This will enable you to limit access to various individuals based upon their role. Look at the /etc/security/*attr files to get a feel for what sort of roles you can use.

Without knowing specifically the reasons for 'removing root access' it is hard to advise you exactly what you should do.
I restrict the root account itself, and then I create a root equivalent role which I su to. My reasoning is that there is no audit trail if I leave root open to anyone, and with a role, I have the audit trail. I also prefer to not allow root to login over the network. This is for two reasons, a) hackers may be using it, and I would not know, and b) snoopers could watch legitimate users logging in over the network and catch the password because it is transmitted in clear text. At least when I create a root equivalent role, only the individuals I specify may su to the root role.

Another advantage is that I can grant permission to certain commands while restricting others. In other words, it's the same advantage as sudo, but it's native to the OS.

 

[dUbbsNIX]

Many thanks for your help.

Forbrush, how do you manage the root passwords? Presumabley you still know what each of them are, this does not meet the requirments, that none of us should know the password or use root on a day to day basis.

The problem with RBAC, sudo and even the commercial products like UPM, is that if have can get root access they become meanigless as you can obviously do whatever you like, including removing audit trails & changing role access.

 

[forbush]

If management doesn't trust you with the root password there must be some issues there that need to be addressed. In my 15 years of Unix Sys Admin work I have never encountered such management. It would be possible for them to change the password and not tell the admins, and then use RBAC to give only the level of access they want people to have. But that would require them knowing RBAC to the degree that they could do that. In my opinion, that is a sysadmin's prerogative. Sysadmins should be the ones restricting root use, not managers. And then sys admins should restrict everyone else's usage of every privelege, that puts the knowledge, responsibility, and the access to enforce it, in the same place, exactly where it belongs.

 

[grega]

I have to agree with forbush here. It's the classic case of management trying to deal with something which they don't fully understand. You must trust the sysops, as banks must trust the individual managers, etc. It the only way for the system can function properly.

Good luck is all I can say.

Greg.

 

[dUbbsNIX]

Thanks again for everyones input. I agree it does seem absurd that root access should be taken away from SAs. However, their concern is understandable given the power that super-user access provides. As I said there was an incident at another company where a Sys admin was effectivley hung out to dry for fraud, it later transpired he was innocent, but there was no proof of his innoncence.

So you see it isn't so much a question of trust, aprt from anything you can be the most trustworthy indivdual in the world, but it won't stop you making a catastrophic mistake.

thanks again all.

D.

 

[forbush]

I think we can all agree that SOMEONE must know the root password. If management wants that responsibility, they should know the consequences. They obviously do not, and someone with background on the subject should educate, or leave all the system administration to them. There are tools to accomplish exactly what they want, for instance, Powerbroker from Symark, or RBAC, as I mentioned before. Powerbroker provides an audit trail for all root users, and could be the tool they are looking for

 

[ruppagator]

I developed a technique for changing the root password on our Solaris 7 servers in such a way that no one knows what it is. However, select users do have the ability to change the password - at least temporarily - to a known value. Furthermore, given our server configuration, anyone with the installation media and access to the CDROM and floppy drives can boot the system from CD, mount the root filesystem, and update any file, including /etc/shadow.

To change root's password, I created a script called skulker that performs a variety of tasks, one of which is setting passwords for restricted accounts. The skulker program runs as a root cron job a few times an hour. In a nutshell, skulker calls another program that generates random passwords and then sets the password for a particular account.

There are many ways to generate a random password. I developed my own password generator program that is based on a random number generator. I had to test the program carefully to make sure it wasn't recycling passwords or generating passwords that could be easily guessed.

Setting the password is a bit tricky since the passwd command in interactive. I use a slightly modified version of C program called setpass, which is licensed under the GNU GPL. Bobby Higgins (higinbg1 at home dot com) is the author.

Once root's password is set to some arbitrary, unknown value, we rely primarily on sudo to grant access to commands. In our environment, we give the members of our on-call team the ability become root using su. Obviously, these people could change root's password if they wanted to, so you might wonder, "What's the point?" Well, this approach has at least one significant advantage: there is no need to write down or communicate to anyone what the root password is. Even the people with root access only need to know their own password. The implications are significant. For example, if someone leaves the on-call team, we don't have to worry about changing root's password so that the person who just left no longer has access to the root account. All we do is update /etc/sudoers and/or remove that person's account entirely.

If you really want to get serious about audit trails on Solaris, check out the basic security module (man bsmconv). Be prepared to think very carefully about how you are going to manage and analyze the log files. The volume of information generated can be overwhelming depending on your configuration.