Can I create a *super* super-user so that I can actually have a user that can deny permission to root?

I was thinking that it might be advantageous to have a user with permissions higher than the root user.

You see, I would like to keep all of the activities and almost all existing root user privileges exactly as they are now.

However, I would like the ability to deny privileges to root on an extremely isolated case by case basis.

One of the advantages of this would allow me to prevent certain unwanted files from being installed during updates. This is just an example of one possible advantage.

Because apt-get updates are run by root or with sudo privileges, apt-get has the ability to replace certain unwanted files during updates.

If I could deny these privileges to these individual particular files, I could set them as a simlink to /dev/null or possibly have a blank placeholder file that could have permissions that would deny the file from being replaced during the update.

Additionally, I can’t help but be reminded about a line which was said in an interview with one of the Ubuntu creators when the guy said something about how users better trust “us” (referring to the Ubuntu devs) “because we have root” which was a reference to how system updates are performed with root permission.

Simply altering the installation procedure to say work around this problem is absolutely not what I am interested here. Now that my mind has a taste for the idea of having the power to deny root access, I would like to figure out a way to make this happen just for the sake of doing it.

I just thought about this and have not spent any time on the idea so far and I’m fairly confident that this could be figured out. However, I am curious to know if this has already been done or if this is possibly not a new idea or concept.

Basically, it seems like there should be some way to have a super super-user which would have permission beyond that of the system by only one degree.

Note: Although I feel the accepted answer fits the criteria the most, I really like the answer by @CR. also.

I would like to create an actual user higher on the tree (me) but I guess I’ll just have to sit down one day when I have the time to figure it out.

Additionally, I’m not trying to pick on Ubuntu here; I wouldn’t use it as my main distro if I felt negative about it.

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

The “user” you want is called LSM: Linux security module. The most well known are SELinux and AppArmor.

By this you can prevent certain binaries (and their child processes) from doing certain stuff (even if their UID is root). But you may allow these operations to getty and its child processes so that you can do it manually.

Method 2

You’re misunderstanding the concept of the root user.

In plain English, root is at the “top of the tree”.

What if you decide one day to have a “super super user”, and then next month, a “super super super user”(!). How far “up” the tree would you want to go? How would you shuffle all the permissions and hierarchy to make that work? Who is always at the top? Someone has to be at the top, and it’s root. End of story.

The solutions given here – including AppArmor and SELinux – don’t really change this. They simply allow finer grain control over root permissions and processes.

It sounds to me like your update process isn’t suitable for the desired outcome. But that’s not a fault of the root user, at all. Instead of overcomplicating things, think of root as the highest level permission user, and then everything else, you have to work downwards.

I know some people will mark this down, but there is no level higher in the user hierarchy, and all the other solutions simply give slightly different control to how root permissions work. But they do not create a new user, with higher permissions.

You can’t have a user with “more permissions” than root because root represents the highest level of permissions possible. Using a phrase like “more control than root” is a contradiction – root has full control and all possible permissions, so there is nothing that can be done above it.

Method 3

If you just want to prevent files or directories from being changed/deleted then just set the immutable flag on them.

chattr +i <file>

Not even root will be able to do anything to them unless the flag is removed. It’s also possible to use the container/namespace system to prevent root access but that seems like overkill for what you need.

Method 4

• Instead of having a super-super-user, you can limit root. see
  What are the different ways to set file permissions etc on gnu/linux
• There is also AppArmor and SELinux.
• And/Or configure sudo, so that you do not give away full root privileges. You can set it up so that a user can only run pre-agreed commands, with pre-agreed arguments.
• You can also use virtualisation to restrict root:
  • cgroups, namespaces, chroot etc (docker does this)
  • Xen
  • Virtualbox
• See also etckeeper: this tool revision controls the /etc directory, and synchronises with apt. By default it is not secure, a malicious install could sabotage it, but you could also get it to push changes to a fire-walled backup repository.
• Use of revision control in general, with a fire-walled backup repository. This help with accidental, intentional corruption and hardware failure.

Firewalled backup repositories could be on a different machine, on the internet, or a different virtual machine (or host of virtual machine).

Method 5

For software like APT, which in normal operation require access to almost all of the system, restricting is problematic. Even if you prevent it from accessing certain parts of the system, there most likely are more than enough possibilities for malicious distributor to work around. For example by replacing a library or just a binary or adding a malicious configuration change, which unrestricted root is going to use eventually.

Depending on how much you would place restrictions, some install scripts can be expected to break.

For ways to restrict applications and users, you can write an AppArmor or a SELinux policy. Such policy would Which is more supported depends on your distribution: Debian based have better support for AppArmor while Fedora/RHEL based distributions enable SELinux by default.

Both AppArmor and SELinux work on white list policies, which contain rules to allow (or deny) specific actions. Policies are applied to a process at exec, similarly users can be restricted when a policy is applied to their processes at log-in. A well thought policy can not be circumvented (if kernel bugs are not considered). Confined process running as root (uid 0) is restricted by the configured policy and cannot change it unless explicitly allowed in the policy.

AppArmor policy language defines a deny rule, which can be used to build a blacklist policy. A good place to begin with AppArmor is AppArmor man pages, wiki and looking the existing configuration on your distribution in /etc/apparmor.d/.

Plenty SELinux administration and development material is provided in SELinux wiki. SELinux reference policy is hosted on github.

Method 6

I can’t believe no one has mentioned apt pinning…

A couple years ago, Microsoft released a patch that broke Windows 10 machines from talking to our old Samba NT4 Domain Controllers. When the issue was found, we pinned the Samba package to stay at the current version, and apt still functioned correctly.

A full Debian Walkthrough explains the process well:

In /etc/apt/preferences (or a new file under /etc/apt/preferences.d/), add some text to specify which package and version:

Package: samba
Pin: release v=3.6.6-6+deb7u7
Pin-Priority: 900

Check the documentation for the exact syntax, but this is the quick and dirty way we pinned a package version. Root could bypass it, as root can always do, but this solves the problem of package managers trying to automatically upgrade packages on you.

NOTE: This answer is assuming you have an XY problem

Method 7

It’s actually quite simple.

Root is your “super super user”

Create an account called “admin” and give him all of root’s permissions except the one’s you don’t want.

Then create a user called bob, and let him “become admin”. By using su or even sudo.

Now you have a normal user (bob) a super user that can do admin stuff (admin) and a super super user (root).

If you want to change the name “root” to something else you can even do that. Technially only the user id (0) matters.

Method 8

If what you want is simply to prevent specific files from being installed, then restricting root permissions is not the way to go about doing this. It is worth noting also that the conventional answers (immutable files or LSM’s) will not work for your particular use case, as APT (and most other package managers), will bail out if they can’t install files.

The real question you want to be asking is:

Is there a way to prevent APT from installing specific files?

That is something completely different from what you’re asking on multiple levels.

Now, as to that question, I’m not 100% certain myself, but I do know a number of other package managers have options to prevent specific files from being installed (for example, Gentoo’s Portage system has the option INSTALL_MASK=, which actually accepts shell-style matching patterns of things to not install). I’d be more than willing to bet that such an option exists for APT ( or possibly dpkg itself).

Method 9

Put a backup copy in a safe place. After any install/update, immediately replace the specific files from that back-up. Thus, no errors to screw up the install but you still get back the file(s) you wanted to keep.

Method 10

Work from a mounted drive

Note that this mostly a conceptual answer, but I think it should work and be in spirit with what you want to achieve.

Let system X be your working system, and system Y an other system which you control

1. Mount a directory from Y as a drive in X
2. Set up the rights in such a way that the root user of X has rights on everything in this mounted drive, with a few exceptions

Now you have your ‘working root’ which can do nearly everything, and you have your ‘super root’, the actual root account of system Y, which can truely do everything.

Method 11

You could run a type-1 hypervisor like Xen hypervisor
& have that hosting your regular OS as a virtualized guest.
The hypervisor controls the virtual guest OS at a level “deeper” than root because it has control over the (virtual) hardware on which the guest OS runs.

You could program the hypervisor to manipulate the guest OS in various ways, including changing permissions, creating & applying backups, hooking certain changes or instructions in the guest OS to inject additional functionality, validation, etc. That would be a valid, potentially useful way to implement a unix type system with a “user” (actually a function of the hypervisor) for “doing things even root cannot do”

My sense that this approach is probably overkill though

Method 12

Take a look at cgroups and Linux namespaces as an alternative method of achieving this type of goal, as well as tools based on them like Docker and lxd.

These tools allow you to, among other things, limit what parts of the file system a process running as “root” can see, limit which processes are visible to it, and provide only certain capabilities to the “root” user.

Method 13

UNINSTALL sudo

How about uninstalling sudo and symlink /bin/su to /bin/false? Couple that with making sure that root cannot login via ssh and you have locked down the system.

That makes root the Super*Super User, and everyone else is subordinate to that.

For files replaced during updates, simply do not do any updates. More realistically, change the permissions of the files to 440 or 444 so they can’t be written. Or put them in a git repository so if they do get overwritten, it can be reverted.

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