Should my package have its own user by default?

0

When I create a package that should run a daemon on the user's system (or on an embedded system), is it good security practice to create a user and/or group for that package at install time? I know that e.g. ssh, telnet, ftp, apache, ... do this on linux.

I'm wondering, what are the downsides of following this practice by default?

xtofl

Posted 2019-05-13T08:00:04.590

Reputation: 236

Answers

1

is it good security practice to create a user and/or group for that package at install time?

Yes, it is, and it's not just for security. Many daemons have wide range of functionality and that includes having its own user for administrative purposes - for example postgres.

I'm wondering, what are the downsides of following this practice by default?

If you do it correctly and securely there are no real downsides to that besides having one more user and group in the system, which doesn't really matter. However, if that user was being used for administrative access to the daemon, then in the case if somebody unauthorized were to gain access to the user it'd be a problem - however, this is the case for anything else, especially the root account, so it's not any different than that.

Should my package have its own user by default?

And as I said, it all depends on the daemon. If you believe there is a use for that user - for administrative access, management, or something else - then yes. Otherwise if you can't find any use for such an user - just don't make one, it's not neccessary.


How to do it correctly depends on the Linux distro you're using. If you're using Debian-based distros (with Debian apt package manager) I can provide you with the following:

The adduser program does the right thing if called with the --system option. It is thus usually only necessary to call

adduser --system $USERNAME

in your postinst to create the account with logins disabled, a primary group of nogroup and a home directory under /home. If you want other options, add them as you want to.

Quote is from AccountHandlingInMaintainerScripts @ Debian wiki. You can read it further for more in-depth information.

Fanatique

Posted 2019-05-13T08:00:04.590

Reputation: 3 475

Thanks! "if you can't find any use for such an user - just don't make one", as what user should the daemon run, then? Or do you imply creating both a run- and an admin- user? – xtofl – 2019-05-13T08:20:16.403

Almost all daemons run as the root user and that is perfectly normal, since setting up correct permissions and etc. for a daemon's own user is a very tricky part. If there is no need for an admin user don't create one, and just run the daemon from root. Note that most daemons despite having admin users, they still run as root. – Fanatique – 2019-05-13T08:22:26.190

Ok. That's surprising to me, but helpful! Is it so tricky that it trumps having resilient systems? – xtofl – 2019-05-13T11:28:22.303

Daemons having their own users doesn't improve resilience. Running as root is resilient enough, does not matter if the daemon has its own user - if somebody gains access to root, they gain access to everything on the system - all users, daemons, everything. Having your own user for a daemon would be useful mostly for sandboxing - if you want to have your daemon completely isolated from other applications, daemons, layers, and etc. and that is easily accomplished via newer versions systemd. – Fanatique – 2019-05-13T11:31:26.230

Sorry, "resilient" was the wrong word. "Secure", "robust", ... may be more appropriate.

Access to root is not the question here, compromised daemons are. If the daemonized process has root access, that's far worse than if it had user access, right? So can we conclude that "sandboxing" is what my question is about, and that yes, it is a good idea with little drawbacks? – xtofl – 2019-05-13T12:01:59.607

1

The daemonizing process includes chrooting into a private environment so you may not have access to other services/daemons and etc. But you're right - although it is insanely hard, it is possible for a daemon to gain access to the root environment and thus to other daemons. systemd's new sandboxing helps to prevent that and secures it a lot better. In my case - I wouldn't bother, since it is really hard for a daemon to gain that access you're afraid of. However, if you still want to do it - https://www.freedesktop.org/software/systemd/man/systemd.exec.html#Sandboxing

– Fanatique – 2019-05-13T12:06:33.327

@xtofl if you do decide to go with it - read the docs carefully and experiment with it, sandboxing isn't something easy to setup as well. And yes - it has little drawbacks if the daemon doesn't need to write to many different partitions or use network and etc. – Fanatique – 2019-05-13T12:07:50.743

I will add all of what we have written in my answer. After that I will move this discussion to chat, because it has become too long. Any mod reading this - sorry! – Fanatique – 2019-05-13T12:08:32.740

Let us continue this discussion in chat.

– xtofl – 2019-05-13T12:09:31.023