This is practically impossible. First of all, if you grant them the power of becoming root, then there's nothing you can do to prevent them from doing anything. In your use case, sudo should be used to grant your users some root powers while restricting others without allowing them to become root.

In your scenario, you would need to restrict access to the su and passwd commands and open access to pretty much everything else. The problem is, there's nothing you can do to prevent your users from editing /etc/shadow (or /etc/sudoers for that matter) directly and dropping in a replacement root password to hijack root. And this is just the most straightforward "attack" scenario possible. Sudoers with unrestricted power except for one or two commands can work around the restrictions to hijack full root access.

The only solution, as suggested by SHW in the comments is to use sudo to grant your users access to a restricted set of commands instead.

We want that some users should be able to do e.g. sudo and become root,

Well, that's the problem sudo is designed to solve, so that's easy.

but with the restriction that the user can't change root password.

You can, as SHW pointed out in a comment, configure sudo to only allow certain actions to be taken as root by certain users. That is, you can allow user1 to do sudo services apache2 restart, allow user2 to do sudo reboot but nothing else, while allowing the hired-as-system-administrator user3 to do sudo -i.

However, a user that has been granted the ability to sudo -i or sudo into a shell (sudo bash, for example) can do anything. That is because by the time sudo launches the shell, sudo itself is out of the picture. It provides the security context of a different user (most often root), but has no say in what the executed application does. If that application in turn launches passwd root there is nothing sudo can do about it. Note that this can be done through other applications, too; many more advanced editors provide facilities to execute a command through the shell, which will be executed with the effective uid of that editor process (that is, root).

That is, a guarantee that we still can login to that server and become root no matter of what the other users will do.

Sorry; that can't be done. A quick "sudo rm /etc/passwd" or "sudo chmod -x /bin/bash" (or whatever shell root uses) and you are pretty much hosed anyway. "Pretty much hosed" meaning "you'll need to restore from backup and hope they didn't do anything worse than a slip of fingers".

By giving unfettered root access on a system to a user, you trust that user (including any software they might choose to execute, even something as mundane as ls) to not have malicious intent, and to not mess up by accident. That's the nature of root access.

If you can't trust them with that level of access, you'll need either a very tightened down sudo configuration, or to simply not grant the user in question root access at all.

I'm assuming you want to make sure you have an "emergency admin" access, even if your actual administrator screws up (but other than that, you trust the main administrator fully).

A popular approach (although very hackish) is to have a second user with uid=0, commonly named toor (root backwards). It has a different password, and can serve as a backup access. To add, you'll likely need to edit /etc/passwd and /etc/shadow (copy the root lines).

It's all but fail-safe, but if you just need to safeguard against the "main administrator" changing the password without notice, then it will work. It's trivial to disable, by removing the toor account; so the sole benefit is having a separate password.

Alternatively, you may want to look into alternate authentication mechanisms, i.e. ssh keys, libnss-extrausers, LDAP etc.

Note that the admin can still screw up badly. For example, by blocking the firewall.

If you want to have a very secure system, consider using SELinux, where the unix user (e.g. root) is also coming with a role, which can be much more fine grained. You may want to give your admin root access, but only a restricted role (e.g. to administrate apache only). But this will require quite a lot of effort on your side to correctly configure the policy.

You can probably do this using SELinux. This allows you to set up much more precise rules about what a user or process is or isn't allowed to do. Even with SELinux, it may be tricky to make it impossible for a user to change the root password, but still able to do whatever they may need to do.

Really it depends on what the user who isn't allowed to change the root password actually does need to be able to do. It would probably be easier and safer to just work out what that is, and grant those permissions specifically using sudo.

I don't know it will be practically feasible but here is one dirty hack:

1. write a wrapper script/program which will copy the /etc/passwd file to some other location, before calling actual sudo
2. Allow the normal user to use sudo
3. Once he finished his task, or when he came out of sudo, restore the /etc/passwd file

I know, there are lot of plus-minus things you have to consider to achieve this. After all, it's a dirty hack

The essence of root is to have unrestricted command of the system. You could tweak it with SELinux (there used to be a demo site where anyone could log on as root, but its power was crippled through the access system), but that's not the point. The point is that this is the wrong solution to your problem.

Now, you haven't said what your problem is, but if you don't trust these users to keep their hands off the root password, they have no business being root. If they need to administer the webserver, or various hardware devices, or the warp drive or whatever, set up a solution for that. Create a super-powered group, give it all the access it needs, and add them to it. If they need to execute root-only system calls, write some setuid programs.

Of course a user with that kind of access (and a bit of knowledge) could probably easily hack the system, but at least you're putting things where they belong.

PS. There are many ways to arrange root access for yourself without the password; for one, if you're in /etc/sudoers (without restrictions) you only need your own password to become root, e.g. with sudo bash. But you simply shouldn't need to go there.

(I don't know ubuntu, but it should be similar to Fedora/Red-Hat)
The only thing I can imagine restricting access to changing the root password is not giving full root access, maybe with sudo, or using SElinux to restrict access to the password file... but I would not trust either with much access as root generally has unrestricted access and could update SElinux, or relabel the password file, or run some pre-prepred program to change the password.

If you don't trust them enough to not change the password you probably shouldn't be giving them root access. Otherwise I would guess you are trying to avoid accidents.

If you are only trying to protect your access to root, setup a program that can restore the root password, so even if it's changed it can be restored with minimal access. (sudo does well on it's own)

The statement that sudo is just for granting root and there is no protection after that is blatantly false.

You use visudo to modify the sudoers file. Here's an example line:

redsandro ALL=(ALL:ALL) NOPASSWD:/path/to/command

redsandro is the username we're giving permission to. Put a % at the front to make it apply to a group.

ALL is a name for this rule. Sudoers can do a lot more than just grant global permissions. That's where it gets complicated though.

= needs no explanation

ALL:ALL reads as (who_to_run_it_as:what_group_to_run_it_as). This way you can allow running a command, but only in the context of a specific user or group.

NOPASSWD: tells it to turn the password prompt off.

/path/to/command lets you specify specific commands path_to_commmand, another_command

The thing to remember is that while sudo is mostly used by home users to escalate to root privileges, it can be and is used to control access to specific commands in a much more granular way.

from my other answer here

Perhaps you should consider letting the users have root access to a virtual machine or LXC container. That would allow them to have full root access to a system, without letting them prevent you from logging into the host or taking administrative actions.

There is no 1/2 root :) Once you give root privileges they can do whatever they want. Alternatively you can use sudo to run a restricted bash shell or run the rbash without root privileges.

If you want to have a failsafe mechanism to login to the server as root, you can either create another user with uid=0 or create a simple cron which will reset the root password periodically.

To complement the other answers, I'm going to assume the scenario is that you perceive losing control of root a rare situation, and that in those cases a server reboot is allowed. (After all, if you believe the machine has been compromised you will want to take it offline anyway.)

The great advantage of this is that there is nothing to configure. Your question becomes: "I've forgotten root password, how do I get back in?" And the answer to that is to reboot, and choose single-user mode when the machine comes up. That gives you a root shell without needing to know the password. At that point you can set a new password. (As well as go and repair any damage...)

If you clone your server into a VM (such as VirtualBox), you can give unfettered root access to people and still guarantee that you'll always have direct access to the guest operating system's partition(s), and therefore maintain final control over /etc/passwd and the like, since you will have root on the host system.

Of course, giving unfettered root access may still not be the right solution: if data security is at all an issue or your responsibility, you can't give root access away.

Try adding a wheel group rather than using sudo. sudo allows a user to execute as though they are root which means it isn't any different than running:

su -

to become root. The root uid=0; the wheel uid=10. People use the names but the OS uses the uid. Certain commands cannot be run by a member of the wheel group. (If you use wheel don't make the mistake of adding root as a wheel group member). Take a look at Red Hat documentation if you don't know what wheel is.

Another option is to use an ssh key rather than a password. Assuming you can be sure the folks using sudo don't add their public keys to the ~/.ssh/authorizedkeys file this gets around any concern of the root password changing because root password is effectively ignored.

If you'd rather get around extending trust to these users (to not add their own public key) try using extended file attributes and using the Immutable bit. After creating your ~/.ssh/authorizedkeys file, and after configuring /etc/ssh/sshd_config and /etc/ssh/ssh_config as you like, set the Immutable bit. Sure, there're ways to screw with that too -- nothing is perfect.

In any system, insiders are the highest risk. The person who runs the show is at the top of the pile. A related thought pertains to contracts. Lawyers will tell you, "Never do business with someone you need a contract to do business with". Common sense tells us, "Never do business without a contract". When you find someone you trust enough to do business with, write the contract based on each other's needs.

All the submitted answers, including mine, fail to address physical access. Whomever has it, has control. If it isn't you then there's likely a way for you to get the person who does to physically access the machine in the event someone finds a way to prevent you from logging in, or if they find a way to log in even after you've attempted to prevent that from happening. Of course, if you've got physical access than there may not be a need for any of these things although implementing a couple should be considered anyway, if you're interested in NOT being inconvenienced.

-John Crout

Your requirement is:

We are having a little problem on a server [...] that is, a guarantee that we still can login to that server and become root no matter of what the other users will do.

From your question it seems as though you are not facing random malicious users intent on destroying your system, but instead have semi-trusted users who may cause mischief now and then (students perhaps?). My suggestions address that situation, not an all-out assault by malicious users.

1. Run the server inside a virtual environment. You will be able to mount the server's filesystem and replace altered files with known-good versions. Depending on the possible damage you anticipate, you could take a snapshot of all critical directories (/bin, /sbin, /etc, /usr, /var, etc.) and expand the snapshot to overwrite damaged files while leaving the rest of the system intact.

2. Run the system read-only, e.g. from a DVD-R. If you can live with most parts of the system being static until the next reboot, this is a good option. You could also use a read-only backing store with a virtual environment or load the base system over the network, making changes between reboots much easier than writing a new DVD-R.

3. Kernel modules. The kernel's Linux Security Modules (LSM) provide the basis for creating secure modules. LSM is used by SELinux, but is also used by a number of lesser-known and simpler systems, such as Smack, TOMOYO, and AppArmor. This article has a good overview of the options. Chances are one of those can be configured out-of-the-box to prevent write access to /etc/passwd, /etc/shadow, or any other file(s) you want, even by root.

4. The same idea as #1, but when the server isn't in a virtual environment. You could have the server chain-load into a read-only OS such as a live CD, which would automatically mount the server's filesystem and overwrite the base system on each boot with known-good copies. The read-only OS would then boot into the main OS.

5. Again, assuming these are semi-trusted users who are accountable to a higher-up (teacher/boss), the best answer may be Linux Audit. This way you'll know every security-relevant action taken and who took it (you'll know who took it because even if all users share the root account, they will have sudo'ed from their user account first). In fact you might even be able to parse the audit log in realtime and replace damaged files. /etc/shadow overwritten? No problem, just have the monitoring server instantly replace it with a known-good version.

Other technologies you may want to investigate based on your needs:

• Linux Integrity Measurement Architecture/Extended Verification Module (IMA/EVM), and
• Trusted Platform Modules(TPM).

One way would be to ensure that /etc is not writable. By nobody, as long as there could be a sudoer around.

That could be done by mounting it over the network and ensure on the other side that the device can't be written.

That could be done by using a local device that prevents write access to it. (Lookup the write blocker hardware)

The important part is that the restriction has to apply outside of the root concept of that machine. A creative hacker will find its way around all obstacles you place on em within the environment he could control. So if root could change its password, so can a sudoer.

To be certain that the user also can't screw up your login abilities you have to have read-only mounted /bin and /sbin.

And you will have to have a script that periodically restores the network connection.

(As a sidenote: If you allow the sudoer only a very limited set of commands and for each of them secure that they can't break out of them / replace them etc., then you can prevent it while having /etc writable..)