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 is important as any malware downloaded, that gains control over a user account that would have been used to elevate via run sudo, could whack away at the elevation utilities or steal an elevation credentials and save it for later abuse when the user is not watching. This is not very different than elevation via su, so rather than take chances, disable both of them and obtain root differently!
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.
If the machine console is secured as the machine, anyone having VT access already has root access, 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.
Most use is on X11 which runs as the normal user anyway, so switching VT is most often for accossing root, and if that is not needed, the first command issued would be runuser or su to change away from the root account.
It also means leaving the debug shell permanently enabled on F9 is quite reasonable.
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, actually is asterisks all the way down.
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
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
It has been found that some persons fixate rather more about insiders, administrators going rogue and the like than the outsider threats.
Most of the time the admins are fundamentally good persons that can just be clumsy sometimes, and for that just trying to have good habits like dropping priviledges, using read-only accounts to explore where possible, and automated backups to help out when things go wrong are all for the good. If selecting computer equipment and a network layout, if it's good enough for the office it likely be good enough for the home and the reverse too.
Wanting to bite back on their owner that feeds is another tale, it does have to be addressed as the fears are real, though hopefully not via vertical privilege escalation paths.
As an example, copying a disk, starting from root.
Still strategy for audit trails and sometimes requiring the cooperation and quorum of multiple administrators to carry out tasks can be desired and is anyway advantagous to have a culture of # console sharing, as in agile projector programming, much like double signature cheques. Even with this being, want to minimise priviledge escalation tools mid path between the keyboards of admin and targets.
In this situation there will be very often be jumpboxes that provide the administrative access to targets, that may require the cooperation of multiple administrators if they exist, to load and replace keys.
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 that machine's root over SSH, that includes via setuid binaries, root is still being accessed remotely. Instead try to reduce away from requiring root as possible.
Consequently leaving PermitRootLogin with the default setting of prohibit-password, as coming in and then escalating again via an internal backdoor to get to root is an anti-pattern!
For those that obsess over insiders, 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.
There were other good ideas that I got from scap though, like usbguard/auditd
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 such as /usr/local/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:
In /etc/systemd/system/ssh@.service.d/override.conf:
Then tell systemd to reload config with systemctl daemon-reload, and restart sshd, unless socket activation is used whcih is generally better.
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.
It its factory state sudo may be fairly safe by disallowing any privilege escalation.
If sudo is not actually being used for anything and also has no hard dependencies on other apps, it may be purged to tighten the attack surface some more. su would already be quite useless for an attacker when root is *, and without them, even consider executing mount -o remount,nosuid /
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.