1

So I was wondering if it is possible to create a Linux system without any (or next to any) userspace processes running as superuser/root, and no (or next to no) ways for other processes to raise their privileges?

What technical solutions there are that could be used to implement that? What would be the technical pitfalls in this?

12
  • 2
    Look ma, a Linux distribution without running in a computer. Jan 31, 2018 at 12:53
  • 3
    What's with the downvotes? It sounds like an interesting question. A computer could be configured to perform a very specific task that requires no root access with the assumption that it would be rebuilt if root access was needed. I can see something like this being useful in a IoT device for example, if it's not expected to be reconfigured at all after it's deployed.
    – Smig
    Jan 31, 2018 at 13:01
  • 2
    This question is hypothetical and invites personal opinions and speculation.
    – Kusalananda
    Jan 31, 2018 at 13:04
  • 1
    @Kusalananda, would it be any less hypothetical if we concentrate on the technical side, and remove the speculation on the cracking? (I can't really see the technical part as opinion-based, and the cracking part is always a bit fuzzy, since it depends on the threat model we accept.)
    – ilkkachu
    Jan 31, 2018 at 13:22
  • 1
    @MarkPlotnick The biggest point is that, computers in the 80s were not inherently more secure than today, and they also had a lot of malware problems, if not more. Anyway, hacking away the kernel and the userland for what defines Linux, it wont be called Linux anymore. Jan 31, 2018 at 13:50

3 Answers 3

6

While it is not practical to remove the superuser, it is possible to limit the access the root user has in the interest of security.

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sec-controlling_root_access#sec-Disallowing_Root_Access

I'll include some excerpts, but copying it all would make a large answer, so I'll just give the gist:

The following are four different ways that an administrator can further ensure that root logins are disallowed:

Changing the root shell

To prevent users from logging in directly as root, the system administrator can set the root account's shell to /sbin/nologin in the /etc/passwd file.

Disabling root access using any console device (tty)

To further limit access to the root account, administrators can disable root logins at the console by editing the /etc/securetty file. This file lists all devices the root user is allowed to log into. If the file does not exist at all, the root user can log in through any communication device on the system, whether through the console or a raw network interface. This is dangerous, because a user can log in to their machine as root using Telnet, which transmits the password in plain text over the network.

Disabling root SSH logins

To prevent root logins through the SSH protocol, edit the SSH daemon's configuration file, /etc/ssh/sshd_config, and change the line that reads:

#PermitRootLogin yes

to read as follows:

PermitRootLogin no

Using PAM to limit root access to services

PAM, through the /lib/security/pam_listfile.so module, allows great flexibility in denying specific accounts. The administrator can use this module to reference a list of users who are not allowed to log in. To limit root access to a system service, edit the file for the target service in the /etc/pam.d/ directory and make sure the pam_listfile.so module is required for authentication.

All of the sections have more info that I left out, but can set you onto further reading if it interests you.

SELINUX

selinux can be used to take away root privileges on the whole by modifying the selinux context of the service/executable/port/etc. That's getting into a huge topic though, so I'll link the RHEL doc on it rather than going into that a bunch: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/selinux_users_and_administrators_guide/index

For a really brutal example restriction, run selinux in enforcing and try: semanage login -a -s user_u root.

This would hand out the standard user permissions to the root user (assuming it even runs, I'm not sure, since I don't have a machine to brick at the moment), and restrict it from doing any "root" like actions.

This however could prevent init and a bunch of services from starting, so it might require a lot of other selinux configuration to allow those services to be run as some other user (which could be insanely secure, and insanely difficult to maintain, given that compromising one service wouldn't give any access to others).

2

A distro which did offer no superuser ability would be practically unusable, since it would not allow its user, by design, to perform any system configuration, driver install, or update.

It's like the famous "perfectly secure computer" which is a machine unplugged and switched off.
This is an example of the balance "security/usability" taken to the extreme (towards maximum security and low usability).

Besides, the kernel still performs above-user-privilege operations at boot, and these (as any operation) are still hackable.

1

Centimane gave a very thorough answer.  Here are a few additional thoughts:

  • You might want to remove cron, because it needs to have the privilege to set a process’s UID to any value.
  • Any process that needs to be able to read any file can be run as a non-root user with the “CAP_DAC_READ_SEARCH” capability — see this, this, and this.
  • Processes that need to be able to write to “system” files can be given non-root UIDs (maybe a different one for each program, or for each resource), and then given access with ACLs.
  • Processes that need to be able to do “privileged” things may be able to do so with other capabilities (discussed above); see Principle of least privilege.

In order to make configuration changes after setup and work around the root restrictions: 

  • Set up the computer to be dual-boot.
  • One operating system would be the hardened one, with minimal root access and activity. 
  • The other would be a more-or-less normal Linux, but with the network drivers removed. 
  • On the (rare?) occasion of the system administrator needing to administer the system, they could shut down, boot into the regular Linux, do what needs to be done, and reboot.

Apparently SELinux and AppArmor explicitly support this notion.

4
  • You don't even need dual boot to make changes, a live disk would be enough. Even Linux installation disks are live disks if you just change TTY when it prompts to install, mount the hard drive and chroot into it. The advantage of using live media being that you don't have to take up drive space and there's no way to see the administrative environment without physical access (otherwise someone could try to read the admin partition in search of vulnerabilities, though that'd be a difficult task)
    – Centimane
    Feb 1, 2018 at 14:08
  • Well, I consider that to be a matter of semantics. My point was that a machine with a hardened / restricted OS is not necessarily crippled if the administrator has the option of booting into a different OS. You make a valid point about using space on the disk — but how big is an alternative vmlinuz file? A few megabytes? And how would a non-privileged user be able to read it? I’m not sure whether there would even need to be a separate partition (although I guess that would be a little more secure). The biggest advantage that I can see to using a live boot … (Cont’d) Feb 1, 2018 at 19:35
  • (Cont’d) …  is that it could add a small extra layer of security.  Consider a high-security facility (think government agency or major corporate headquarters) that has restricted access, enforced with guards and maybe even metal detectors at the doors.  If the security policy forbids personnel from carrying digital media into and out of the building without specific authorization, and the officially sanctioned administrative boot disk is kept in a secure container, it becomes harder for an intruder to get root access even if he can get hands on the computer. Feb 1, 2018 at 19:35
  • 1
    Agreed that the live boot option offers only a minor advantage, but given we're talking about a seemingly ultra-secure environment it might be applicable. Reading the other partition would be a difficult task, given that normal users don't have read access to disks themselves (so they can't just dd the /dev/sd* to an image file for reading) but there's still the risk that some software/service/etc. would have a vulnerability that enabled it. Air gaps are normally the only certain form of security, and even they aren't perfect.
    – Centimane
    Feb 1, 2018 at 19:42

Not the answer you're looking for? Browse other questions tagged .