Strong Linux User Account Isolation

From Kicksecure
< Dev
Jump to navigation Jump to search

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[edit]

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 yourself, and the plenty of 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!archive.org"

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: Useful for reasons explained in chapter Rationale.
  • Applications under separate user accounts: 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.
  • Context and threat models: Many of the things written about sudo, su, root, and user isolation are correct but were 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 elaborated in chapter Issues.
  • Password encryption: But how can malware steal the password? Aren't passwords encrypted? Yes, passwords are encrypted in the /etc/shadow file. Additionally, non-root users cannot read the /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 the 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[edit]

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

History[edit]

  • Root password sharing issues: Historically, sharing the root password was problematic when one computer was shared by multiple system administrators. If someone changed the root password without properly recording the new password, other administrators could no longer log in.
  • Development of sudo: To address this issue, sudo was developed.
  • Functionality of sudo: With sudo, individual users could:
    • Log in as root (sudo su)
    • Execute individual commands with root rights (sudo command).
  • Insight from sudo's co-author:

    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 [1], complete answer herearchive.org

Isolation rationale and benefits[edit]

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 many background processes run on most computers.

  • Attack surface and sensitive data: 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.
  • Restricted permissions: 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 permissions.
  • Compromise containment: If a background process 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:

  • Protection of system accounts:
    • Attack prevention: Hinders system accounts from attacking other system accounts or people's user accounts.
    • Risk reduction: Reduces (though does not eliminate) the risk of a compromised service resulting in the entire system being compromised.
  • Protection of people's user accounts:
    • Account isolation: Hinders people's user accounts from attacking other people's user accounts or system accounts.
    • Malicious user prevention: Reduces (though does not eliminate) a malicious user's ability to steal data or compromise accounts they aren't supposed to access.
    • Multi-user system relevance: This is particularly useful on systems used by more than one person, such as server machines.
  • Root account protection:
    • Unauthorized access prevention: Hinders both system accounts and people's user accounts from gaining unauthorized access to the root account.
    • Frequent attack target: Since root account access allows one to access any data or compromise any accounts or processes on the system, it is a frequent target for attackers.

Defenses against root user exploits[edit]

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

Non-Hardened Linux Distributions[edit]

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

  • Root compromise risk with sudo accounts:
    • Equal to root compromise: By default, a compromised non-root user account that is a member of the group sudo is almost equivalent to a full root compromise.
    • Password retrieval risk: There are too many ways for an attacker to retrieve the sudo password.
    • Malware risk: See: Malware can sniff the sudo password.
  • Non-sudo account compromise:
    • Conditions for root compromise: Compromised non-root accounts that are not members of the group sudo require either:
      • A) A local privilege escalation exploit, or
      • B) Brute-forcing the root password.
    • Example scenario: If the web server account (www) becomes compromised, it cannot gain root without fulfilling one of these conditions.
  • Home folder readability:
    • Cross-account data access: By default, the home folder (~) of one account (e.g., /home/user) might be readable by other accounts (e.g., user2 or www).
    • Reduced file permission effectiveness: This significantly reduces the usefulness of Linux file permissions.
    • Data exfiltration risk: While compromised user accounts might not be able to destroy other user account's data, they can exfiltrate all private user data.

Kicksecure Hardened Linux Distributions[edit]

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

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

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[edit]

Console lockdown restricts console access to members of the group console. Everyone else, except members of the group console-unrestricted, is restricted from using the console. This includes blocking access via ancient, unpopular login methods such as /bin/login over networks, which might be exploitable (CVE-2001-0797archive.org). This is implemented using pam_access for the PAM service login (/etc/pam.d/login), and is part of the package security-miscarchive.org.

This also has good usability.archive.org Attempts to log in to the console by users who are not members of the group console result in an error message.

By Kicksecure default:

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

Related files:

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

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

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

Bruteforcing Linux Account Passwords Protection[edit]

Bruteforcing into Linux user accounts is severely limited by the package security-miscarchive.org.

Forum discussion: protect Linux accounts against brute force attacksarchive.org

Issues:

Online Password Cracking Restrictions[edit]

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 limited only by RAM, disk, and CPU) are not possible. Only "online" attacks are feasible, similar to attempts to crack a password of a user account on a website.

These attacks are limited to a specific number of attempts (e.g., 50 failed login attempts) within a defined time period (TODO). After the limit is reached, the account is locked, and additional steps, such as a password unlock procedure, are required.

See also: Bruteforcing Linux User Account Passwords Protection

Relevant discussion: How strong do Linux user account passwords need to be when using full-disk encryption?archive.org

/etc/securetty[edit]

The package security-miscarchive.org removes all non-comment lines from /etc/securetty. As a result, root login and ancient console-based root login attempts are effectively disabled.

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

Root Login Disabled[edit]

Root login has been disabled by default since Kicksecure 15.0.0.3.6.

For users that require account password protection, having only one user account with a password and no root account login by default simplifies security. This setup ensures users only need to remember and secure one strong password instead of two.

Usability:

  • Root login failures do not count as failed login attempts, thanks to the faillock implementation by security-misc.

Related files:

Documentation: root

su restrictions[edit]

By default in Debian, any user account can attempt to use su to switch to the root user or another user account. This means any user can attempt to bruteforce switching to another account. Kicksecure / Whonix (via the package security-miscarchive.org) restricts this behavior by requiring group sudo membership to use su, utilizing pam_wheelarchive.org.

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

User documentation:

Related development discussion:

su success sample log[edit]

Jan 06 05:28:43 work-main su[51364]: pam_exec(su:auth): /usr/libexec/security-misc/pam_only_if_su failed: exit code 1
Jan 06 05:28:43 work-main su[51364]: pam_wheel(su:auth): Ignoring access request 'user2' for 'root'
Jan 06 05:28:43 work-main su[51366]: pam_exec(su:auth): Calling /usr/libexec/security-misc/pam-info ...
Jan 06 05:28:43 work-main su[51364]: pam_exec(su:auth): /usr/libexec/security-misc/pam_faillock_not_if_x failed: exit code 1
Jan 06 05:28:45 work-main su[51364]: pam_exec(su:auth): /usr/libexec/security-misc/pam_faillock_not_if_x failed: exit code 1
Jan 06 05:28:45 work-main su[51380]: pam_exec(su:auth): Calling /usr/libexec/security-misc/pam-abort-on-locked-password ...
Jan 06 05:28:45 work-main su[51364]: (to root) user2 on pts/6
Jan 06 05:28:45 work-main su[51364]: pam_unix(su:session): session opened for user root(uid=0) by user(uid=1001)
Jan 06 05:28:45 work-main su[51364]: pam_succeed_if(su:session): requirement "uid eq 0" was met by user "root"

Annotated: 

Jan 06 04:50:17 work-main su[37262]: pam_exec(su:auth): /usr/libexec/security-misc/pam_faillock_not_if_x failed: exit code 1

Jan 06 04:50:19 work-main su[37262]: pam_exec(su:auth): /usr/libexec/security-misc/pam_only_if_su failed: exit code 1

Expected. See file /usr/libexec/security-misc/pam_faillock_not_if_x and /usr/libexec/security-misc/pam_only_if_su for implementation and comments. 

Jan 06 04:50:19 work-main su[37262]: pam_wheel(su:auth): Ignoring access request 'user2' for 'root'

su access of user2 for root was permitted because user2 was a member of group sudo.

unix_chkpwd error[edit]

Jan 06 05:25:43 work-main unix_chkpwd[50748]: check pass; user unknown

chmod +s /usr/bin/su

Should not be required: 

chmod +s /usr/sbin/unix_chkpwd

su failure sample log[edit]

Jan 06 05:17:22 work-main su[49202]: pam_exec(su:auth): /usr/libexec/security-misc/pam_only_if_su failed: exit code 1
Jan 06 05:17:22 work-main su[49202]: pam_wheel(su:auth): Access denied to 'user3' for 'root'
Jan 06 05:17:22 work-main su[49202]: FAILED SU (to root) user3 on pts/9

Annotated: 

Jan 06 05:17:22 work-main su[49202]: pam_exec(su:auth): /usr/libexec/security-misc/pam_only_if_su failed: exit code 1

Expected. See file /usr/libexec/security-misc/pam_faillock_not_if_x and /usr/libexec/security-misc/pam_only_if_su for implementation and comments. 

Jan 06 05:17:22 work-main su[49202]: pam_wheel(su:auth): Access denied to 'user3' for 'root'

su access of user3 for root failed because user3 was a member of group sudo.

Console Login Attacks[edit]

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

The Linux kernel provides various virtual console devices to userspace, typically through the /dev/tty* devices. 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.
  • They can only be read and written by the owning user.

This ensures that non-root processes cannot access virtual consoles without root privileges.

One or more login processes are automatically started on some of these virtual terminals by the init program. These processes run as root and provide a login prompt to the user. They cannot be accessed without the ability to read from and write to the virtual console each process runs on.

Due to the permission restrictions mentioned above, no user process can log into the system as another user through the console without already having root privileges. When a user logs in using a virtual console, the login process controlling that console changes the permissions on it so that the user who just logged in can read and write data on that console. This allows the user to interact with any program executed on the console (typically a shell such as bash).

Once the user logs out, the console device's permissions revert, preventing processes running as the user from exploiting the console login system to log in as another user.

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 developerarchive.org

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. The X11 server will take control of one of the virtual consoles, and when one presses Ctrl+Alt+Fn, that keypress will go to X11, not the kernel virtual console code. In this instance, X11 will interpret the keypress and instruct the kernel's virtual terminal code to switch to the user's desired virtual console. (Wayland, at the very least the SwayWM compositor and likely all other wlroots-based compositors, works in a similar or identical fashion here.)

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. 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 an X11 server is running as root (which it does by default on Debian-based systems, Kicksecure included). In this instance, it is possible to perform 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.

Wayland does not suffer from the same problems here as Wayland compositors generally run as a non-root user and can only be accessed by the user they run as (or by the root account). File permissions are used to protect the socket the compositor uses for communicating with graphical applications. The base Wayland protocol also does not make it particularly easy to inject keystrokes into the server the way X11 does, although there are additional input method protocols that allow Wayland clients to act as input devices. Therefore, one should not assume it is impossible for a program to inject input into Wayland if it can connect to the Wayland server.

sudo restrictions[edit]

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[edit]

Strong Linux User Account Separation. Access rights restrictions.

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

Removes read, write, and execute access for others for all users who have home folders under the 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 the /home directory, so users who wish to relax file permissions are free to do so. This protects previously created files in user home folders that were created with lax file permissions prior to the installation of the security-misc 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 Manualarchive.org, chapter Limiting access to other user's informationarchive.org

umask hardening[edit]

Complements Permission Hardening for folders outside of /home.

The umask (user file-creation mode mask) determines the default file permissions for newly created files and directories. By default, many systems set the umask to 022, allowing read access to all users. For enhanced security, especially in multi-user environments, it's advisable to set a more restrictive umask, such as 027, which restricts new files and directories to be accessible only by their owner.

The default umask for files created by non-root users, such as the user account, is set to 027.

This behavior is achieved through the PAM module configuration: pam_mkhomedir.so umask=027.

By setting this value, files created by non-root users are protected from being read by other non-root users by default. Although the /home folder is already secured by Permission Lockdown, this configuration provides additional safeguards for directories like /tmp.

group read permissions are retained, which is safe due to Debian's implementation of User Private Groups (UPGs). For further details, refer to: User Private Groupsarchive.org.

The root umask remains unchanged because system configuration files in /etc require "others" read access to avoid breaking applications. Examples of such files include /etc/firefox-esr and /etc/thunderbird. To address this, the umask for root is configured to 022 via sudoers, ensuring files created by root remain world-readable. This includes actions like sudo vi /etc/file or sudo -i; touch /etc/file.

Discussions:

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

libpam-tmpdir[edit]

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 directoriesarchive.org

General Issues[edit]

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[edit]

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

Therefore, instructions to Prevent Malware from Sniffing the Root Password are required. This is intended for advanced users only, as awareness and usability are poor.

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

Reasons:

  • Guidance for account separation: Users would have strong guidance to separate the use of the limited account user through different boot modes.
  • Group membership: user group sudo membership
  • Exclusive sudo access: Only account sysmaint would have the ability to use privilege escalation tools such as sudo, pkexec. (No Access to Privilege Escalation Tools for Limited Accounts)
  • Group membership: user group sudo membership
  • Separation of risky activities: Everyday activities considered higher risk, such as browsing the internet, would be done clearly separated under account user, while activities such as package installation and system upgrades would be performed using the separate account sysmaint.
  • Reduced risk of password sniffing: The more likely compromised account user would not have a chance to sniff the sudo password, thus hindering it from escalating to root without a local privilege escalation exploit.

X Windows System[edit]

Any graphical application running under X Windows System (X11) can see what any account is typing in any other application for any account. For example, if account user running X11 would run lxsudo -u limited-account some-application a compromised graphical application could sniff anything that account 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). [3] [4]

Potential solutions:

Help welcome!

Wayland application isolation[edit]

Wayland is designed to provide good isolation between simultaneously running graphical applications, while still allowing those applications to communicate with each other in controlled ways. In the base Wayland protocol, each window only knows about its own content, and events that are specifically passed to it by the compositor. It does not have any access to the contents, events, or even positions of other windows. This prevents things such as logging other application's keystrokes, reading other application's screen information, etc. This is mostly documented the Wayland Documentationarchive.org.

While the base protocol places severe restrictions on what windows know, Wayland compositors in general will allow some additional info to be shared with windows, depending on the particular compositor. For instance, compositors that implement the wlr-layer-shell protocol will allow surfaces to be created that have some knowledge about their position on the screen, while compositors that implement certain image capture protocols will allow applications to access the graphical contents of other windows. Compositors may also allow access to the screen contents or contents of individual windows through PipeWire and the system's xdg-desktop-portal implementation. In general, applications should not assume that other applications will not be able to snoop on their screen contents, even under Wayland. Keylogging is most likely not a concern.

/proc/pid/sched spy on keystrokes[edit]

The /proc filesystem leaks a significant amount of information about other processes, allowing attackers to spy on certain processes extensively. One example is /proc/pid/sched, which enables attackers to spy on keystrokes. However, the information leakage extends far beyond just that.

Potential solutions:

  • hidepid=2 mount option: This hides processes from other accounts, preventing spying on processes of other accounts. However, the benefits are limited unless multiple accounts are used, as most users run most applications under the same account.
  • PID namespaces: These hide processes from outside the namespace and can be used for sandboxing apps, effectively preventing spying on processes outside of the sandbox.
  • apparmor.darchive.org profiles: This provides fine-grained restrictions over /proc, offering a more targeted approach to mitigating information leakage.

LD_PRELOAD[edit]

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

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

Potential solutions:

  • Use environment scrubbing for everything in apparmor.d.

Setting up a fake sudo[edit]

An attacker can set up a fake sudo binary to trick the user into providing their password. Below is a simple example attack implementation demonstrating how this could be accomplished:

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 could theoretically be improved further, but that is beside the point being made here.

Even specifying the file path of the real sudo binary would not work:

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

Non-Solutions:

  • noexec: Mounting all user-writeable places such as /home and /tmp as non-executable is not a viable solution because an attacker can bypass these restrictions by using the bash interpreter, for example: bash /path/to/script. Would interpreter lockarchive.org help?

Potential solutions:

Device timing sidechannels[edit]

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_sidechannelsarchive.org

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 [5]

SUID SGID[edit]

Ideally, there should be no SUID binaries reachable from the user account, as otherwise significant extra attack surface inside the VM is exposed (dynamic linker, libc startup, portions of Linux kernel including ELF loader, etc.)comment on Qubes ticket Automate vm sudo authorization setuparchive.org by security researcher Solar Designerarchive.org

To address this issue, SUID Disabler and Permission Hardener has been created.

Kernel[edit]

The Linux kernel can have security issues. A kernel exploit that can be run from user space and does not require root can be used for LPE (local privilege escalation).

TODO: elaborate

Qubes Specific Issues[edit]

Qubes - /dev/xen libxenvchan issue[edit]

/dev/xen folder permissions are an issue inside Qubes. See Qubes bug report: harden insecure permissions inside /dev/xen folder / research security impact of the Qubes /dev/xen folder permissionsarchive.org and Root Privilege Isolation and libxenvchan.

Qubes - Automate vm sudo authorization setup versus SUID issue[edit]

Would Qubes feature request Automate vm sudo authorization setup #2695archive.org if implemented require sudo to retain the SUID bit (security-risk) by default and be world executable?

An implementation where sudo and other privilege escalation tools are not executable by default by "others" ("world"), primarily limited to user account "sysmaint", such as how Dev/user-sysmaint-split implements this, would be more secure.

Qubes - Strong Linux User Account Isolation - Motivation[edit]

Motivation of user/root isolation in Qubes? In the past, there have been Xen vulnerabilities that requires root access. (Actually a kernel module, but root has the permission to load kernel modules.)

All three vulnerabilities have the potential to enable a guest virtual machine to break out of the hypervisor isolation. However, in order to exploit this vulnerability, an attacker would need to be running code in kernel mode of one or more VMs on the system. Any system that allows untrusted users to run arbitrary kernels will be particularly vulnerable.Xen Project: Updates on XSA-213, XSA-214 and XSA-215archive.org

Qubes Security Bulletin #30archive.org

Passwords[edit]

Default Empty Password Security Impact[edit]

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

Rationale for Change from Default Password changeme to Empty Default Password[edit]

  • 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.
  • 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) impactarchive.org

Default Password Implementation Level[edit]

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.postinstarchive.org.

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:::

Related: Meanings of Special Characters in the Password Field of /etc/shadow File

Conclusions[edit]

  • In Kicksecure based Linux distributions:
    • On single-user systems (with a single human used account only):
    • 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 accounts (such as for example account 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 accounts. In effect, strong Linux 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 account user escalate to root if account user was compromised?
    • Protection against Physical Attacksarchive.org: This is a mostly unrelated issue. A screen lockarchive.org might be sufficient protection from lesser adversaries. In that case, a host screen locker and a better, non-default Linux account password on the host operating system might help, as the login password will also be used for the screen lock.

Analyze PAM Stack[edit]

Older versions: 

/usr/bin/sudo /usr/bin/apt update
Sorry, try again.
Sorry, try again.
sudo: 3 incorrect password attempts
Command exited. You may close this window safely.

New versions: 

[template  user ~]% sudo apt update      
Sorry, user user is not allowed to execute '/usr/bin/apt update' as root on localhost.
zsh: exit 1     sudo apt update
  • If you open /etc/pam.d/common-auth, you'll see the auth stack most things that use PAM (including sudo and su) use in Debian. Critically, sudo shares this stack with su.
  • pam_wheel checks the user calling it to determine if that user is in a specific group. If not, access is denied. This doesn't block lightdm login because lightdm runs as root, and root is (apparently) allowed to authenticate as anyone. However, if user user is not in the specified group (in our case sudo), access is denied, regardless of what user user is trying to do.
  • Our old PAM stack ran pam_wheel for any successful authentication, which meant that anything the user tries to use that requires authentication (sudo, pkexec, su) will fail due to failed authentication. This applies even if user user is passwordless, in which case one will see authentication automatically fail without any other user input. sudo attempts authentication three times, so you get three failure messages.
  • Adjusting PAM to only run pam_wheel when running su fixes the issue because now su is the only thing that will attempt to use pam_wheel. Anything else will ignore it, and so authentication will succeed. In the case of sudo, it will then check, see that user user is not part of group sudo, and return a clear error message rather than an authentication failure message.

Related Topics[edit]

Resources[edit]

User Freedom[edit]

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

See also[edit]

Footnotes[edit]

  1. ↑ Bob Coggeshall is mentioned on sudo historyarchive.org.
  2. ↑ On the flip-side, if the Prevent Malware from Sniffing the Root Password steps are followed, two secure passwords are required for the user user and user sysmaint accounts.
  3. ↑ Quotearchive.org Joanna Rutkowska, security researcher, founder and advisor (formerly architecture, security, and development) of Qubes OS:

    One application can sniff or inject keystrokes to another one, can take snapshots of the screen occupied by windows belonging to another one, etc.

  4. ↑ Note: Rewritten "user" with "account" for clarity. https://github.com/QubesOS/qubes-issues/issues/2695#issuecomment-521646366archive.org @Patrick

    Why “I” can do it but account “man” cannot? What makes “me” and account “man” different?

    On non-Qubes Debian I am always wondering if I can switch a virtual console using ctrl + alt + F1, why can account “man” not? And how’s that different in Qubes?

    @marmarek wrote:

    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 (lets forget about X11 breaking all this assumptions, as we are talking about non-X11 session), especially if it’s of a different account, 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.

    marmarekarchive.org

    (lets forget about X11 breaking all this assumptions

    @Patrick

    Indeed.

    While experimentingarchive.org with module loading disabling, I experienced that broken X can block switching to virtual consolearchive.org. Needless to say (for other readers), if X can do, also malware could do. “SysRq + r” can take away control from X. After that, switching to another virtual console was possible.

    @marmarek

    Yes, X (or other process with access to input device) can grab it for exclusive access, disabling Alt+Ctrl+F1 or similar combos. This still is independent of what is happening on other terminals. Especially, input devices grabbed in this mode are handled by X server (or other process that grabbed them). As long as X server doesn’t have access to other terminals, it still can’t influence them.

  5. ↑ https://github.com/anthraxx/linux-hardened/commit/72b66e85807fd92b0c8ee53df59492806a6234aaarchive.org
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!

Retrieved from "https://www.kicksecure.com/w/index.php?title=Dev/Strong_Linux_User_Account_Isolation&oldid=90881"