1

On an board running Linux I see a daemon and an utility run under root when started. The SELinux is enforcing for this system.

Are there any potential threats of running as root, even if the SELinux policies are quite well written and stringent?

The daemon collects device diagnostics and sends diagnostics data over IP network to a remote server. The utility is used to tweak a configuration file, that tells the daemon what all types of diagnostics are required to be monitored, collected.

1

A process running as root has more extensive access to various system calls, which increases the attack surface area. Even if SELinux is correctly enforced, there will still be an increased risk of kernel exploitation. The reason for this is that many system calls have checks to ensure that the process is running as root (more specifically, the checks are usually for CAP_SYS_ADMIN). If the process lacks those permissions, it quickly returns EPERM or a similar error. If it has those permissions, then a bug in between the quick permission check and the much later LSM checks can allow a process to exploit the kernel and disable SELinux, or more.

A privileged process may be able to take actions which SELinux cannot restrict due to there being no appropriate LSM hooks, which mandatory access controls tend to rely on. These hooks are scattered throughout the kernel and, each time they are reached, check whether or not the LSM has restricted the action. For example, after DAC checks (standard Unix permissions), an LSM hook exists that checks whether or not accessing a given filesystem object is permitted. Because the kernel is so complex and has such an extensive relationship with userspace, it is not possible to restrict everything. For one example, the risky ioctl system call (a catch-all syscall against file descriptors which allows kernel drivers to register what is in effect their own system calls) is not restricted by SELinux. In order to provide more fine-grained restrictions, you would need to whitelist the individual syscalls and their arguments. This can be done using the seccomp syscall filter.

No matter how tight you think your SELinux policy is, there is always room for improvement. For example, do you restrict the process' resource limits? Root processes are able to override resource limits, which can have security implications (for example, it is possible to disable ASLR for newly executed processes if you are able to control the stack resource limits).

Overall, there are four main risks that I can think of when running a process as root:

  • As explained above, the increased attack surface area may be exploitable.

  • The lack of defense-in-depth will mean that a bug in SELinux could lead to exploitation.

  • SELinux is not able to hook every possible action a root process can take.

  • No matter how tight the policy is, it can always be improved (e.g. do you restrict rlimits?)

Unless it is prohibitively difficult to run the daemon as its own user, I would suggest you drop privileges appropriately as if you were using no access control system at all.

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.