1

Well, I've done a lot of reading and documentation around possible exploitation of sudoers files and SUID programs, but don't have a deep enough knowledge to pick up the wisest possible solution for my problem.

We're currently developping a Qt-based tool on Ubuntu for upgrade/rollback management of our main application.
So as you might have guessed, the said tool is making extensive use of apt install/purge and dpkg commands, that happen to be executable only with root privileges, which the tool does not have, as it is meant to be executed only within the limited-privileges user's context.

To circumvent this limitation, the team has chosen the most straightforward solution : adding appropriate entries in the user's sudoers file for the aforementioned commands.
BUT, as far as I know, this opens up a dangerous vulnerability in the system, as an attacker who would gain only limited access to the machine might then remove important components of the underlying linux system (systemd for instance), thus making the system crash.

As I'm the only cybersecurity engineer in the team, I'm trying to find the safest and most recommended way to mitigate this flaw, but so far could think of only one alternative : turning the upgrade tool into a SUID program.
The thing is : SUID programs have a nefarious reputation when it comes to privilege escalation vulnerabilities they might expose on the target system (see here for a checklist of all the considerations to implement in order not to mess up everything when writing a SUID program).

The question is : is going through this painful process really worth it ?
Is there any other way we could safely use apt/dpkg commands without all the hassle of SUID implementation, and without making the upgrade tool run with superuser mode ?

Note: a lot of questions on stackexchange cover SUID related concerns, but none actually discusses the specific usecase we're dealing with.

programmersn
  • 33
  • 5

1 Answers1

1

In summary, you mention two possibilities:

  • adding sudoers entries for apt-get, dpkg, etc. – yes, this sounds dangerous
  • making your application setuid root – yes, this is a problem; even more so if there's a code path where it doesn't drop privileges very early during execution

There are at least two other options that I can think of:

Write a small setuid root wrapper around the dangerous commands

You can have a small wrapper application which validates how it is being called, only allows operating on a small number of predefined packages, etc. This doesn't remove the liability of having a setuid root application in the first place, but it does greatly limit the attack surface.

It doesn't even really have to be setuid root; it could also be allowed to be executed via sudo. (Though sudo or setuid root doesn't significantly change the attack surface.)

Use a custom dpkg root

This might be the easiest approach. dpkg accepts --root=<somepath>, which is an alias for specifying --instdir and --admindir. If those two directories are writable by the user, then they shouldn't need root access to work with packages within those hierarchies.

Since by default the tools will only look in the standard locations, your packages won't show up in a standard package listing, system upgrade, etc.; but your management application could presumably take care of that.

The only real downside of this is that it allows the user to mess with their own installation of the software. However, you could in principle use user account separation to reduce that attack surface.

Of these options, unless there's a good reason not to, myself, I would probably go with the custom dpkg root, especially since you already have an application that's going to handle most of the gory details.

user
  • 7,670
  • 2
  • 30
  • 54