No root password

As an experiment, have done without a root password, meaning that there is no way to obtain root via sudo or su, since if user cannot access the root account by cracking a password, neither could malware in theory.

This leaves the issue of getting root access directly. The resolution I have used is to open up the system virtual consoles, so they automatically login as root on startup.

All this assumes the console is as safe as the system unit, such as a desktop pc next to its own keyboard and not in a security cage, or otherwise users with console access could rip open the system unit.

  1. --- /etc/systemd/system/getty@.service.d/override.conf
  2. +++ /etc/systemd/system/getty@.service.d/override.conf
  3. @@ -0,0 +1,3 @@
  4. +[Service]
  5. +ExecStart=
  6. +ExecStart=-/sbin/agetty --noclear --autologin root %I $TERM

It also means leaving the debug shell permanently enabled on F9 is quite reasonable.

Actually Disabling the password

Now the password can be removed in /etc/shadow, line begins root:*: with the * meaning that there is no such thing as a correct password for this account, which is important as without it means that access to the account does not require a password without limit to the source of the logins.

I am usually using X11 via gdm3 which runs sessions as the regular user, and if wanting to use a VT as a regular, switch in with login -f

root in X11

A root X11 terminal is useful sometimes, I am using the property that GDM launched Xorg from the root account.

This needs to be set off from a root VT, or perhaps a systemd event triggered by a safe key, and when open, appears on the desktop. There is the possibility this could be attacked via the window manager; though only while the terminal and things ran from it are open.

I am regarding that as far more secure than any priviledge escalation, since it will be expected a virus can't issue a hotkey request unless it already has root access.

#!/bin/sh
export DISPLAY=:0.0
export XAUTHORITY=/var/run/gdm3/auth-for-Debian-gdm-*/database
exec gnome-terminal

Or in use on Debian 9, note that Xorg runs as the less priviledged user so there may exist attacks on the root terminal, though only whilst it is open. One could run multiple X11 sessions, yet to be explored.

#!/bin/sh
export XAUTHORITY=`echo /run/user/*/gdm/Xauthority | cut -d" " -f1`
export DISPLAY=:0
exec sakura

Getting remote root

Root difference of opinions

Firstly, there is some difference of opinion and explore around openscap shows that some consider that remote root access should be impossible, with statements like PermitRootLogin no, and that user should maybe do vertical privilege escalation This is only true if it is never expected to access root over SSH, if some secondary priviledge escalation path is then possible to use such as any setuid binaries, root is still being accessed remotely.

The OpenSSH server itself can log the public key before handing over control, providing "individual accountability", and that could be propogated to some dark logger server out of reach of the administrator, leaving the option of time travel to delete logs.

If wanting to go further, system owners that consider administrator privacy fair game can enable debug logging for a transcript of activity as well, that can also be sent for dark logging at least til the rogue administrator severs it.

Process

This is an exception to the absolute control over root access given that cracking long ssh keys and good passphrases should be difficult.

If the source terminal in is the same - home pc (browse horizontal) or better trust zone (browse down) than the target (home server) then we need not use a passphrase on the key. If instead it is in a LESS trusted environment (i.e users pet laptop they take on holiday) accessing the administration jumpboxes (i.e. home server) then that is browse-up so the key gets protected with a long passpoem for that hop

This is closing in on SSH public key and sometimes vlan and cec access.

Since encryption only provides difficult to crack and not mathematically impossible, it could be combined with impossible (if configured correctly) separation via protected channel flags like vlan or priority bits.

Make a copy of /etc/ssh/sshd_config as /etc/ssh/sshd_config_example where _example is replaced with a name of user choosing. This preserves the original config file so that updates do not overwrite customisations.

In sshd_config_example

Tell sshd to use this file by adding two overrides

In /etc/systemd/system/ssh.service.d/override.conf:

  1. [Service]
  2. ExecStart=
  3. ExecStart=/usr/sbin/sshd -D $SSHD_OPTS -f /etc/ssh/sshd_config_example

In /etc/systemd/system/ssh@.service.d/override.conf:

  1. [Service]
  2. ExecStart=
  3. ExecStart=-/usr/sbin/sshd -i $SSHD_OPTS -f /etc/ssh/sshd_config_example

Then tell systemd to reload config with systemctl daemon-reload, and restart sshd, unless socket activation is used whcih is generally better.

Removing all priviledge escalation possibilties

It seems more secure to decend from root and lock oneself in, than to allow escalate privileges, so take applications like sudo off the system, ignoring the warning about not having a root password!

You have asked that the sudo package be removed, but no root password has been set. Without sudo, you may not be able to gain administrative privileges.

If you would prefer to access the root account with su(1) or by logging in directly, you must set a root password with "sudo passwd".

If you have arranged other means to access the root account, and you are sure this is what you want, you may bypass this check by setting an environment variable...

Having read the warning, can export the environment variable and then remove sudo.

Calling root from userspace without sudo

systemd allows the creation of custom units that can be used to open a portal to the root account from userspace to trigger things.

We can create a example.socket unit that listens on a unix socket, and an example@.service unit that "does things" as root.

Then, rather than issuing a sudo /path/to/program call, userspace invokes socat UNIX-CONNECT:/path/to/your/socket -, issuing commands, and awaiting responses when synchronous behaviour is needed.

This has the main advantage that we are not using setuid root, the calling program does not own the root process and therefore cannot exploit that. The security is still dependent on the root side validating input.