8

There are certain applications that I don't want people to be able to open unless they have root privileges, however I do not want to give the programs root privileges. So how can I make it so that only root can run certain applications, but so that the applications are not actually run as root (I don't want them to be for security reasons)? I am running Ubuntu GNOME 15.04, with GNOME Shell, and GNOME 3.16.

  • If narrowing down "users with root privileges" to "users in the sudo group" would work anyway than it would be pretty easy, otherwise I think it would be quite complicated – kos Aug 25 '15 at 14:26
  • @kos: It would have to be users with root privileges. –  Aug 25 '15 at 14:27
  • @kos: Complicated in what way? –  Aug 25 '15 at 14:31
  • Could you make a new group specifically for the users you would like to be able to run this application, add those users, and then change group permissions for the application? –  Aug 25 '15 at 14:32
  • @HeatherBrown: I would prefer not to create any other users or groups. –  Aug 25 '15 at 14:35
  • Because an updated comprehensive list of users with root privileges is kept only in /etc/sudoers, so allowing / not allowing users to run a certain program should be based on that list. Restricting the execution privileges to the sudo group would be pretty easy instead – kos Aug 25 '15 at 14:36
  • Basically the problem is there might be more users with root privileges than those in the sudo group. My understanding is that this may happen only in specific configurations, but if you want a comprehensive solution restricting to the sudo group is not enough – kos Aug 25 '15 at 14:46
  • Its a very good question..its hard to get it right as sudo is implemented at the start..otherwise geteuid() and getuid() could get us somewhere near.. – heemayl Aug 25 '15 at 14:50
  • sudo echo -n; [[ $? = 0 ]] && echo "RUN" ? First checks if allowed to run sudo (sudo group and root), then runs program echo "RUN" as normal user if it was allowed. – Charlie Aug 27 '15 at 21:37

2 Answers2

8

This answer is complementary to Heather's one (which will work).

First of all, take into account that in Unix (and Linux) if one is able to take root privileges, they can do anything. In the case of Heather answer, nothing will stop your user to just sudo /usr/bin/applicationcommand (with a bit of search for the real path or whatever). But I suppose this is ok with you.

In that case, why do not simply(1): 

sudo chgrp sudo /usr/bin/applicationcommand
sudo chmod 750 /usr/bin/applicationcommand

? If the users are able to use sudo, it means(2) they are in the sudo group; the above commands make the applicationcommand readable/executable only to members of the sudo group. When they run it, however, they will run it as their real user, as any other command.

However, the "classic" Unix solution is:

  1. create a group, call it privileged.
  2. sudo chgrp privileged /usr/bin/myapp and then sudo chmod 750 /usr/bin/myapp.
  3. add the user(s) (unprivileged!) that you want to be able to run the app to the group privileged

and now the user will run myapp as its user, without any need to have sudo privileges.

Notice that if you want the application to run as a different user, you can use the set-uid mechanism combined with the above techniques.

Footnotes:

(1): Notice that you can't do this if the application has a set-gid flag (it happens with some mailer, for example). Check it before changing the group of the binary.

(2): in most configurations. sudo can be fine-trimmed (see man sudoers) in zillions of way, so the effectiveness of this simple hack will vary depending on how much you have customized it.

Community
  • 1
Rmano
  • 31,947
  • 1
    This is what I was thinking about when writing in the comments under the question, but while any user in the sudo group has indeed root privileges (at least by default), not every user with root privileges is necessarily in the sudo group. So restricting the execution to users in the sudo group technically may cut out users. /etc/sudoer will give a better clue about which users have root privileges, but that would still exclude (for example) users authenticating via Polkit. – kos Aug 27 '15 at 06:06
  • 1
    I also think that checking for root privileges based on the user being or not being in the sudo group is good enough in most configurations, but maybe this should be pointed out? – kos Aug 27 '15 at 06:06
7

Try using setuid from package super. Do sudo apt-get install super, then create a shell script that can only be run as root. Have that shell script run only one command:

#!/bin/sh
setuid $ORIG_USER applicationcommand
exit 0

Then, set an alias for each of the users so that applicationcommand points to the shell script you created by adding into each of their .bashrc files:

alias applicationcommand="sh /path/to/shell/script"

Alternatively, or as well as creating an alias you can edit the .desktop file of the application you want to run, assuming that your applications has a .desktop file (if it's not an application that runs in the GUI, but rather the CLI it is likely not to have a .desktop file), so that the Exec= line has sh /path/to/shell/script after it, or the name of the alias if you decided to create that. You will find .desktop files in /usr/share/applications and ~/.local/share/applications.

  • 1
    setuid(2) is system call, not any standalone executable..to set the setuid bit you can use chmod ....also i don't get what setuid bit is doing here..please clarify.. – heemayl Aug 25 '15 at 15:06
  • setuid here is setting the uid for the command applicationcommand to the uid of the original user. My source is here –  Aug 25 '15 at 15:28
  • 1
    @heemayl setuid in this case is an executable provided by the package super. I'm guessing it setuid(2)'s and then forks or executes the command desired. – nanofarad Aug 26 '15 at 01:29