21

A desktop running Ubuntu Linux 14.04 LTS seemed to go slower than usual. top showed that freshclam, the database-update utility for the Unix anti-virus program, was working the hardest.

freshclam --version shows the version is from yesterday:

ClamAV 0.100.3/25835/Sat Jun  6 14:51:26 2020

This program was running under the user clamav, rather than root or user.

  • Is it usual for a program to claim a dedicated user profile to run itself?
  • Is this actually a good sign, because it adds transparency to what happens anyhow?
  • Is this actually a bad sign, because such an ad-hoc user can intrude upon other "stuff"?
  • Can I retrieve a list of the programs installed in my computer claiming this right of working with a dedicated user name? Basically, can a user oversee such behaviours?

Any common-sense tips that apply to understanding these kinds of situations are appreciated.

jwodder
  • 166
  • 1
  • 6
XavierStuvw
  • 965
  • 2
  • 8
  • 15

5 Answers5

80

Clamav is a daemon. The Linux Standard Base Core Specification recommends that daemons run under individual User IDs. This way you have fine-grained access control for each daemon, and in case one of them is compromised, the attacker does not automatically have unlimited access to the system (as they would if the daemon ran as root, for example).

gardenapple
  • 3
  • 1
Moritz Schmitt
  • 799
  • 3
  • 11
  • 9
    Yes, many webservers and databases run under their own user as well. It's fairly common, even though it takes some getting used to. I've seen systems with 10-20 'users' active at the same time. – Mast Jun 08 '20 at 07:35
  • @Mast I would say it's more than just common, it's [good security practice](https://en.wikipedia.org/wiki/Principle_of_least_privilege). – JimmyJames Jun 10 '20 at 16:22
16

Any common-sense tips that apply to understanding these kinds of situation

Any application needs some account to run. Running every application with a root account can be dangerous. In case such application has a critical bug, e.g. it allows execution of other applications in the system, the success of possible attacks depends essentially on the permissions of such application.

If this application is running with a root account, than actually any actions it executes will be accepted and performed by the system. Means, an attack can be successful. But if the application is running with a some restricted account with less permissions, then many malicious actions will be impossible because the system will refuse to perform them.

Using a separate account allows to control the permissions needed to the particular application more precisely. You can give such account exactly the permissions that it needs and not more. Also, you can withdraw permissions from such accounts quickly or even delete it. Having a separate account allows the application to keep its data (config files, log files) protected from other users without requiring the root account.

This is the idea.

In the reality we should keep in mind following:

1) It can be that the granularity of permissions is too coarse grained and you have to give some more permissions than you would like to.

2) Maintaining a separate account for every application (process, service, daemon) requires efforts. That's why we estimate the risks and take into account efforts. If the risks are low, it makes sense to keep the efforts low and to maintain as little accounts as possible.

3) Many applications have a configurable user account they will be running with. It has name similar to the application name. It is up to you to keep it or to use some other user account for this application.

4) In regards to clamav: Having a separate account is not suspicious, it is normal.

mentallurg
  • 8,536
  • 4
  • 26
  • 41
  • 5
    Traditionally you needed root to listen on low ports, but in reasonably modern Linux -- even Ubuntu 14.04 Trusty -- you can use CAP_NET_BIND. – dave_thompson_085 Jun 07 '20 at 20:35
  • 1
    You can also run services that listen on low-numbered ports as non-root users, via the 'djb way'. See http://thedjbway.b0llix.net/daemontools/uidgid.html – mti2935 Jun 07 '20 at 21:11
  • 1
    @dave_thompson_085: This is *very* good point. I removed the part about ports. I don't want to start here a discussion about capabilities vs users and groups. – mentallurg Jun 07 '20 at 21:11
  • @mti2935: The goal of the example with ports was to show, that some goals can require root permissions, and running with root user a process gets actually much more than it was required. I have removed it. – mentallurg Jun 07 '20 at 21:15
6

Applications often run a script as root during installation. This script may use the root rights to create the limited user account that only has as much permissions as the program requires. It is a normal and good approach.

In case of doubt, use

   ps -e -f

to see the command line in completeness and verify where is the running binary located.

Programs with less extensive installation support require administrator to create these accounts and scripts for switching into them.

h22
  • 901
  • 6
  • 10
5

Is it usual for a program to claim a own user profile to run itself?

It is normal for programs that run in the background to run as their own users.

Is this actually a good sign, because it adds transparency to what happens anyhow?

It's good because it provides privilage seperation, if all the background programs ran as the same user then a compromise of one could more easily spread to the others, it also helps with monitoring.

Is this actually a bad sign, because such an ad-hoc user can intrude upon other stuff?

It's certainly sub-optimal that unix-like systems do not maintain a distinction in usernames between human users and system users, but it's an old design that is very hard to go back and fix :(. Debian does now recommend an underscore prefix for newly added system usernames, but there doesn't seem to be any desire to try and change the multitude of existing ones.

Can I retrieve a list of the programs installed in my computer claiming this right of working with an own user name? Basically, can a user oversee such behaviors?

As a general rule on Debian-like systems, system users can be distinguished by having user-ids in the range 0 to 999 while normal users will normally have user IDs in the range 1000 to 59999 (see https://www.debian.org/doc/debian-policy/ch-opersys.html for further details)

In terms of what programs actually use each user that can be harder to tell, sometimes you may find it in an init script, systemd service file, cron job etc but some services start is root and then drop down to their specific user after certain privileged initialization tasks (mostly binding to privileged TCP/UDP ports) are complete.

Peter Green
  • 4,918
  • 1
  • 21
  • 26
3

Is it usual for a program to claim a own user profile to run itself?

As mentioned in other answers, this isn't a regular program. It's a daemon. And, yes, it's perfectly normal for a daemon to have its own user.

Is this actually a good sign, because it adds transparency to what happens anyhow?
Is this actually a bad sign, because such an ad-hoc user can intrude upon other stuff?

It's neither good nor bad. It's simply a matter of convenience. On a Linux system, all processes must have some user. It's not possible to have a process without a user. So, which user? Not root, because you should never run anything as root unless you absolutely have to. You could just pick a user, but what happens if that user is deleted? It's much simpler for the installer/package manager/whatever to just create a user and use that.

Having said that, for some daemons (especially network-related ones), there is some security benefit. If someone is able to remotely compromise a network daemon, they'll (in theory) only have access to files that daemon was originally able to access, i.e. files belonging to that user.

Can I retrieve a list of the programs installed in my computer claiming this right of working with an own user name? Basically, can a user oversee such behaviors?

Switching users is a "right" of every process that's running as root. Since daemons are (typically) started by the system boot procedure, they (typically) start as root, so they're (typically) free to arbitrarily change their own user ids. Even after they drop root privilege (if they do so, there's nothing stopping them from continuing as root), they can retain the capability of changing their user id if they need to. So, no, there's no central information repository of which daemons will change their user id when they start, and which won't.

Though, there is a convention that user IDs less than 1000 are reserved for daemon users. So you could look through /etc/passwd for low-number user IDs.

HiddenWindshield
  • 270
  • 1
  • 4