12

I've developed an application that uses NTP to change the network time, to sync two of my computers. It runs as root, since only the latter is allowed to change the time and date on Linux(I guess).

Now, I want to run it as a user. But, I need to access the time.

  • Is it a good practice to run a daemon under a non-root user account?
  • Shall I give my application a capability such as CAP_SYS_TIME?
  • Does it not introduce a security vulnerability?
  • Is there a better way?
  • Normally the NTP daemon is supposed to run as the ntp user account (at least on Linux systems) so you shouldn't be required to make this change. What NTP package have you installed? – user86969 Jun 1 '15 at 8:26
  • 6
    Running a daemon under a non-root account is called "dropping root privileges" and is a commonly known good practice as it limits the potential damages of security vulnerabilities in the daemon. – user86969 Jun 1 '15 at 8:39
  • 1
    See wikipedia for "Privilege separation". – Kusalananda Jun 1 '15 at 9:01
  • I've compiled NTP from the sources. I don't have a NTP group – xhaltar Jun 1 '15 at 13:12
  • @xhaltar You can create the NTP group and user. To configure how a service is started (user, group, etc.) you can either create / edit the service init script, either create / configure a systemd unit. – Pl4nk Jun 1 '15 at 14:02
15

Is it a good practice to run a daemon under a non-root user account?

Yes, and this is common. For instance, Apache start as root and then forks new process as www-data (by default).
As said before, if your program is hacked (ex: code injection), the attacker will not gain a root access, but will be limited to the privileges you gave to this specific user.

Shall I give a "Capability" such as "CAP_SYS_TIME"?

It is a good idea since you avoid using setuid, and limit permissions to this very specific capability.

Shall I use another way to do so that would be considered "Good Practice"?

You can increase security, for instance:

  • Run the service as unprivileged user, with no shell.
  • Use chroot to lock the user in it's home directory.
  • NB: Chroot provides no security if you are root and running on Linux. The root user can create a directory in the chroot, open the root directory of the chroot, chroot to the new directory, chdir its way back up to the real root, and then chroot to the real root. BSD fixes this by disallowing taking directory fd's into a chroot. – Kevin Jun 1 '15 at 18:19
  • @Kevin If you're root, you can also ptrace processes outside the chroot, and there are many other ways to circumvent it. A mere chroot can't keep root in. – Gilles Jun 1 '15 at 22:07
  • // , emp.jar.st actually creates a user for itself for security reasons. Very good practice. – Nathan Basanese Jun 2 '15 at 0:07
  • Wait, if I'm USER, can I lock the USER into a specific directory ? Such as "/opt" (for instance) ? – xhaltar Jun 3 '15 at 7:29
  • @xhaltar To lock a process run by USER into a directory, you use chroot (run it as root user). However, you must create and initialize a jail (directory) before. In short, you must place the libraries and binaries your process needs into this jail, then call chroot <path/to/jail> <command>. A good tutorial with some the examples you need is available here – Pl4nk Jun 3 '15 at 12:53
13
  • Shall I use another way to do so that would be considered "Good Practice"?

Unless you have strong, irrefutable reasons otherwise, you should just use the NTP package that comes with your GNU/Linux distribution. The standard NTP daemon has taken years to mature and come with sophisticated features such as slowing or speeding up your system's clock to have it sync with a network or GPS clock. It's been tailored for sync'ing clocks so it most likely is the best tool around for that purpose.

ntpd is still maintained, judging by the recent updates (as of writing this post). If you need more features I'd suggest you contacted the developers directly, trust what they have to say about that.

5

If you have a program that needs to be able to do function X (e.g., manipulate the clock), and you can give it the privilege/power to do function X and nothing else, that is better than giving it the whole can of alphabet soup.  This is known as the principle of least privilege.  Consider, what if your program has a bug — either an ordinary programming error or an exploitable security vulnerability.  If it's running as "root", it could remove everybody's files — or send them out to an attacker.  If the only thing the program is able to do is manipulate the clock (and non-privileged functions, like manipulating files in a locked-down directory), then that's the worst that can happen if the program goes rogue.

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.