Assume you can install something on a system because you have sudo rights to do so, but only have sudo rights for the installer. In that case it is fairly easy to create a package that installs a binary owned by root that has the setuid bit set during installation, and have that binary execute any command that you feed it, as root. This makes it insecure to allow limited sudo access for any given user to a package that can arbitrarily change change permissions. The other obvious (IMO) security hole is that a package can update the /etc/sudoers file and grant the user all kind of additional rights.

As far as I know apt-get nor yum have an option that you can set, or check how they are invoked, that causes what is installed in the normal, default, locations, but in a limited way (e.g. not overwriting already available files, or not setting setuid bits).

Did I miss something and does installation with such restrictions exists? Is it available in other installers? Or are there other known workarounds that would make such restrictions ineffective (and implementing them a waste of time)?

  • 1
    I take it that in your scenario the user can not only create a package, but also make it available in a repository trusted by the installer? – Stephen Kitt May 31 '15 at 12:39
  • @StephenKitt Yes, although it is also interesting to consider allowing only packages signed by already trusted signatures to be installed (and not being able to switch of that check). – Anthon May 31 '15 at 12:48

This is probably doable with an SELinux policy (and probably not doable without SELinux or other a security module that can confine root), but it's pointless.

As you note, a package could declare that it installs /etc/sudoers. Even if you make an ad hoc rule to somehow prevent that, the package could drop a file in /etc/sudoers.d. Or it could drop a file in /etc/profile.d, to be read the next time any user logs in. Or it could add a service that's started by root at boot time. The list goes on and on; it's unmanageable, and even if you caught the problematic cases, you'd have prevented so many packages from installing that you might as well not bother (for example, that facility wouldn't allow most security updates). Another thing the package could do is to install a program that you'd be tricked into using later (for example, if you forbid write access to /bin altogether, it could install /usr/local/bin/ls) and which injects a backdoor via your account the next time you invoke the program. To prevent a package installation from injecting a potential security hole, you need to either restrict the installation to trusted packages, or to make sure you never use the installed packages.

Basically, if you don't trust a user, then you can't let them install arbitrary packages on your system. Let them install software in their home directory if they need something that isn't in the distribution.

If you want to give an untrusted user the ability to install more packages (from a predefined list of sources that you approve as safe) or upgrade existing packages on the main system, that can be safe, but you need to take precautions, in particular to disable interaction during the installation. See Is it safe for my ssh user to be given passwordless sudo for `apt-get update` and `apt-get upgrade`? for some ideas about apt-get upgrade.

Under recent Linux versions (kernel ≥ 3.8), any user can start a user namespace in which they have user ID 0. This basically allows a user to install their own distribution in their own directory.


If a user can create any package and upload it to a repository trusted by the installer, I don't know of any way to protect the system in the way you're looking for (at least not with apt-get). Maintainer scripts in a package are run as root (whether on apt, yum or dnf type systems), so installing a package effectively gives the package's author root access to that system.

Perhaps with something like SELinux you could come up with a policy which would give users enough access to install packages in certain places but not do any damage (e.g. not touch /etc/sudoers, /sbin, /usr/sbin etc., and of course the package manager's configuration), but I doubt you could catch everything. (I don't know enough about SELinux to be sure.)

If you can control what goes into the repositories, then you're OK. If anyone can upload anything to the repository, requiring signatures isn't actually going to help you much, at least with apt-get: mismatched signatures only cause warnings and prompts, which can be overridden, and I don't think there's a way of configuring apt-get so it won't allow an override.

  • I had forgotten that the installer executes scripts (my RPM packaging days are from the time ReiserFS was not yet part of the kernel) and I had not thought about the fact that it is not necessarily the packaging program itself that sets the permission bits on the files extracted to disc. – Anthon May 31 '15 at 18:24

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.