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.

You can use sudo to grant permission for specific root-privileged application only. In that way, user will not be allowed to change the root password
–
SHWDec 16 '13 at 8:48

24

WHY do you need sudo for these users. If you don't trust them, don't give them sudo access in the first place. Also note that ideally, root should not have a password at all, but you should use other means of authenticating. (Which the user will still be able to "hack", even if you would protext /etc/passwd)
–
Anony-MousseDec 16 '13 at 11:48

3

What do those users need to do exactly?
–
Olivier DulacDec 16 '13 at 14:20

4

What are they going to be doing with their root-privileges? There might be a better solution than what you are thinking of.
–
sparticvsDec 16 '13 at 14:24

21

This is one of those "Can God make a boulder so large he himself cannot lift it?" type questions. If you have root access, you can do anything, which is why root access is best given judiciously. sudo and setuid can solve most problems.
–
bdowningDec 16 '13 at 16:58

19 Answers
19

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.

@DavidCowden Yeah, it seems this is the case here...
–
Joseph R.Dec 17 '13 at 10:48

1

@JosephR. No worries for me. The Stack Exchange community isn't always predictable, and questions that already have lots of upvotes do tend to attract more. Thanks for the upvote, though. :)
–
Michael KjörlingDec 17 '13 at 11:55

Thanks, I used the info you gave here, but forgot to accept the answer.
–
244anMar 14 at 12:09

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:bob@FOOBAR.ORG
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, bob@FOOBAR.ORG, 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.

How did you do that cool reference to a comment? I looked at the source for your answer and saw () surrounding it. Cool secret hat!
–
JoeDec 20 '13 at 23:24

@Joe The time a comment was posted is actually a link to the comment itself.
–
Joseph R.Dec 20 '13 at 23:33

@Joe Find the id (<tr id="thisistheid"...) to the comment (e.g. in Chrome right-click and Inspect element), then append it to the thread link with a preceding #. In your case (id = comment-162798) it looks like this: unix.stackexchange.com/questions/105346/…
–
polymJul 27 '14 at 9:53

1

Thanks for the answer, I didn't know if I should accept this or that from @Michael Kjörling, I chose his because that has more description - needed by a noob like me :) However, yours was also helpful
–
244anMar 14 at 12:17

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.

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.

This doesn't actually prevent user toor from changing the root password; it only provides a second password to become root with.
–
alexisDec 16 '13 at 12:30

2

-1, then. You're suggesting a backdoor password so that the admins can recover root access after they lose it??? That's just wrongheaded, and besides the pesky users could easily disable it, as you say. There are much more reliable ways to set up a backdoor.
–
alexisDec 16 '13 at 14:03

2

@alexis That is what IMHO the author of the question asked for. Why give -1 for this? toor recovery accounts has been a common practise (although frowned upon) on Unix for decades.
–
Anony-MousseDec 16 '13 at 17:08

9

If the only goal is to prevent against accidental password changes, this is a good answer. If the goal is to prevent anything malicious, this isn't much help. Since the OP didn't say what the goal was, we don't know.
–
BobsonDec 16 '13 at 17:18

2

Which is why I stated that in my first sentence: "screws up ... other than that, you trust ... fully". This is really only a "support access" solution; not a security feature. Using additional root ssh keys achieves the same, without being hackish.
–
Anony-MousseDec 17 '13 at 8:47

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.

While doing this with SELinux may in theory be possible (and I'm not convinced), claiming that it is without showing actual rules isn't going to help anyone.
–
GillesDec 16 '13 at 22:00

@Gilles well actually, this is what SELinux was designed for. SELinux is a layer of permissions required in addition to standard POSIX permissions. On a properly configured SELinux machine, root access is meaningless since your true permissions are determined by the security context and object labeling.
–
tylerlDec 21 '13 at 17:51

Theoretically, it may still be doable with SELinux; however, the setup of something like that would need to be more complex, to ensure a robust separation for ALL SELinux-related config files from the "normal" file-system (to which the root user has full access). In the end, the "easiest" method for such separation (with or without SELinux) would be to go with something like Kerberos, as mentioned by Joseph R.
–
ILMostro_7Oct 14 '14 at 9:12

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.

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's always the possibility that a malicious user will read this script and nuke the backup copy.
–
Joseph R.Dec 16 '13 at 9:07

This is also pretty much what vipw and friends do already.
–
Michael KjörlingDec 16 '13 at 9:10

Consider it program, and having only root access
–
SHWDec 16 '13 at 9:11

@SHW Then the malicious user can probably strace it or even (with enough perseverance) disassemble it and reverse engineer it.
–
Joseph R.Dec 16 '13 at 9:48

4

Why would you GRANT root access to a potentially malicious user??? As root, it is trivial to install a back door that does not depend on going through sudo and/or the wrapper...
–
alexisDec 16 '13 at 20:34

"The statement that sudo is just for granting root and there is no protection after that is blatantly false." Let's say I grant sudo vi access to a user because I want them to be able to edit system configuration files. That user then does :!/bin/bash inside a sudo vi session. How does sudo's ability to restrict what commands a user can execute through sudo help protect my system under those circumstances? (Nobody has said sudo can't be configured more tightly than an all-or-nothing sudo -i approach.)
–
Michael KjörlingDec 16 '13 at 9:09

5

Understanding the limitations of an approach is easily as important as knowing how to perform a task.
–
Michael KjörlingDec 16 '13 at 9:15

1

@MichaelKjörling, I think this is just an example. But to be clear, the right way to let users edit system config files is to let them run sudoedit. You can specifically identify which files they should be able to sudoedit. This is in man sudoers.
–
Matthew FlaschenDec 17 '13 at 5:09

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

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.

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.

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.

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.

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.

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.

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

No. As Michael so aptly noted, a malicious user can prevent root access without necessarily hijacking the password by simply messing up the binaries. Even the init=... approach may be prevented removing execute permissions from pertinent binaries. I think a better solution in this case, is to mount your root filesystem via LiveCD and (try to) fix the damage. Then again, if you believe the system has been compromised, you're better off restoring from backup anyway.
–
Joseph R.Dec 16 '13 at 23:46

Agreed @JosephR; discovering and fixing damage is complicated, and I'd just reinstall too. But I'm guessing the OP's concern was more about someone accidentally locking them out... deliberately hacking in a work or school situation is a bit suicidal. ;-)
–
Darren CookDec 16 '13 at 23:56

Not necessarily. A truly malicious user combined with a careless/clueless sysadmin can escalate privileges undetected. I do agree that the OP's original intent was probably to ward off innocent mistakes rather than to guard against malicious intent, but the question was tagged "security" and we just ran with it, I guess :)
–
Joseph R.Dec 16 '13 at 23:59

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.

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

detect when a user changes identity to root and keep track of any created processes;

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;

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

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.

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

FreeBSD Jails can help with this, maybe is not exactly what you want, but give you the flexibility to have multiple root users within a host inside a Jail and basically can do anything with out compromising the main host. (note that this is not virtualization)

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.

sudo is hugely different from su -. This has been pointed out repeatedly, for example by SHW, Joseph R., myself, hbdgaf and quite possibly several more the comment field is too short to include...
–
Michael KjörlingDec 17 '13 at 16:05

All true, but irrelevant. You're discussing alternate ways to become root, and risks of granting root access, but nothing that has any bearing on “root access that can't change root password”.
–
GillesDec 17 '13 at 16:11

True. The question is a logical oxymoron; It can't exist unless the installation is broken. What good is a user login/account where that user can't change their password, yet they have root access? Therefore the suggestions offered apply to what the questioner may have meant; not to the way they wrote the question. Any access control method has inherent risk.
–
John CroutApr 13 '14 at 18:53

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

Mounting /etc read-only, while perhaps possible (you'd have to be careful during the pivot-root in the initrd's boot scripts, for example), runs the risk of being a rather fragile setup. Also, there are many things a user with root access can do which cripples other users' ability to attain root privileges which do not involve making modifications in /etc.
–
Michael KjörlingDec 16 '13 at 11:57

@MichaelKjörling The setup is not fragile, I use it often (as read-only local mounts).
–
Angelo FuchsDec 16 '13 at 12:00

@MichaelKjörling I added some other elements you'll want to have read-only if you want to ensure you can still log in. So, the list of actions that have to be done if you go down that road is not so short, but its the only way that "is, a guarantee that we still can login to that server and become root no matter of what the other users will do."
–
Angelo FuchsDec 16 '13 at 12:03

I'll admit I've never seen the need to try it, but one thing I can definitely see that would be risky is how init is going to handle /etc/inittab being replaced under its feet. Or what the system will do if the initial and after-remounting /etc/fstab are different. And there's /etc/mtab. Other users may want to change their own passwords, which involves writing to /etc/shadow and possibly /etc/passwd. And mounting /etc read-only is still only a partial solution. I'm not saying it cannot be part of a solution, but it certainly isn't the first step I'd take in the OP's situation.
–
Michael KjörlingDec 16 '13 at 12:06

1

Yes. Doing this is dangerous and has severe problems if done wrong. Still as far as I can see its the only viable way to solve the OPs request for users who should be allowed to become root.
–
Angelo FuchsDec 16 '13 at 13:30