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?

ilkkachu
  • 138,973
Minh Khôi
  • 157
  • 2
    Look ma, a Linux distribution without running in a computer. – Rui F Ribeiro Jan 31 '18 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 '18 at 13:01
  • 2
    This question is hypothetical and invites personal opinions and speculation. – Kusalananda Jan 31 '18 at 13:04
  • @Kusalananda Thanks for the explanation. Maybe that's warranted for being hypothetical but it shouldn't invite personal opinion at all. If he were to remove the part where he says that it just popped in his head and that it could have no practical usage, then it would become a valid question. The answer should be clear. – Smig Jan 31 '18 at 13:22
  • 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 '18 at 13:22
  • I was going to add "while still being able to do useful work", but defining that at least is opinion based. – ilkkachu Jan 31 '18 at 13:26
  • You could write an /etc/init that drops its root privileges and creates a shell. The user would be doomed to having console access only, but it's not too different from a non-networked single-user computer from the early 1980's. – Mark Plotnick Jan 31 '18 at 13:26
  • 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. – Rui F Ribeiro Jan 31 '18 at 13:50
  • I was just wondering if you could a Linux distro with no root account and no superuser but is still runnable. I realize the question has no practical meaning in it. But I want the satisfaction of knowing whether it could be done. – Minh Khôi Jan 31 '18 at 13:51
  • 1
    @RuiFRibeiro, Well, the Linux kernel does include a number of ways of access control and privilege management. How would using them result in something that isn't Linux anymore? Sure, it wouldn't be a run-of-the-mill general purpose distribution then, but does something have to run systemd and GNU coreutils to be called Linux? Is Kali a Linux, What about something with a minimal init and busybox as the background for some main application? – ilkkachu Jan 31 '18 at 14:17
  • I’m beginning to agree with the closure of this question, but for lack of clarity.  What does it mean to have a system with no root account?  You could rename the UID 0 user to be fred; does that count?  Do you want to have multiple users?  If so, you pretty much need to have a superuser to be able to run the login program, because it needs to be able to set a process’s UID to any value.  Or you could move password verification into the kernel, but there be dragons down that path.  Is it OK to have a one-user system, with no login and password required, like DOS or Windows 95? … (Cont’d) – G-Man Says 'Reinstate Monica' Feb 01 '18 at 20:23
  • (Cont’d) …  Then you wouldn’t need a superuser, since the one user would own every file on the system, including “system” files (do you see where this is heading?).  But how would you mount filesystems?  Well, you could give “everybody” the privilege to mount filesystems.  How would you set the date/time?  You could build NTP into the kernel (we’re getting closer to the dragons) or give “everybody” the privilege to set the date/time.  Continue down that path, and you have a system where the only UID is 1 (or 17, or 42, or whatever), and that UID is superuser (because it can do everything). – G-Man Says 'Reinstate Monica' Feb 01 '18 at 20:23

3 Answers3

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

Community
  • 1
Centimane
  • 4,490
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.

dr_
  • 29,602
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.

G-Man Says 'Reinstate Monica'
  • 22,870
  • 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 01 '18 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) – G-Man Says 'Reinstate Monica' Feb 01 '18 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. – G-Man Says 'Reinstate Monica' Feb 01 '18 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 01 '18 at 19:42