Log in

No account? Create an account

Previous Entry Share Next Entry
runuser versus su

Many years ago, we noticed SELinux having problems with the su command.  Many confined domains were using su to switch user from root to some non privileged user.  But this would generate lots of bogus SELinux errors such as:

Domain X_t wants to getattr on the fingerprint device or look at the pid file of the Smart Card reader. 

su using the pam_stack was the cause of these errors.  Depending on which pam_modules you had in the /etc/pam.d/su configuration, certain access would be checked.  Services using su do not want/need these side effects of using the pam stack.  SELinux policy writers do not want to allow the access or add dontaudit rules all over the place.

In order to fix this, we built a new application called runuser.  runuser is actually built from the su.c source code.  You just define the RUNUSER constant when compiling su.c.  Basically runuser is just the su command with the pam stack removed as well as verifying the command is running as root, not setuid.

Whenever an service is running as root and wants to change UID using the shell it should use runuser.

When you are logged in to a shell as a user and want to become root, you should use su.  (Or better yet sudo)

  • 1
There was independent interest in adding such a tool to coreutils
Seems like we should just make runuser available in coreutils upstream

When you are logged in to a shell as a user and want to become root, you should use su. (Or better yet sudo)
I'm not seeing any advantage to using sudo. Indeed, the horrendous abuse of sudo perpetrated by Ubuntu (and Debian?) arguably makes the system less secure.

I am talking about using sudo to give limited privs to the admin account. For example only allow the admin to execute a script through sudo, or better yet, use SELinux confined administrators and sudo to control what a shell running with UID =0 can do.

  • 1