mjhjmtu

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?

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

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.

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.