We are so relaxed here, even auditors are welcome and get answers. ;-))


I think you are looking in the wrong direction. See below.

Yes.

No.

Here it comes: in principle nobody should be allowed to become root without a password and in principle nobody is. Having said that, i will try to explain in the most non-technical fashion i can muster:

It simply makes no sense to identify people over and over again. A password is a device to identify people - "prove that you are X by entering a password only X would know". If you make someone enter the password, say, 2 times, this enhances security not one bit. Admins often have many systems to administer and usually all these systems have the same people responsible for them. As the admin switches from one system to the other he has to log on over and over again always proving to a system he is still the same as he has been the last second. This is why clever people have developed several ways to centralize this identification process and this is why it sometimes looks like an admin is able to get into a system as root without a password. This is also the reason why you might be looking not in all the necessary places. Let me explain some of the possibilities:


1) Centralized user administration

A host maintains a directory of users along with a secret to identify them (usually the password) and some credentials they have (things they are allowed to do). It is easy to conceive that it might be a good idea to centralize this information for several hosts thus creating user accounts valid for either a single host or a group of (or even all those) hosts. Basically they all work the same way: if a system should decide to let a user something do it doesn't look in its own directories of user rights but asks a centralized server for that information.

Some of these systems are: Kerberos, LDAP, DCE, NISplus, in the Windows world the pendants are Active Directory, E-Directory, X.400 and there are probably some i don't know. If your environment includes one of these systems you have to look there too and not only in the local machine.


2) sudo

To give someone the right to become root is a "everything or nothing"-decision. Either s/he is allowed to become root or not. To make this a bit more specific and adjustable there is a tool called "sudo". Basically it allows you to execute certain commands as another user (quite like "su - ... -c", see post above) but without having to enter the other users password. You enter your own password instead to identify you (or none at all). If one has to execute a certain command as root you had to give him the root password before and s/he was free to do whatever s/he wants as root, now it is possible to give him the right to execute exactly this command as root but nothing else - and don't give the root password away.

I can't explain here the complete list of possible rules which govern this process, but there is a simple check: look for a file "/etc/sudoers" and if it is there sudo is most probably used. You will have to investigate the ruleset then too.


3) ssh-keys

This is a similar idea to 1), but this time not in a centralized but a distributed way: if you connect to one system as a certain user you identify yourself. If you are allowed to connect to another system as a certain user from there it simply makes no sense to identify you again. You generate a private-/public-key pair and store the public key in a keyring on the target system after connecting to it the conventional way (with a password). From now on you don't need a password but the key pair is used to identify you.

This works only on host-user pairs and only in one direction. If you connect to host a as user a[A] and then exchange keys to connect without passwords to host b as user b[B] this doesn't mean you can connect backwards to host a as user a[A] without a password too - you would have exchange the keys in the other direction in the same manner to make that mechanism work both ways. Neither is it possble for some user c[A] on host c to connect as b[B] - this would also require to use the procedure of key exchange described above.

To find out if someone can connect to the user account using ssh keys look in the directory "~/.ssh" (default name, could be different on your system, but usually isn't) for a file "authorized_keys" (again: default name). If it exists and has entries (read it with a simple text editor) then these user/host combinations are allowed to connect to this account without password.

I hope this helps.

bakunin