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.
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.
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.
*** Bug 6356 has been marked as a duplicate of this bug. ***
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.
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
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.
Created attachment 9700 [details] potential partial implementation This is a sample potential implementation that patches against 2.0.47-r10.
*** Bug 36650 has been marked as a duplicate of this bug. ***
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.)
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.
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?
This is mostly fixed now I'd say. Still no signatures, but no use to have a summary bug about it.