Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 5902 - emerge security - running as root and digital signatures
Summary: emerge security - running as root and digital signatures
Status: RESOLVED FIXED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Unclassified (show other bugs)
Hardware: All Linux
: High critical (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
: 6356 36650 (view as bug list)
Depends on:
Blocks: 2765 8595
  Show dependency tree
 
Reported: 2002-08-02 08:20 UTC by Chris Bainbridge (RETIRED)
Modified: 2011-10-30 22:18 UTC (History)
19 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
potential partial implementation (signed-ebuilds.tgz,4.85 KB, application/tar)
2003-03-22 14:18 UTC, Robert Coie (RETIRED)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Bainbridge (RETIRED) gentoo-dev 2002-08-02 08:20:31 UTC
Running emerge as root is only necessary for the merge step. Unpacking, setup  
and compilation should be done as a normal user (say, "nobody"). Merging  
should never overwrite an existing file without user authorisation.  
  
At the moment there are a couple of ways to get root from portage:  
  
1) through a trojaned build process  
2) through a trojaned source that gets installed and executed by root  
  
Running the build process as a normal user avoids 1). Not overwriting existing  
files avoids 2), unless the user is installing some new root daemon/program,  
then they're screwed anyway.  
  
How difficult is it to compromise the md5 checksums? At the moment you need to 
either compromise the rsync/cvs server, or a developer with cvs write access. 
Using digital signatures would remove the first option here, so the only point 
of attack would be to compromise a developer. You could even use multiple 
signatures to sign off, so a release of a new ebuild depends on 2 or more 
developers. This would be significantly more difficult to compromise than the 
existing system.
Comment 1 Ole Tange 2002-08-24 06:44:21 UTC
Good idea. Though using 'nobody' is bad. Here is why: 
 
If all packages that need to run stuff as an unprivileged user uses the user 
nobody, then all these packages can compromise eachother. 
 
Example: 
 
Package A has a vulnerability that can make a remote user run stuff as the user 
which runs package A. 
 
Package B has a vulnerability that can make the user which runs package B root. 
 
If package A and package B uses the same user then you can gain remote root 
access. However, if package A and package B run as seperate users then you 
cannot gain remote root access. 
 
So: do not use 'nobody' for anything. Create a seperate, unprivileged user 
instead. 
 
Comment 2 Ole Tange 2002-08-24 06:48:14 UTC
Concerning overwriting files it would probably be awkward if an upgrade to a 
newer version could not overwrite older version. 
 
So IMHO it should only complain if overwriting files owned by another 
(unrelated) package. 
Comment 3 SpanKY gentoo-dev 2002-09-30 21:35:50 UTC
*** Bug 6356 has been marked as a duplicate of this bug. ***
Comment 4 Robert Coie (RETIRED) gentoo-dev 2002-10-07 01:48:24 UTC
Additionally, if the emerge sync step could be run as a normal user, say with
membership in a portage (or wheel) group as the only requirement, it would
become much easier to share /usr/portage over NFS without having to disable
root-squash.
Comment 5 Alexander Holler 2002-10-30 09:51:07 UTC
There is a much easier way to compromise gentoo users. 
 
Just change a init script in files/*.  
 
These files aren't checked at all and it is really easy to start a shell which 
listens on a port. An advanced hacker e.g. could change /sbin/runscript, which 
resides in baselayout/files/rc-scripts*, therefore it is unchecked too. 
 
So signing the ebuilds is really a matter of security. Right now, anyone who 
has access to one of the rsync mirrors could compromise a large number of 
gentoo users. 
 
Signing itself should'nt be that hard. 
 
E.g. to sign a complete (ebuild-)directory one could use: 
find -type f -print0 | xargs -0 gpg --print-md sha1 > signatures.txt 
gpg --output signatures.sig -ba signatures.txt 
 
Verifying could be done with testing the sig and comparing signatures.txt with 
a freshly generated signatures.txt (e.g. with a simply diff which shouldn't 
produce a difference). 
 
Regards, 
 
Alexander 
 
Comment 6 Nicholas Jones (RETIRED) gentoo-dev 2002-12-26 23:51:25 UTC
portage-2.0.47 will have support for drop-root compilation.
Two pre-releases are available, but I need to do a bit more
work on them before they can be public. Look for >=_pre3
before New Years.
Comment 7 Robert Coie (RETIRED) gentoo-dev 2003-03-22 14:18:30 UTC
Created attachment 9700 [details]
potential partial implementation

This is a sample potential implementation that patches against 2.0.47-r10.
Comment 8 SpanKY gentoo-dev 2003-12-28 10:28:16 UTC
*** Bug 36650 has been marked as a duplicate of this bug. ***
Comment 9 Ed Grimm 2004-11-11 23:17:52 UTC
Dropping root on compiling packages offers no protection - you have to have root privs to install the package (which I believe at least has the potential of executing code from the package), and you frequently need root privs to run the package.  The only safety net is to be able to trust the package in the first place.  That is, you need to have signatures on the packages, and maintainers that can be trusted.

If you want to have a package install more securely by dropping root privs, you need to create a unique user per package set (packages that interoperate in critical ways may need to share an id to interoperate), and the package must then be compiled, installed, and run as that user.  Without SELinux, I cannot see this system actually working; I have difficulty imaging it working *with* SELinux.

Bah.  I had a more secure system when I was running a DIY box that was mostly two years out of date - at least all the package signatures were checked, the updates were all signature checked and reviewed, the security holes were reviewed for applicability, and the packages were prioritized for upgrade if there was an issue.  Many of the packages had been code-reviewed before initial install.  (Yes, this was a minimal system.  Yes, this took a *LOT* of time; this is part of why my username is frustrated.)
Comment 10 Brad Allen 2004-11-12 20:20:59 UTC
Besides it actually offering protection, more important, install can and might be done chroot'd, and furthermore, most packages do not need to run as root.
Comment 11 Brian Harring (RETIRED) gentoo-dev 2005-02-27 21:44:49 UTC
Installation (non-merge, install phase) needs to install files as root on occasion... so, either you have to use fakeroot (supported in cvs head), or you just plain can't droppriv for that phase.

A more annoying aspect, is that until spanky's uid/gid glep is implemented, you *cannot* fully droppriv for all phases, due to the potential of user/group additions during setup phase.  So setup is still a vulnerability/target.

Spanky has a patch to handle phases from setup -> package; that patch, combined with the above reqs should allow portage to be non-root for all ebuild related steps, exempting merging.

For having sync as non-root, dunno.  I'd prefer it.
Right not, SYNC="cvs://" is a pita for most devs, do the fact cvs + root isn't friendly.  Thoughts/ideas/addendums?
Comment 12 Marius Mauch (RETIRED) gentoo-dev 2007-01-11 03:44:37 UTC
This is mostly fixed now I'd say. Still no signatures, but no use to have a summary bug about it.