Strong Linux User Account Isolation

Kicksecure ™

Download

On Computer USB Installation Debian morph to Kicksecure Windows (VM) Linux (VM) Mac (VM) VirtualBox (VM) KVM (VM) Qubes (VM) More options Source Code

About

Overview Features Why Open Source? Project Activities Contributors Mission & Vision

Docs

Documentation FAQ Troubleshooting

Community

Forums Contribute

Support

Self Support First Policy Search Engines, Docs and AI Support (Limited) Reporting Bugs Contact (Restricted)

Tools Upload file Special pages Recent changes Print Version Page meta What links here Related changes Page information

Page Read Edit History Move Protection Unwatch Watch Delete Purge

User Preferences Watchlist Contributions Logout Create account Login

Donate

• Default Passwords
• Passwords
• User Management
• Login
• Login Spoofing
• Safely Use Root Commands
• sysmaint user
• Protection against Physical Attacks
• User Account Isolation (developers)
• user-sysmaint-split (developers)

Protect Linux User Accounts against Brute Force Attacks, Root Account Locking, Console Lockdown, sudo password sniffing, X Windows System Password Sniffing, /proc/pid/sched spy on keystrokes, Linux user account cracking, pam_faillock, pam-tally2, pam-cracklib, /etc/securetty

Introduction

User account isolation and root rights is a very relevant, but often overlooked security topic for many Linux distributions. In this chapter we will give you an overview about the history, possible attack vectors, security measures that you can implement youself and the plenty security measures that are implemented in Kicksecure by default.

• We are aiming to provide a comprehensive, rather complete overview. There are many advanced details being discussed in many places on the internet, but explanations of the essential foundations are hard to find. When this topic is usually discussed, there is a large amount of unspoken assumptions and threat models. Example :

  The solution to this is simple: you shouldn't be logging in on the console as root in the first place! (What, are you crazy or something?). Proper Unix hygiene dictates that you should log in as yourself, and su to root as necessary. People who spend their day logged in as root are just begging for disaster.XScreenSaver FAQ, answer to "When I'm logged in as root, XScreenSaver won't lock my screen!"

  Sounds quite important, right? Is it? What kind of disaster awaits if being logged in as root? No automatic security disaster. Many applications (such as Kate; Wayland) refuse to run as root. Due to this convention, it is best to go with the flow (what most Linux distributions do) and avoid being logged in as root. As many actions as possible should be done with a non-root user.
• Avoiding root compromise is useful for reasons explained in chapter Rationale.
• Many applications nowadays run under different Linux user accounts. For example, the web server and database server very likely run under different Linux user accounts.
• Many of the things written about sudo, su, root, and user isolation are correct but written in a different time and/or with a different threat model in mind.
• Is sudo a security tool? Yes. But what does this mean? sudo provides an audit trail. It keeps a log of all invocations of sudo. Specifically, if there are multiple system administrators, and there is an unexplained issue, they can look at the logs and investigate who performed which action. By default, this only works in non-malicious cases. An attacker with root rights also has the ability to remove evidence of their own actions from logs. Secure, tamper-proof append-only logs is a different security problem to solve.
• Password input security: The sudo project does not guarantee a secure password entry mechanism. Various attack vectors, such as malware, can compromise password security by intercepting or sniffing passwords entered via sudo. This is being elaborated in chapter Issues.
• Password encryption: But how can malware steal the password? Aren't passwords encrypted? Yes, passwords are encrypted in /etc/shadow file. Additionally, non-root users cannot read /etc/shadow file thanks to default file permissions. This, however, is of little help against malware. As elaborated in chapter Issues, what malware actually can do to steal the password does not involve attacking the encryption. The encryption of passwords in /etc/shadow is only useful in a different threat model. For example, if an attacker gained access to /etc/shadow (by possibly getting access through full system compromise), then at least the attacker still does not know that user's password. This can be useful in case the user re-used this password elsewhere, for example to log in to their online banking.
• single-user system vs multi-user system: The usefulness of sudo also depends on whether it is a single-user system or a multi-user system. This is elaborated in chapter Information.
• Local system vs remote server: When using password-based login, the user password matters. However, password-based logins are only safe when logging into a machine locally. Public key authentication is much more secure for remote access.

Essentials

In this chapter we would like to introduce the topic of user account isolation more broadly.

History

• Sharing the root password historically when one computer was often shared by multiple system administrators was bad. When someone changed the root password and did not properly record the new password, other system administrators could no longer easily login. Hence, sudo has been developed.
• With sudo it became possible for individual users to login as root (sudo su) or to execute individual commands with root rights (sudo command).
• From one of the co-authors of sudo:

  I am the co-author of sudo. It was written in the early 80's specifically to address a need to protect the integrity of a shared resource (A VAX-11/750 running BSD UNIX) from its users (the faculty of the CS Department at SUNY/Buffalo). At the time, the only other option was 'su' which required everyone share a single password. Had a calamity occurred it would have been difficult or impossible to sift through the forensics ...Bob Coggeshall, co-author of sudo , complete answer here

Isolation rationale and benefits

Oftentimes when we think of a user account, we think of an account on the system that someone is intended to log into. However, most systems have a large number of user accounts even if they are only intended to be used by a single person. This is because there are many background processes that run on most computers. Many of these background processes introduce some form of attack surface, or work with sensitive information that other background processes or other people should not be able to access. To reduce the risk of unauthorized access or severe damage in the event of a compromise, these services are given user accounts with appropriately restricted permisisons. If one of those background processes becomes compromised, the attacker will not be able to easily read or write data that the user account restricts them from accessing.

When properly implemented, user account isolation provides three main benefits:

• It hinders system accounts from attacking other system accounts or people's user accounts. This reduces (though does not eliminate) the risk of a compromised service resulting in the entire system being compromised.
• It hinders people's user accounts from attacking other people's user accounts or system accounts. This reduces (though does not eliminate) a malicious user's ability to steal data or compromise accounts they aren't supposed to access. This is only useful on systems that are used by more than one person, such as server machines.
• It hinders both system accounts and people's user accounts from gaining unauthorized access to the root account. Root account access allows one to access any data or compromise any accounts or processes on the system, thus making it a frequent target for attackers.

Defenses against root user exploits

In this chapter we compare non-hardened vs. Kicksecure-hardened Linux Distributions and discuss various defense strategies implemented by Kicksecure.

Non-Hardened Linux Distributions

Defenses: low - for most if not all Linux desktop operating systems

• By default, a compromised non-root user account which is member of group sudo is almost equal to full root compromise as there are too many ways for an attacker to retrieve the sudo password. Malware can sniff the sudo password.
• Compromised non-root users that are not member of group sudo in order to acquire root compromise require either,
  • A) a local privilege escalation exploit, or
  • B) brute forcing the root password.
  • For example, were the web server user (www) to become compromised, it could not gain root without that.
• Home folder (~) (such as for example home folder of user user /home/user) might be readable by other users (such as for example by user user2 or www). This to a large degree negates the usefulness of linux file permissions. While compromised user accounts might not be able to destroy user data, all private user data might be exfiltrated.

Kicksecure Hardened Linux Distributions

Defenses: high - for Kicksecure-hardened Linux desktop operating systems

Kicksecure implements various mechanisms to implement strong linux user account isolation:

• Console Lockdown
• Anti Bruteforcing of Linux User Account Passwords
• disable root login
• su restrictions
• sudo restrictions
• access rights restrictions (permission lockdown)
  • Such as for example home folder (~) of user user /home/user being readable only by user user and not by user www.
• Usability: if the advanced advice to Prevent Malware from Sniffing the Root Password is not followed, then users will only require a single, secure root password for the user user account. It is no longer necessary to have two secure passwords for the user user and root accounts.

Prevention of Malware Sniffing the Root Password is currently only functional for advanced users following the documentation.

Once proposal user-sysmaint-split (Role-Based Boot Modes) has been implemented there will be a strong guidance for users to better separate their limited (everyday use) account (user) and administrative account (sysmaint). This would result in a robust Prevention of Malware Sniffing the Root Password.

Console Lockdown

Console lockdown allows only members of group console to use console. Everyone else except members of group console-unrestricted are restricted from using console using ancient, unpopular login methods such as using /bin/login over networks, which might be exploitable. (CVE-2001-0797) Using pam_access. It is active for pam service login. Implemented in package security-misc.

This also has good usability. Attempts to login into console for users which are not a member of group console would result in an error message.

By Kicksecure and Kicksecure default:

• Console lockdown is enabled by default in Kicksecure version 15.0.0.8.7 and above.
• Only user user is a member of group console by default.
• There are no default members of group console-unrestricted.

Related files:

• https://github.com/Kicksecure/security-misc/blob/master/usr/share/pam-configs/console-lockdown-security-misc
• https://github.com/Kicksecure/security-misc/blob/master/usr/libexec/security-misc/pam_only_if_login
• https://github.com/Kicksecure/security-misc/blob/master/etc/security/access-security-misc.conf
• https://forums.whonix.org/t/etc-security-hardening-console-lockdown-pam-access-access-conf/8592

Kicksecure is an Implementation of the Securing Debian Manual. This chapter has been inspired by: Securing Debian Manual, chapter Choose a BIOS password

Kicksecure is an Implementation of the Securing Debian Manual. This chapter has been inspired by: Securing Debian Manual, chapter User access control in PAM

Kicksecure is an Implementation of the Securing Debian Manual. This chapter has been inspired by: Securing Debian Manual, chapter Disallow remote administrative access

Bruteforcing Linux User Account Passwords Protection

Bruteforcing into Linux user accounts is severely limited in by package security-misc.

• Lock user accounts after 50 failed login attempts using faillock until password unlock procedure is required.
• https://github.com/Kicksecure/security-misc/blob/master/usr/share/pam-configs/faillock-security-misc
• https://github.com/Kicksecure/security-misc/blob/master/usr/share/pam-configs/faillock2-security-misc
• This also has good usability. After the first authentication failure, pam_tally2-info by security-misc will show the number of remaining login attempts before unlock procedure will be required. Once required, will show a link to documentation how to perform unlock procedure.

forum discussion: protect Linux user accounts against brute force attacks

issues:

• PAM issue: pam_faillock tally and lockout status is reset by running a command with a NOPASSWD exception using sudo
• sudo issue: NOPASSD exceptions in /etc/sudoers(.d) interact poorly with pam_faillock, no configuration option available to allow sudo to tell PAM when a NOPASSWD command is being run

Online Password Cracking Restrictions

A secure password for root/user accounts does not necessarily have to follow the rationale explained on the Passwords page. Offline attacks against the password (parallelization, password cracking attempts only limited by RAM, disk, and CPU) are not possible. Only "online" attacks are possible. Similar to attempts of cracking a password of a user account on a website. Only x attempts every y time are possible. See also Bruteforcing Linux User Account Passwords Protection.

https://security.stackexchange.com/questions/213084/how-strong-do-linux-user-account-passwords-have-to-be-when-using-full-disk-encry

/etc/securetty

Package security-misc removes all non-comments from /etc/securetty. Thereby root login and ancient consoles can no longer be used to attempt root login.

• https://github.com/Kicksecure/security-misc/blob/master/etc/securetty.security-misc

Kicksecure is an Implementation of the Securing Debian Manual. This chapter has been inspired by: Securing Debian Manual, chapter User access control in PAM

Root Login Disabled

Root login is disabled by default since Kicksecure 15.0.0.3.6.

Only one user account with password and no root account login supported by default also means the user has only to remember and secure one rather than two strong passwords.

usability:

• Root login failures do not count as a failed login attempt fortunately to the faillock implementation by security-misc.

related files:

• https://github.com/Kicksecure/security-misc/blob/master/usr/share/pam-configs/pam-abort-on-locked-password-security-misc
• https://github.com/Kicksecure/security-misc/blob/master/usr/libexec/security-misc/pam-abort-on-locked-password
• documentation: root

su restrictions

By Debian default, any user account can attempt to use su to try to switch to the root user or any other user account. Any user account can try to bruteforce switching to another user account. Kicksecure / Whonix (package security-misc) configure that group sudo membership required to use su using pam_wheel.

• https://github.com/Kicksecure/security-misc/blob/master/usr/share/pam-configs/wheel-security-misc

SUID Disabling and Permission Hardening by security-misc removes SUID from su and many other binaries by default for further hardening.

User documentation: Safely Use Root Commands chapter Substitute User (su) Command

related development discussion: https://forums.whonix.org/t/restrict-root-access/7658

Console Login Attacks

Blocking access to su would be ineffective if it were possible for a compromised user account to log into another user account by switching to a virtual terminal and bruteforcing the password from there. However, this is not possible due to access controls in the Linux kernel. This section explains how this works.

The Linux kernel provides various virtual console devices to userspace, generally through the /dev/tty* devices. In order to switch between virtual console devices, the user must have write access to at least one of these devices. By default, these devices are owned by root and can only be read and written by the owning user. This prevents any non-root process from accessing virtual consoles without root access.

One or more login processes are automatically started on some of these virtual terminals by the init program, which run as root and provide a login prompt to the user. These cannot be accessed without being able to read from and write to the virtual console each process runs on. Due to the permission restrictions mentioned above, no user process can attempt to log into the system as another user through the console without already having root privileges. When a user does log in using a virtual console, the login process controlling that console will change the permissions on it so that the user that just logged in can read and write data on that console. This permits them to interact with whatever program is executed on the console (typically a shell such as bash). Once the user logs out, the console device's permissions are changed back, preventing processes running as the user from exploiting the console login system to log in as someone else.

This is about where the process is started and what has connected as controlling terminal. It isn't anything Qubes specific. A non-privileged process cannot inject characters into a separate session (let's forget about X11 breaking all this assumptions, as we are talking about non-X11 session), especially if it's of a different user, similarly as it cannot write to files it doesn't have write permission. to. You can think of it as a write access to /dev/tty (or /dev/hvc0 in this case). When you login on /dev/hvc0, login process (running as root) will setup permission to /dev/hvc0 and also pass an open FD to it to your shell. Then, you (user, and that shell) will be able to interact with /dev/hvc0 and specifically run commands connected to it. If you don't login there, login process will not set the permissions, so you won't have access. This does assume kernel enforced permissions are effective, but as we are talking here about in-VM account isolation only, it's a reasonable assumption.Comment by Marek Marczykowski-Górecki, Qubes lead developer

This raises the question of how it is possible to switch between virtual consoles using a keypress such as Ctrl+Alt+Fn, or by using a command such as chvt. Virtual console switching is done by one of two things - the kernel virtual console code itself, or a program that can control any one of the virtual console devices. If you are logged in at a TTY, and press a Ctrl+Alt+Fn key combo, the kernel's virtual console code will detect the keypress, and switch to the desired virtual terminal. If you use the chvt command while logged into a virtual terminal, it will be able to switch to another virtual terminal because the virtual terminal the user logged in at is now readable and writable by the logged in user. It can thus access it and tell the kernel virtual terminal code to switch to a different virtual terminal. When you have a running graphical session, things are slightly more complicated, because the X server will take control of one of the virtual consoles, and when one presses Ctrl+Alt+Fn, that keypress will go to X, not the kernel virtual console code. In this instance, X will interpret the keypress and instruct the kernel's virtual terminal code to switch to the user's desired virtual console.

With the above rules in place, the only way to gain read/write access to a virtual terminal is to:

• Have physical access to the computer, thus giving one the ability to communicate directly with the kernel virtual terminal code.
• Or, be running under a user account that has logged in at a virtual terminal already.
  • In this latter instance, software running as the logged-in user could switch to a different virtual terminal, but it would not be able to attempt to login at that terminal. That would require read/write access to the virtual terminal that was switched to, and virtual terminals that have a login prompt are only able to be read from and written to by root or a person with physical access to the machine.

It is also possible to communicate with an application that is controlling a virtual terminal. The most obvious example of this is when the X server is running as root (which it does by default on Debian-based systems, Kicksecure included). In this instance it is possible to do some limited console-level actions (namely switching to a different virtual terminal) even without direct read/write access to any virtual terminal device (for instance, by using xdotool to emulate a Ctrl+Alt+Fn keypress). Even in this scenario however, a malicious process that did this would not be able to login at the virtual terminal that was switched to, because it would not have read/write access to the virtual terminal that it switched to.

sudo restrictions

By Debian default, users who are not members of the group sudo cannot use sudo. Therefore limited user accounts (for example user sdwdate) cannot use sudo to attempt to crack other user account passwords to run under these users.

Permission Lockdown

Strong Linux User Account Separation. Access rights restrictions.

For example, user1 with home folder /home/user1 cannot read user2's files in /home/user2 home folder.

Removes read, write and execute access for others for all users who have home folders under folder /home by running, for example, chmod o-rwx /home/user during package installation, upgrade, or PAM mkhomedir. This will be done only once per folder in folder /home, so users who wish to relax file permissions are free to do so. This is to protect previously created files in user home folders that were created with lax file permissions prior to the installation of this package.

• debian/security-misc.postinst
• /usr/libexec/security-misc/permission-lockdown
• /usr/share/pam-configs/mkhomedir-security-misc

Kicksecure is an Implementation of the Securing Debian Manual. This chapter has been inspired by: Securing Debian Manual, chapter Limiting access to other user's information

umask hardening

TODO: document

Complements Permission Hardening for folders outside of /home.

Discussions:

• https://forums.whonix.org/t/change-default-umask/7416
• https://github.com/Kicksecure/security-misc/issues/185
• https://github.com/Kicksecure/security-misc/pull/194
• https://github.com/Kicksecure/security-misc/pull/282

Kicksecure is an Implementation of the Securing Debian Manual. This chapter has been inspired by: Securing Debian Manual, chapter Setting users umasks

libpam-tmpdir

Many programs use $TMPDIR for storing temporary files. Not all of them are good at securing the permissions of those files. libpam-tmpdir sets $TMPDIR and $TMP for PAM sessions and sets the permissions quite tight. This helps system security by having an extra layer of security, making such symlink attacks and other /tmp based attacks harder or impossibleDebian package libpam-tmpdir - automatic per-user temporary directories

• make symlink attacks and other /tmp based attacks harder or impossible using libpam-tmpdir

General Issues

In this chapter general Linux-specific issues are discussed. These issues are unspecific to Kicksecure. Most if not all Freedom Software Linux desktop distributions are affected by one or multiple of these issues.

sudo password sniffing

A compromised user account user could be infected with a keylogger (which unfortunately, does not even require root access) which could trivially read the sudo password and thereby acquire root access.

Therefore, instructions to Prevent Malware from Sniffing the Root Password are still required. It's for advanced users only and awareness and usability is bad.

In future, user-sysmaint-split (Role-Based Boot Modes) might solve this issue.

Reasons:

• Users would have a strong guidance to separate use of user user through different boot modes.
• User user would not be a member of group sudo by default anymore.
• Only user sysmaint would be a member of group sudo by default.
• Every day activity considered higher risk such as browsing the internet would be done clearly separated under user user while activities such as package installation and system upgrades would be done using separate user sysmaint.
• Therefore the more likely compromised user user would not have a chance to sniff the sudo password and therefore would be hindered from escalating to root without a local privilege escalation exploit.

X Windows System

Any graphical application running under X Windows System (X11) can see what any user is typing in any other application for any user. For example, if user user running X11 would run lxsudo -u limited-user some-application a compromised graphical application could sniff anything that user user is writing. Including but not limited to any sudo password prompts. This is also the case for applications running under mandatory access control framework AppArmor.

See the following footnotes for references about security issues with GUI isolation related to X Windows System (X11).

Potential solutions:

• Can AppArmor prevent sudo password sniffing through abuse of X Windows System?
• Can we replace xfce window manager as an easy path to switch to wayland?
• In future, multiple boot modes for better security: persistent + root | persistent + noroot | live + root | live + noroot might solve this issue for similar reasons as in above chapter.

Help welcome!

/proc/pid/sched spy on keystrokes

The /proc filesystem leaks a lot of information about other processes which allows attackers to spy on certain processes a large amount. One example is /proc/pid/sched which allows attackers to spy on keystrokes but there is definitely far more information leakage than just that.

• https://forums.whonix.org/t/proc-pid-sched-spy-on-keystrokes-proof-of-concept-spy-gksu/8225
• https://www.openwall.com/lists/oss-security/2011/11/05/3
• https://forums.whonix.org/t/apparmor-for-complete-system-including-init-pid1-systemd-everything-full-system-mac-policy/8339/363

Potential solutions:

• hidepid=2 mount option to hide processes from other users - this would prevent spying on processes of other users but since most people run most of their apps as the same user, the benefits are limited unless multiple users are being used
• PID namespaces to hide processes from outside the namespace and can be used for sandboxing apps - this would prevent spying on processes outside of the sandbox
• apparmor.d to give fine-grained restrictions over /proc

LD_PRELOAD

LD_PRELOAD is an environment variable which specifies certain libraries to preload for an application. An attacker can preload their malicious library globally to log keystrokes or even worse, hijack the program.

There are many examples of LD_PRELOAD rootkits in Linux. One example is:

• https://github.com/Aishou/wayland-keylogger

Potential solutions:

• Use environment scrubbing for everything in apparmor.d.

Setting up a fake sudo

An attacker can setup a fake sudo binary so the user gives them their password. Here is a simple example attack implementation on how to accomplish that.

cat <<\EOF > /tmp/sudo #!/bin/bash if [[ "${@}" = "" ]]; then /usr/bin/sudo else read -r -p "[sudo] password for user: " password echo "${password}" > /tmp/password echo "Sorry, try again." /usr/bin/sudo ${@} fi EOF chmod +x /tmp/sudo export PATH="/tmp:${PATH}"

This example attack implementation has in theory a lot room for improvement but that is besides the point being made here.

Specifying the file path of the real sudo will not work either:

function /usr/bin/sudo { echo "Doesn't work"; } function /bin/sudo { echo "Doesn't work"; }

Potential solutions:

• None except getting rid of sudo access

Mounting all user-writeable places such as /home and /tmp as non-executable is not a solution because an attacker can use the bash interpreter to bypass the restrictions using bash /path/to/script. Would interpreter lock help?

Device timing sidechannels

Device timing sidechannels may allow keylogging but more research needs to be done on this.

https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Eliminate_stat/notify-based_device_sidechannels

If you say Y here, timing analyses on block or character devices like /dev/ptmx using stat or inotify/dnotify/fanotify will be thwarted for unprivileged users. If a process without CAP_MKNOD stats such a device, the last access and last modify times will match the device’s create time. No access or modify events will be triggered through inotify/dnotify/fanotify for such devices. This feature will prevent attacks that may at a minimum allow an attacker to determine the administrator’s password length.

Potential solutions:

• linux-hardened fixes this by restricting it to CAP_MKNOD

Passwords

Default Empty Password Security Impact

Does a default password such as changeme provide better security than an empty by default password? No, because malware could easily use dsudo to enter changeme into the sudo prompt.

Rationale for Change from Default Password changeme to Empty Default Password

• Usability: Better usability.
• No impact on security: See Default Empty Password Security Impact.
• Security theater: A default public known account password for user user is security theater. Due to many issues, having a user password to password protect running sudo from the user account is also security theater in many contexts. When a user password makes sense is documented in the user documentation.
• User documentation: See Default Passwords.
• Real security: See the Safely Use Root Commands, especially Prevent Malware from Sniffing the Root Password (SysRq based solution).
• Root login: Root Login Disabled remains unchanged.
• No user freedom restriction: The users ability to configure a user account password remains unchanged. It is still possible to set a password.
• Accidental copy/paste of sudo command not a concern: A terminal window is very powerful, dangerous in any case. One needs to know what one is doing. A destructive command such as rm -rf ~/file-name * where the user actually meant to write rm -rf ~/file-name* can delete all user data. Only preventing sudo does not make a sufficient difference.
• Secure Administrative Rights Prompt Infeasibility: There are too many issues which prevent the creation of a secure root prompt that cannot be trivially broken by malware. It is technically challenging to fix all of them. These are generic issues applicable to most if not all Freedom Software desktop Linux distributions. In other words, these issues are unspecific to Kicksecure.
  • Future: A "boot into sysmaint mode" feature is planned. This is elaborated in chapter sudo password sniffing.
• Comparison: How did Google Android and Apple iOS solve this issue? By having developed different graphical interfaces and user freedom restrictions where the used is being refused administrative rights.
• Forum discussion: default password (changeme) impact

Default Password Implementation Level

What technically changed.

Instead of running echo "${user_to_be_created}:${password}" | chpasswd --encrypted, now passwd --delete user is run during the build process in dist-base-files debian/dist-base-files.postinst.

Related /etc/shadow entry, before 17.2.0.1 and below:

user:aTayYxVyw5kDo:19935:0:99999:7:::

After, build version 17.2.0.7 and above:

user::19932:0:99999:7:::

Conclusions

• In Kicksecure based Linux distributions:
  • On single-user systems:
    • Assessment: There should be no way for potentially compromised applications running under limited Linux user accounts (such as for example user sdwdate) - if compromised by malware - to login to other user accounts such as root or user user. This is thanks to the following security features:
      • A) Console Lockdown
      • B) su restrictions
      • C) sudo restrictions
      • D) Bruteforcing Linux User Account Passwords Protection
      • E) Online Password Cracking Restrictions
    • Malware Compromise Considerations: Strong Linux user account passwords should be unnecessary for protection from locally running malware unless above security features can be circumvented.
  • On multi-user systems:
    • Definition: A multi-user system is defined here as a shared computer that has multiple human users.
    • Assessment: Similar to single-user systems, but additional Linux user accounts (such as for example user user2) will need to be added to Linux user group console. Therefore security feature Console Lockdown (A) will be ineffective against attacks from the added user accounts. In effect, strong Linux user account passwords are more important. However, other security features (B, C, D, E) still providing protection.
  • Remote Login:
    • Systems using remote login (such as SSH): A strong password might make sense during initial SSH setup, before public key authentication has been set up. Once exclusively using public key authentication, password authentication should be disabled entirely. Once public key authentication is being used exclusively, a strong password should be no longer required for remote login.
    • Systems not using remote login: No requirements for a strong password to protect remote logins since not using any remote login mechanism.
  • Threat: Could a compromised user user escalate to root if user user was compromised?
    • If using procedure Prevent Malware from Sniffing the Root Password: no
    • If not using procedure Prevent Malware from Sniffing the Root Password: yes, due to issues.
  • Protection against Physical Attacks: This is a mostly unrelated issue. A screen lock might be sufficient protection from lesser adversaries. In that case, a host screen locker and a better, non-default Linux account user password on the host operating system might help, as the login password will also be used for the screen lock.

Related Topics

• https://forums.whonix.org/t/restrict-root-access/7658
• https://forums.whonix.org/t/how-strong-do-linux-user-account-passwords-have-to-be-when-using-full-disk-encryption-fde-too/7698/8
• https://forums.whonix.org/t/is-it-safe-to-install-keepassxc-on-gateway/16391
• VirusForget: about problematic files such as ~/.bashrc and other folders which malware can use to fake or sudo prompt and/or to persist after boot
• multiple boot modes for better security: persistent + root | persistent + noroot | live + root | live + noroot
• walled garden, firewall whitelisting, application whitelisting, sudo lockdown, superuser mode, protected mode
• root

Resources

• https://serverfault.com/questions/57962/whats-wrong-with-always-being-root
• https://www.howtogeek.com/124950/htg-explains-why-you-shouldnt-log-into-your-linux-system-as-root/
• https://unix.stackexchange.com/questions/244124/why-does-turnkey-linux-not-have-sudo-installed-by-default-if-youre-never-suppo
• https://unix.stackexchange.com/questions/106529/why-is-sudo-not-installed-by-default-in-debian

User Freedom

Kicksecure / Whonix / security-misc does not restrict user freedom. All default settings can be undone. Everything is configurable and documented on page Root.

See also

• Default Passwords
• Passwords
• User Management
• Login
• Login Spoofing
• Safely Use Root Commands
• sysmaint user
• Protection against Physical Attacks
• User Account Isolation (developers)
• user-sysmaint-split (developers)

Footnotes

Kicksecure A secure by default operating system with the latest security research in place.

Dark mode

Follow us on social media

Supported by Power Up Privacy

Kicksecure is proudly supported until 2025 by Power Up Privacy, a privacy advocacy group that seeks to supercharge privacy projects with resources so they can complete their mission of making our world a better place. (Strictly subject to our sponsorship policy.)

At Kicksecure we value freedom and trust, supporting Open Source and Freedom Software

By using this website, you acknowledge you have read, understood, and agree to be bound by these agreements: Terms of Service, Privacy Policy, Cookie Policy, E-Sign Consent, DMCA, Imprint 2012- 2024 ENCRYPTED SUPPORT LP

Your support makes
all the difference!

We believe security software like Kicksecure needs to remain Open Source and independent. Would you help sustain and grow the project? Learn more about our 12 year success story and maybe DONATE!