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?

1 Answer 1

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.

9
  • 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
    Commented May 13, 2019 at 8:20
  • 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
    Commented May 13, 2019 at 8:22
  • Ok. That's surprising to me, but helpful! Is it so tricky that it trumps having resilient systems?
    – xtofl
    Commented May 13, 2019 at 11:28
  • 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
    Commented May 13, 2019 at 11:31
  • 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 - freedesktop.org/software/systemd/man/…
    – Fanatique
    Commented May 13, 2019 at 12:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .