17

Is it possible to allow non-root users to install packages system-wide using apt or rpm?

The place where I work currently has an out of date setup on the linux boxes, and admins are sick of having to do all the installations for users on request, so they are thinking of giving full sudo rights to all users. This has obvious security disadvantages. So I'm wondering if there's a way to allow normal users to install software - and to upgrade and remove it?

naught101
  • 739

5 Answers5

24

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.

You can also use PackageKit combined with polkit for some finer level of control than sudo.

Allowing users to install/remove packages can be a risk.  They can pretty easily render a system nonfunctional just by uninstalling necessary software, like libc6, dpkg, rpm etc.  Installing arbitrary software from the defined archives may allow attackers to install outdated or exploitable software and gain root access.  The main question in my opinion is how much do you trust your employees?

Of course your admin team could also start using a configuration management system like puppet, chef or look into spacewalk to manage your system. This would allow them to configure and manage the system from a central system.

G-Man Says 'Reinstate Monica'
  • 22,870
Ulrich Dangel
  • 25,369
  • I left it out of my question, but do you have any comments on the security reduction implied by allowing this? I mean, you can't change the package repositories, so you're probably not going to get full sudo access, but you can write to any file using aptitude (options > preferences > "File to log actions into"), which could cause some serious damage. I'm less certain about PolicyKit... – naught101 May 29 '12 at 04:41
  • 1
    @naught101 ok i added some comments about security. JFTR as policykit won't provide root access it would be less problematic than using sudo – Ulrich Dangel May 29 '12 at 10:31
  • There are ways that you can run a shell from dpkg or rpm. For example: dpkg will prompt when there is a config file change which clashes, with one of the options being start a shell to examine the situation. This will start a shell as root if run via sudo. Likewise if you can run an editor from the tool, as most editors let you run arbitrary shell commands from within them (e.g. !command in vi). – David Gardner Sep 22 '16 at 13:01
  • @naught101 I would test for privilege escalation via a RPM that contains a SUID shell as this blog describes: https://nosedookie.blogspot.com/2011/07/leveraging-sudo-rpm-for-privilege.html In a shell injection scenario, however, where the sudoer account is compromised, one could mitigate privilege escalation via sudo by requiring a password to be entered, as opposed to NOPASSWD. – Matt Borja Oct 19 '16 at 16:07
  • 1
    I do not understand this answer. I provides a line that we are supposed to write ... where ??? – Vince Nov 16 '21 at 11:12
  • Perhaps worth mentioning where exactly to put this line. /etc/sudoers was where I put it. – Carlos Aug 13 '23 at 18:10
7

aptdcon

From the man pages:

aptdcon: allows to perform package management tasks, e.g. installing or removing software, using aptdaemon. There isn't any need to be root to run this program.

Mat
  • 52,586
pl1nk
  • 171
  • 1
    Although you do not need root/sudo privileges to run aptdcon, it immediately launches an authentication dialog for unprivileged users - I just tested on Ubuntu. If you are not a privileged/authorized user, then this does not add/remove packages. – sage Aug 31 '16 at 01:21
  • 1
    Doesn't work on operations ERROR: You are not allowed to perform this action. ('system-bus-name', {'name': ':1.716'}): org.debian.apt.install-or-remove-packages – JacopKane Jan 16 '19 at 21:51
  • I have tried adding [Install software] Identity=unix-group:admin;unix-group:sudo;unix-group:fic Action=org.debian.apt.install-or-remove-packages ResultActive=yes to /var/lib/polkit-1/localauthority/10-vendor.d/com.ubuntu.desktop.pkla but it does not work as expected – rapto Oct 20 '20 at 18:27
3
username ALL = NOPASSWD : /usr/bin/yum, /bin/rpm
Michael Mrozek
  • 93,103
  • 40
  • 240
  • 233
fromnaboo
  • 6,932
2

For me on the Debian 10 the option with visodo required additional steps:

  1. Add yourself to the sudousers:

Login as root via su -, open sudo editor by visudo and add next lines:

%yourusername% ALL=NOPASSWD: /usr/bin/apt-get install
%yourusername% ALL=NOPASSWD: /var/lib/dpkg/lock-frontend

  1. Exit session(root and yours) typing exit <Enter> exit <\Enter>

  2. Reopen it and type:

     sudo chown  %yourusername%: /var/lib/dpkg/lock-frontend
 chmod  u+w /var/lib/dpkg/lock-frontend 
 sudo chown  %yourusername%: /var/lib/dpkg/lock
 chmod  u+w /var/lib/dpkg/lock
 sudo chown  %yourusername%: /var/cache/apt/archives/lock
 chmod  u+w /var/cache/apt/archives/lock
 sudo chown  %yourusername%:  /var/lib/apt/lists/lock
 chmod  u+w  /var/lib/apt/lists/lock

PS: I also added the visudo file lines to allow myself to update repos list:

%yourusername% ALL=NOPASSWD: /usr/bin/apt-get update
Stadub Dima
  • 121
  • Why are you wrapping a variable in % signs? % means something in that file which adds a point of confusion. In step three, if you renamed it to $(whoami), it wouldn't have to be edited. That said, this did fix the problem for me, so I appreciate you posting it. – Daniel Kaplan Feb 02 '22 at 06:54
1

I also looked for something like that, but nothing showed up, so I coded this easy solution "softwarechannels":

https://github.com/alfem/softwarechannels

It is a very simple system to allow common (no admin) users to install packages from restricted catalogs.

Just define 'channels' (groups of packages) in a simple text file and give your users permissions to launch softwarechannels.

They will only see packages in channels matching their unix groups.

Alfonso E.M.
  • 11