Root access that can’t change root password?

We are having a little problem on a server. We want that some users should be able to do e.g. sudo and become root, but with the restriction that the user can’t change root password. That is, a guarantee that we still can login to that server and become root no matter of what the other users will do.

Is that possible?

Answers:

Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.

Method 1

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.

Update

There might be a way to accomplish this if you use Kerberos tickets for authentication. Read this document explaining the use of the .k5login file.

I quote the relevant parts:

Suppose the user alice had a .k5login file in her home directory containing the following line:
[email protected]
This would allow bob to use Kerberos network applications, such as ssh(1), to access alice‘s account, using bob‘s Kerberos tickets.
…
Note that because bob retains the Kerberos tickets for his own principal, [email protected], he would not have any of the privileges that require alice‘s tickets, such as root access to any of the site’s hosts, or the ability to change alice‘s password.

I might be mistaken, though. I’m still wading through the documentation and have yet to try Kerberos out for myself.

Method 2

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 part is easy enough.

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. There are howtos available on how to set up sudo like that, or you can search (or ask) here. That is a solvable problem.

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; for example, many of the more advanced editors provide facilities to execute a command through the shell, a 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; if you really do mean “ensure we’ll be able to log in and use the system no matter what someone with root access does to it”, that (for all intents and purposes) cannot 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”. You can take some steps to reduce the risk of an accidental mishap leading to an unusable system, but you cannot prevent malice from causing very serious problems up to and including the point of needing to rebuild the system from scratch or at the very least from known good backups.

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.

Limited root access through e.g. sudo is a bit better, but you still have to be careful to not open up any attack vectors. And with root access, there are plenty of possible attack vectors for privilege escalation attacks.

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

Method 3

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.

Method 4

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 working with the OS security model, not against it.

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.

Method 5

It’s probably possible, at least in theory, to 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.

Method 6

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.

Method 7

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

Method 8

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.

References

• from my other answer here

Method 9

(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)

Method 10

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).

Method 11

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…)

Method 12

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.

Method 13

The requirement is not technically possible. As already eloquently commented, granting unlimited or even more limited sudo rights to a user means you trust that user. Somebody having evil intentions and enough technical ability and perseverance can go through any obstacles that are put in place.

However, assuming you can trust your users to not be evil-intentioned, you can make the restriction on password changing a matter of policy. You can create a wrapper for passwd program that will remind them “please do not change the root password”. This assumes the source of the problem is that the users that are changing the root password are doing it due to a misunderstanding (like maybe thinking they are changing their own password after having done sudo bash).

Under special (rare) circumstances, if complete trust is not possible and it is not possible to break the sudo access to adequate but reasonably safe chunks, you might consider establishing organizational sanctions against password changing (or any other specified form of system tampering), arrange monitoring of critical resources so that it is not easy to go undetected to get around the set policies – and be public and transparent about the usage rules and monitoring.

The monitoring and discovery aspect is hard technical problem benefiting from another question should you choose to walk that path. It seems to me we would need to

1. detect when a user changes identity to root and keep track of any created processes;
2. log the process creations from then on to see who is the original user responsible for each process, and using remote host where the half-trusted users do not have access to send the logs;
3. use some kind of system tracing to log what is happening and to later be able to discover who was behind the policy violation.

We would at least need to log opening of other than safe set of files for writing, process creation, exec(), and of course any attempt to change networking.

Implementation could be done by modified libc or (much better) system call tracing.

Of course, it is impossible to make such tracing and logging work 100% correctly, it is not easy to implement, and it also requires additional resources to operate. This would not stop the password change or other unwelcome system tampering, but it would make it (more likely) possible to find the guilty user or at least create an illusion that there is monitoring and make it less inviting for some evil minded users (but some problem loving hackers who see the fundamental futility of the technical measures put in place might feel encouraged to embrace the challenge and try to circumvent the system just for the fun of it).

Method 14

The originaly formulated question is useless. It looks like the main goal is “still have login” so speaking about some emergency enter which keeps working for sure even with root access granted to another person. Cheers to Anony-Mousse who first noted It explicitly.

The problem is: If the owner has physical access to the box It can easily recover logical acces to the system (providing It is still alive:). If not – keeping root password will not rescue from e.g. sshd down or bad networks setup, thus the system is still not accessible anyway.

The topic about how to prevent the system from damage by a person with administrative privileges seems too broad to fit SE question format.

Speaking about remote emergency enter solution the best way is IPMI (I think) if It is available. The system owner can attache virtual drive anytime, boot from It and
procced with system recovery.

If IPMI is not available any suitable virtualization technology can to be work-around, as have already been proposed above.

Method 15

You can limit the access to sudo in your /etc/sudoers file

To fully explain the syntax of /etc/sudoers, we will use a sample rule and break down each column:

jorge  ALL=(root) /usr/bin/find, /bin/rm

The first column defines what user or group this sudo rule applies to. In this case, it is the user jorge. If the word in this column is preceded by a % symbol, it designates this value as a group instead of a user, since a system can have users and groups with the same name.

The second value (ALL) defines what hosts this sudo rule applies to. This column is most useful when you deploy a sudo environment across multiple systems. For a desktop Ubuntu system, or a system where you don’t plan on deploying the sudo roles to multiple systems, you can feel free to leave this value set to ALL, which is a wildcard that matches all hosts.

The third value is set in parentheses and defines what user or users the user in the first column can execute a command as. This value is set to root, which means that jorge will be allowed to execute the commands specified in the last column as the root user. This value can also be set to the ALL wildcard, which would allow jorge to run the commands as any user on the system.

The last value (/usr/bin/find, /bin/rm) is a comma-separated list of commands the user in the first column can run as the user(s) in the third column. In this case, we’re allowing jorge to run find and rm as root. This value can also be set to the ALL wildcard, which would allow jorge to run all commands on the system as root.

With this in mind, you can allow X commands in a comma delimited fashion and as long as you do not add passwd to this you should be fine

Method 16

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.

Method 17

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

Method 18

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..)

All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0