Idea #11605: Another take on installing without root

-18

Written by tgape the 29 Jul 08 at 00:22. Category: System.
Related to: Synaptic package manager. Status: New

Description

This is an attempt to submit brainstorm 10644 as a workable idea, that will actually achieve the goals elie stated.

Modify the install process to use one of three privileged accounts, as follows:

1. Any package which needs to install something suid, or needs to touch /etc, /bin, /lib, or /var (excluding, of course, the actual package files) still requires root to install. (Simple heuristics: If it's not all going in /usr, it touches root so requires root. Only root can su without a password, so suid requires root.)

2. Any other package can either be installed using the 'bin' user or using the 'local' user. If it's installed using the 'bin' user, it is put into /usr, the way most packages are installed today.

3. If it's installed using the 'local' user, it's installed into /usr/local. (The only change from the current paths is that 'local' is inserted right after /usr; the structure otherwise is retained.) Any package installed using the 'local' user tracks which user installed it. Only that user or someone with either 'bin' or 'root' access can uninstall it.

With this setup, one could then use sudo(1) or a similar program to manage who can install programs, and at what level. Note that dpkg would need to some modifications. One possibility could be have it store the package database information with acls to allow both 'bin' and 'local' update it. (This could be simplified slightly by having 'bin' own the database.)

There would need to be some key constraints:

A. Only root could install files without entering a password to do so.

B. The 'bin' and 'local' users would need a shell that prevents general command execution. I'd recommend a custom shell which invoked aptitude, synaptic, or another package manager depending on environment and what is installed.

C. Something in the install process should verify each time that the various install directories are sufficiently restrictive (generally, permissions 755, owned by the right account.)

D. When 'root' performs updates, all updates would be available. Updating a /usr/local application must not move it to /usr, and must not forget who installed it initially.

E. When 'bin' performs updates, all 'bin' or 'local' updates would be available. Updating a /usr/local application must not move it to /usr, and must not forget who installed it initially.

F. When 'local' performs updates, only the updates for packages that particular user submitted would be available.

I feel certain I'm forgetting something.

Edit note: updated to remove requirement for suid dpkg. One thing I forgot was to include mention of controlling who can invoke dpkg, but the whole suid wasn't actually required, so removed.

Tags: installation package security systems

Attachments

No attachments.

Duplicates

[Report a duplicate and merge its votes to this idea]

Comments

droetker wrote on the 29 Jul 08 at 06:30

You should read some Linux books and things about security.
making dpkg SUID would be nonsense.

Please try to think in Linux, and don't try to make Linux more "windowsish".
Tere are some good reasons to make only root install software.

gmatht wrote on the 29 Jul 08 at 08:40

On the flip side there is good reason not to give everyone who needs to install software root access. Giving someone the right to install non-suid software from a trusted repo is much less dangerous that giving them root. It would in principle be possible to allow the user to relocate software into their home directory and thus allow them to install software without any extra privileges. In theory this would make it easier for them to shoot themselves in the foot, but again not really if they install from a trusted repo. So this would be both safer and easier than the old
wget ; configure --prefix=~ ; make ; make install.

There is a project to give the user real safety: even if the package in the repo is malware it won't be able to trash the users own file let alone other users. See:
http://plash.beasts.org/wiki/PackageSystem

vexorian wrote on the 29 Jul 08 at 12:44

Or, we could only allow root to install software, since that's the way things are supposed to be...

gmatht wrote on the 29 Jul 08 at 17:40

@vexorian
We already allow non-root users to install software via:
* wget ; configure --prefix=~ ; make ; make install.
* Third party binaries bundled in .sh or .run files.
etc.
I am not sure if I approve of this specific implementation, but we may as well look at ways we can make this easier and safer.

tgape wrote on the 1 Aug 08 at 13:02

Just for the record - I have *never* been a predominantly Windows user.

I realize, in the above idea, I failed to indicate that dpkg would be restricted to only being run by root, bin, and local. Only a restricted set of users would be able to run dpkg.

Malicious code could exist in an install script. If root ran such an install script, the system is compromised. If it were possible to run the install script via a less privileged user, it is likely that the install script would have insufficient access to fully compromise the system.

Install scripts rarely contain malicious code, for the following reasons:

1. Most project maintainers review any patches they include. Many package maintainers also do this. (Possibly most, although I've run into a few poorly run distributions.)

2. It's easier to slip something into tens of thousands of lines of code than it is to slip it in hundreds of lines of code.

3. The sorts of holes install scripts can open tend to be more easily detected. Stealth is still possible, but generally requires greater sophistication.

That having been said, it's still an opening. In some instances, it could even be a fairly attractive one:

A. The most security critical applications tend to get the most detailed security review. Applications with no security ramifications tend to get much less security review. All install scripts have equal access to compromise the system. As such, it could be easier to slip an install script exploit in a completely unsecured app than it is to slip an exploit in the body of a security app.

B. If the hole is a simple configuration weakening, systems without configuration monitoring could be compromised fairly stealthily. Even when the change is finally detected, there would be no indication of why it changed.

C. If the malicious code is spyware, it may just need to run once - in which case, inclusion into the install process is actually idea, because all the traces are removed when the install script is cleaned up by the package maintainer.

Post your comment