22

We always hear it is safe to run unknown programs as non-root users in Linux because non-root users are sandboxed from the system level and can't change anything out of their permission scope. If need be, as root user one can always delete a non-root user and be confident the rest of the system wasn't affected.

However, isn't it possible for a low-level user to install a script with a keylogger, for example, that waits for an su - or sudo call and takes system control from there?

  • 3
    Ideally, installing a keylogger wouldn't be possible as a non-root user. – JimmyJames Apr 29 '16 at 16:24
  • 10
    To be honest, on a single user system (like a personal computer) there isn't much point to getting root, as all the important data is already accessible from your user account. – André Borie Apr 29 '16 at 18:48
  • 23
    The obligatory XKCD – drewbenn Apr 29 '16 at 19:46
33

In short: yes, being on a low-privilege account helps protect you against malware, but does not make you immune. Like any security measure, no single thing is going to keep you 100% safe.

TL;DR: Running on a low-privilege account (aka "principle of least privilege") should be part of a balanced breakfast which also includes good firewall configurations; tools to monitor processes, system resources, open ports, network traffic, etc for suspicious activity; a policy to only run signed executables, configuration of the SELinux secure kernel mod, keeping the OS and application up to date with security patches, and other things.


Your question is very broad to answer directly. Instead I'll break it into several cases based on the configuration of the system, and what the attacker is after:

Case #1: Personal computer

Let's say the linux computer in question is my personal laptop. I effectively use this as a single-user system and I type sudo pretty regularly - so all of the things you mentioned apply. Moreover, if the attacker is trying to steal my personal information like credit card numbers, tax documents, etc, that's all sitting in my home directory where this user has access to it. If it's ransomware and wants to encrypt my personal files - same thing. They want to install a background process to make my computer part of a botnet, that doesn't need any special permissions.

Case #2: Server, admin account

The damage of getting malware onto an admin's account is less than the end-user case above since the admin account probably has no valuable data in it. but even so, an attacker can probably do some damage by having a packet sniffer inside the network, or by opening a port that allows the attacker to do pen testing from inside the network. Here you would rely on your firewall configuration to protect you against some of this and hopefully notify you to the suspicious activity so you can clean it up.

If the admin types sudo on a regular basis, then yeah, you're probably in trouble.

Case #3: Server, non-admin account

Imagine the use in question is tomcat - a very low-privilege user that runs the web server applications. This is the case people usually think of when talking about "principle of least privilege", and getting malware onto this account will be the least dangerous of the three case I've mentioned.

Also consider that Privilege Escalation exploits exist for linux that would allow a low-privilege user to bypass the OS security and turn themself into root. Generally speaking, keeping up to date with security patches protects you against this, but actors wealthy enough to purchase exploits on the black market will know about zero-day exploits that are not publicly known, and have not been patched.

  • 2
    Note: it is perfectly possible to have a separate user account for a somewhat untrusted install on your personal computer. It won't have access to your data, it won't be able to intercept your sudo. Plus it's easy to see if it has some background job running, as it will have a specific user id. – spectras Apr 30 '16 at 19:53
  • @spectras Sure, you could, but do you? Only installing untrusted software (which, realistically, is most software) on a dedicated low-privilege account would make a personal computer almost completely unusable. – Mike Ounsworth Apr 30 '16 at 20:21
  • 2
    I think it should be made more clear. It can be a lot, very, and incredibly dangerous to run things even on your own unprivileged user. Imagine having a thesis deleted by ransomware a day before due date... – NothingsImpossible May 1 '16 at 4:57
  • 1
    @MikeOunsworth actually, I chose to trust my distro's repository. Anything I really need and is not in it I have a separate user account for and I copy documents over to a shared area. Granted, if it happened often it would be an annoyance. – spectras May 1 '16 at 10:54
  • @spectras Kudos then, that's a good security practice. – Mike Ounsworth May 1 '16 at 13:18
58

We always hear...

Do we? I don't.

Installing some untrusted program as a normal user is a bad idea with Linux the same it is with Windows or Mac: this program has access to all your data and can delete these data, send these data to somebody else etc. Moreover it can make screenshots, control other applications running on the same X windows screen (even if they run as a different user), can grab keys (i.e. keylogger),... For details see The Linux Security Circus: On GUI isolation.

Apart from that we regularly have privilege escalation bugs even in Linux bugs which can be used by an unprivileged user to get root or even kernel level permissions.

Thus don't install any untrusted programs on any kind of system unless you are willing to compromise this system or the data stored on it.

  • 13
    Can confirm, as someone new to *nix systems, that I've heard that before. – Insane Apr 29 '16 at 19:07
  • 1
    On Linux, you have many users for many things and it is considered more secure and especially more usual to run apps as separate user. It's not secure to run something as a separate users, but it will stop many things like the average ransomware. – Sebb Apr 30 '16 at 19:51
  • To be fair, I would expect a program to be able to do whatever my normal user can, but I didn't know that an unprivileged program could sniff the input to sudo (is that still true today on modern distros?). That strikes me as a rather unexpected flaw, particularly considering that if I switch to the admin user under Windows the same can't happen since that's crossing a security boundary. – Voo Apr 30 '16 at 20:36
  • @Voo That's not right, you are blending together too many concepts and making some assumptions. To sniff the input to sudo, all you need to do is read from the keyboard. Many apps can read keyboard input even when they don't have focus - think about a music player or a game overlay. This is usually not considered an "administrative task". The difference with Windows is that you type your admin pass into a dedicated overlay, whereas a terminal window is not given any special sandboxing, even if you happen to type sudo into it. The linux command gksudo does the overlay thing that you like. – Mike Ounsworth May 1 '16 at 14:11
  • @Mike Yes I'm aware that many apps can read keyboard input and that Windows forces a separate security boundary to avoid that problem. I would've assumed that sudo had some way to do something similar. I mean if every untrusted program can read the sudo password anyhow, this strikes me as a perfect example of security through obscurity. I mean what's the purpose of sudo right now? Clearly not added security. – Voo May 1 '16 at 14:23
-5

isn't it possible for a low-level user to install a script with a keylogger, for example, that waits for an su - or sudo call and takes system control from there?

No - and you've already given the answer, because that is "out of their permission scope". Linux has always been a multi-user system and (nearly) everything which can be implemented outside of the kernel is implemented outside of the kernel and therefore subject to the constraints of the permissions system.

A user can install/run code which trashes their own data, but the only way any further harm can be done is by exploiting a vulnerability in the implementation.

Yes, if that user has 'su' or sudo access then its possible that malware could change the path to point to its own code instead of su/sudo and thereby MITM the interaction. but this is a bit more tricky to do in practice, since su or sudo would have to be invoked from process tree which already contains the running malware.

  • 3
    Unfortunately the security model of X11 makes key loggers possible even for non-privileged users. – Steffen Ullrich Apr 29 '16 at 14:40
  • @Steffen: are you still using MIT magic cookies? (OK this is also possible with XDM auth) – symcbean Apr 29 '16 at 14:45
  • @SteffenUllrich How would a keylogger be able to be installed as a regular user unless the "root/sudo" account was already comprimised? Looking at all X11 permissions (on my box), any modifications would have to be as root... Just trying to better understand how a keylogger as a non-root user is even possible – bluerojo Apr 29 '16 at 14:48
  • 8
    See The Linux Security Circus: On GUI isolation for details or simply play around as a non-privileged user with xinput or xev. You will see that it is easy to sniff any keys in X11. – Steffen Ullrich Apr 29 '16 at 14:55
  • 1
    @SteffenUllrich Thank you very much. Just started on the security aspects of systems and quite a bit of a learning curve (although fascinating). – bluerojo Apr 29 '16 at 15:03
5

The system itself is safe from accounts that aren't root-equivalent, but that doesn't help much on a desktop where most of what you care about is your own data, and you authenticate regularly to become root from your account.

If someone has an account on a correctly-configured multi-user system, and they don't have sudo privileges or the root password, then barring any bugs in privileged software, there's nothing that user can do that will give them control of the machine. A user account that may have installed malicious software should be considered a potential attacker by the rest of the system.

On my desktop, I added an unprivileged account that I can sudo to, but it can't sudo to root. I sometimes run software I trust a bit, but not entirely, under that account, esp. if it uses networking.

In theory, since I give that account access to my X server, it could escalate its privileges with clipboard / keystroke-simulation attacks. It's in the same Unix group as my regular account, and I'm sure I haven't fully removed group-write permission from some important files, but I did chmod 0644 ~/.bash{rc,_profile} and some other important files. So it's an extra hurdle that some malware might not have anticipated.

9

This is a horrible case of Security Theater

Security Theater is the practice or belief of something that looks like it improves security, but in reality does little/harm to it.

This false belief has been around as long as the following rumor

Linux has no viruses because of it's permission system

That's almost as good as saying

I don't have a virus on my computer because I don't see anything flashing

Just because you don't see it, doesn't mean it's true. Closing your eyes doesn't protect you from the intruder.

In all reality Linux, Mac OS, Windows, Android, Xbox, everything has vulnerabilities that would allow escalation to a system level of control.

HOWEVER just because the attack doesn't escalate itself to system level doesn't mean it isn't EXTREMELY dangerous. These applications with just user level access can still steal your information, record your every move, and hold your data for ransom! All without EVER being escalated because this is the data it has access to as just your user.

These facts are true of ANY OS regardless of the device. If you have access to the memory, it has access to the memory. That means even if you can't see it, it still has access to it.


The Good News

Because you are a regular user it means the attack isn't already at root level privileges, which means the access it has it limited to the users access, and helps protect other users on the system. Of course this doesn't mean that escalation can't happen, it just means it's much harder.

1

The recipe here, while not by any means foolproof, is incomplete or wrong.

Installing untrusted software under your unprivileged account is a disaster.

Installing it in a carefully prepared other unprivileged account? Less risky, but by no means guaranteed to be safe.

If:

  • you are sure that your system is set up as a secure multi-user system (no random bits of write access to system directories, probably full SE Linux)
  • You create an account that shares no groups with your account.
  • You have carefully set the access on all your data to be something like 0770 -- no access to 'other' --

then you are as secure as any environment that depends on multi-user security on a shared Linux system. However, those bullets represent quite a lot of work. Wouldn't it be easier to boot a CD or a VM?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.