1

So I want to create a special system management user that can only install, update and remove packages, but don't want to let them use the sudo command directly. Say for example on a Debian based system like Ubuntu or Linux Mint you can use the command apt to install, and you just enter your user password, which will temporarily elevate that user's permissions to install, remove and update packages, whereas doing apt-get requires sudo at the beginning, which is what I want to avoid a the user from using.

Case in example, your don't want them to use this;

$ sudo apt-get <flag> <package> ✗

but you want them to use this instead;

$ apt <flag> <package> ✔

I understand there's a specific way of granting permissions to certain command wheels, without granting full usage to the specified commands, but I'm not sure how to set it up for individual users case like this.

  • 3
    It’s worth pondering the fact that anyone allowed to install a package is effectively root anyway, regardless of any other restrictions. – Stephen Kitt Jan 15 '18 at 11:00
  • 2
    Is it the sudo command that you don’t like, or the password prompt? The later is easily fixed. – Jeff Schaller Jan 15 '18 at 11:35
  • @StephenKitt yes that's technically true, but you want them to directly use the sudo command, since you're only allowing temporary elevated permissions to install, update and remove packages. You don't want to allow them to use sudo for anything else. –  Jan 16 '18 at 22:51
  • @JeffSchaller It's not the sudo command that I don't like or the password prompt, its limiting what commands a user can execute, and how they can be executed, in the case of package updates you want to temporarily grant elevated privileges by using apt instead limiting to using only that command for updating, installing or removing packages. –  Jan 16 '18 at 22:53
  • @user94959 I’m not sure you understood my point. If you allow a user to install a package, you’re giving up control — they can do anything they want, as root (including reconfiguring sudo, but that’s the least of your worries by that stage). – Stephen Kitt Jan 16 '18 at 23:11
  • @StephenKitt You're assuming they have access to dpkg commands as well. –  Jan 18 '18 at 08:04
  • @user94959 no, I’m assuming they have access to apt and only apt. Give me apt on any Debian machine and I’ll get you a root shell pronto. (But then, if you’re running Debian or a derivative there’s a strong chance I’m effectively root on your system anyway.) – Stephen Kitt Jan 18 '18 at 08:08
  • I should qualify the previous comment — “give me apt able to install packages” etc. There aren’t any root-enabling vulnerabilities in apt as far as I know! – Stephen Kitt Jan 18 '18 at 22:29
  • @StephenKitt: Please don’t let this go to your head, but I’ll venture to guess that user91679’s system manager might not be as clever as you. There’s something to be said for the “locking the file cabinet” philosophy — most file cabinets have locks that are easily picked by anybody who has made even a casual study of the art — but if an average employee with idle curiosity gets into the office while the secretary is on a break, the fact that the cabinet is locked will probably stop them from taking a quick peek. … (Cont’d) – G-Man Says 'Reinstate Monica' Feb 08 '18 at 19:30
  • (Cont’d) …  Like the way it’s just about impossible to make a car or a home totally impregnable, but it’s easy to make it secure enough to deter criminals who aren’t highly determined to target you. – G-Man Says 'Reinstate Monica' Feb 08 '18 at 19:30
  • @G-Man point taken; I tend to view things from a “everything locked down by default” perspective, but a limited sudo is better than a wide-open sudo, that’s for sure. However I don’t like relying on people’s lack of cleverness — that tends to lead to complacency... Plus leaving this kind of access open means that compromising root is much easier, an attacker only needs to compromise a system manager. Comparing sudo to physical access is IMO somewhat misleading since the risk equation is completely different (an attacker is unlikely to be spotted in time). – Stephen Kitt Feb 09 '18 at 09:29

1 Answers1

2

You can modify your /etc/sudoers file using visudo and acheive this goal.

You can specify the allowed commands with sudo, you don't have to allow unlimited access, e.g.

username ALL = NOPASSWD : /usr/bin/apt-get , /usr/bin/aptitude

This would allow username to run sudo apt-get and sudo aptitude without any password but would not allow any other commands.

This is already answered in the following link: Allow non-admin users to install packages via apt or rpm?

Please note that the only commands a granted user would be able to run using sudo would be the one explicitly mentioned, like in the above scenario user can only use sudo for nothing but apt or aptitude.

Rajneesh Gadge
  • 83
  • Per my comment on the question, it seems the OP does not want sudo in the command-line at all. – Jeff Schaller Jan 15 '18 at 14:57
  • @JeffSchaller True, but OP also mentioned that he is not sure how sudoers for a specific user works, and I guess he can get away with the solution mentioned. And thanks for the +1. :) – Rajneesh Gadge Jan 15 '18 at 15:27
  • this is somewhat close to how I'd thought it be, but what I'm looking for here is that the user is only allowed to execute apt for updating and installing and removing packages, but can't use sudo apt-get to do it. –  Jan 16 '18 at 22:56
  • There is a tool named PolicyKit that also serves the desired purpose. I have not used it but i guess you can give that a try. https://wiki.debian.org/PolicyKit – Rajneesh Gadge Jan 20 '18 at 05:01
  • I hope this answer helped you! If yes, please mark the question status as answered. – Rajneesh Gadge Feb 19 '18 at 12:42