[gentoo-dev] Non-root emerges
Chris L. Mason
I've checked the documentation and man pages and couldn't find what I
was looking for. If I've missed something, please point me in the
right direction.
I've been trying to figure out if it is possible to have all emerges
(especially the builds) to be done as a non-root user, and have the
process call sudo (or similar) only for the final merge. All
downloading, unpacking, compiling and installing to the fake target
should be doable without root permissions. So, you'd just need to be
in the portage group, and be configured in sudo.
This is similar to what is possible in OpenBSD, with a setting in
/etc/mk.conf. This allows regular users to build ports, or even the
whole system. Debian allows something similar using fakeroot, which
allows non-root users to build packages. Probably the OpenBSD
approach would work best for gentoo. A similar setting could be added
to make.conf to indicate how to gain root permissions (i.e. by calling
sudo, or something else.)
This is desirable both for security reasons and just to avoid
accidentally trashing the system because of a broken build script, for
example.
If this currently possible, and if not, what do people think? If
there's no major obections or issues, I'd be happy to open a bug.
Thanks,
Chris
--
gento...@gentoo.org mailing list
Ciaran McCreesh
wrote:
| I've been trying to figure out if it is possible to have all emerges
| (especially the builds) to be done as a non-root user, and have the
| process call sudo (or similar) only for the final merge. All
| downloading, unpacking, compiling and installing to the fake target
| should be doable without root permissions. So, you'd just need to be
| in the portage group, and be configured in sudo.
Well, there's FEATURES="userpriv"...
--
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail : ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm
Chris L. Mason
> On Thu, 30 Sep 2004 10:24:46 -0300 "Chris L. Mason" <clm...@gmail.com>
> wrote:
> | I've been trying to figure out if it is possible to have all emerges
> | (especially the builds) to be done as a non-root user, and have the
> | process call sudo (or similar) only for the final merge. All
> | downloading, unpacking, compiling and installing to the fake target
> | should be doable without root permissions. So, you'd just need to be
> | in the portage group, and be configured in sudo.
>
> Well, there's FEATURES="userpriv"...
Okay, just checked the man page for make.conf:
userpriv
Allow portage to drop root privledges and compile pack-
ages as portage:portage without a sandbox (unless user-
sandbox is also used).
That looks useful, however, I think it would be more secure to always
run *without* root permissions, then acquire them when needed (i.e.
*just* for the merge to root.) Also, that allows people to call
emerge as a regular user, without having to su to root.
Chris
(reposting to list, I need to get used to responding to mailing lists in gmail)
--
gento...@gentoo.org mailing list
Paul de Vrieze
> Okay, just checked the man page for make.conf:
>
> userpriv
> Allow portage to drop root privledges and compile
> pack- ages as portage:portage without a sandbox (unless user- sandbox
> is also used).
>
> That looks useful, however, I think it would be more secure to always
> run *without* root permissions, then acquire them when needed (i.e.
> *just* for the merge to root.) Also, that allows people to call
> emerge as a regular user, without having to su to root.
>
Well, the issue is that without being root the file permissions in the
install stage will not be correct. The only even more secure option
besides the sandbox would be some kind of chroot with an overlay
filesystem. That would though require a nonstandard kernel module and as
such raise all kinds of other problems.
Paul
--
Paul de Vrieze
Gentoo Developer
Mail: pau...@gentoo.org
Homepage: http://www.devrieze.net
Luke-Jr
> Well, the issue is that without being root the file permissions in the
> install stage will not be correct. The only even more secure option
> besides the sandbox would be some kind of chroot with an overlay
> filesystem. That would though require a nonstandard kernel module and as
> such raise all kinds of other problems.
effect as such a chroot. Then, libsandbox (or whatever it's called) could
simply use the module if available and fallback to the normal way if it's
not...
--
Luke-Jr
Developer, Utopios
http://utopios.org/
Stephen P. Becker
So in other words, breaking all installs that don't use kernel modules?
Steve
--
gento...@gentoo.org mailing list
Paul de Vrieze
> >
> > Simply implementing sandbox as a kernel module would have the same
> > security effect as such a chroot. Then, libsandbox (or whatever it's
> > called) could simply use the module if available and fallback to the
> > normal way if it's not...
>
> So in other words, breaking all installs that don't use kernel modules?
No, the idea is to fall back to the normal sandbox if the kernel one is not
available. The only disadvantage of this approach instead of a chroot with
overlay is that in such an environment DISTDIR would not be necessary
anymore. Removing DISTDIR in some setups is dangerous though as it means that
testing gets a lot more complicated and quality might degrade.
Simon Stelling
> No, the idea is to fall back to the normal sandbox if the kernel one is not
> available. The only disadvantage of this approach instead of a chroot with
> overlay is that in such an environment DISTDIR would not be necessary
> anymore. Removing DISTDIR in some setups is dangerous though as it means that
> testing gets a lot more complicated and quality might degrade.
Guys, it's not the idea of UNIX to install a software-package without
root-access. Why do you want to install something without beeing root?
blubb
Chris L. Mason
>
> Guys, it's not the idea of UNIX to install a software-package without
> root-access. Why do you want to install something without beeing root?
I'm not sure about some of the other posts, but that wasn't my
intention. I believe the standard (and secure) UNIX way has always
been to compile stuff yourself (i.e. in your home directory) and then
su to root for the "make install". Basically I was just looking for a
way to do that with emerge (i.e. calling "sudo" for the actual copy of
files into /). That's what OpenBSD does, and they tend to set the
example in secure practises.
This should be easily doable without any kernel modules or other such magic.
Stephen P. Becker
>>root-access. Why do you want to install something without beeing root?
>
>
> I'm not sure about some of the other posts, but that wasn't my
> intention. I believe the standard (and secure) UNIX way has always
> been to compile stuff yourself (i.e. in your home directory) and then
> su to root for the "make install". Basically I was just looking for a
> way to do that with emerge (i.e. calling "sudo" for the actual copy of
> files into /). That's what OpenBSD does, and they tend to set the
> example in secure practises.
>
> This should be easily doable without any kernel modules or other such magic.
Which is the point of userpriv and usersandbox, which is already
included in portage.
Chris L. Mason
>
> Which is the point of userpriv and usersandbox, which is already
> included in portage.
>
Yes, thanks, I'll be using that now. However, I still think it's more
secure to do everything as a regular user (including running all the
portage code!) and only elevating to root permissions for actual
merges. Otherwise you spend more time running things as root, even if
you drop for the builds, and it's possible for a bug to prevent the
privileges from being dropped. Anyway, just wanted to make that
point, obviously it's up to you guys to decide.
Stroller
On Sep 30, 2004, at 2:39 pm, Chris L. Mason wrote:
> userpriv
> Allow portage to drop root privledges and
> compile pack-
> ages as portage:portage without a sandbox (unless
> user-
> sandbox is also used).
>
> That looks useful, however, I think it would be more secure to always
> run *without* root permissions, then acquire them when needed (i.e.
> *just* for the merge to root.) Also, that allows people to call
> emerge as a regular user, without having to su to root.
This probably doesn't address all your concerns, but I usually run
emerge sudo as a regular user. I just `sudo emerge whatever` & it works
fine.
Stroller.
--
gento...@gentoo.org mailing list
Stephen P. Becker
> Yes, thanks, I'll be using that now. However, I still think it's more
> secure to do everything as a regular user (including running all the
> portage code!) and only elevating to root permissions for actual
> merges. Otherwise you spend more time running things as root, even if
> you drop for the builds, and it's possible for a bug to prevent the
> privileges from being dropped. Anyway, just wanted to make that
> point, obviously it's up to you guys to decide.
>
Really though, it only becomes insecure if the source code can't be
trusted. This has become a bit more complicated/worrisome lately since
it has been demonstrated that malicious source tarballs with the same
md5sum as as the originals could be used to attack a gentoo install. I
think steps are being taken to remove this possibility from affecting
portage, however.
Chris L. Mason
>
> Really though, it only becomes insecure if the source code can't be
> trusted. This has become a bit more complicated/worrisome lately since
> it has been demonstrated that malicious source tarballs with the same
> md5sum as as the originals could be used to attack a gentoo install. I
> think steps are being taken to remove this possibility from affecting
> portage, however.
>
Remember, it's not just security though. A bug in a script when run
as root could wipe out all or parts of a system.
Stephen P. Becker
> as root could wipe out all or parts of a system.
>
...which is the reason why we have sandbox. FEATURES="sandbox" causes
an emerge to terminate immediately with an access violation if it
attempts to touch system files before the build is complete.
I'm not saying you are wrong by the way, I'm just pointing out that
stuff like this has been thought of before, so portage has safety nets
accordingly.
Ned Ludd
And sandbox does such a good job.
cd /usr/lib/portage/bin/ && HOME=`perl -e 'print "A"x512'` && ./sandbox
========================== Gentoo linux path sandbox
===========================
Detection of the support files.
Verification of the required files.
Setting up the required environment variables.
sandbox: stack smashing attack in function setenv_sandbox_write()
Aborted
>
> Steve
>
>
>
> --
> gento...@gentoo.org mailing list
--
Ned Ludd <so...@gentoo.org>
Gentoo (hardened,security,infrastructure,embedded,toolchain) Developer
Christian Birchinger
Well i don't use modules on my servers and i sure wont start
using them only for portage.
Christian
--
gento...@gentoo.org mailing list
Paul de Vrieze
> On Thu, 2004-09-30 at 15:21, Stephen P. Becker wrote:
> > ...which is the reason why we have sandbox. FEATURES="sandbox"
> > causes an emerge to terminate immediately with an access violation if
> > it attempts to touch system files before the build is complete.
> >
> > I'm not saying you are wrong by the way, I'm just pointing out that
> > stuff like this has been thought of before, so portage has safety
> > nets accordingly.
Sandbox should never ever be regarded as a security measure. It isn't. It
is almost trivial to subvert the sandbox. The reason for it's
effectiveness is solely that it's purpose is to protect against
accidental installing outside of the destination directory and so
subverting the package management (in short protecting against bad
makefiles and ebuilds). It IS NOT SECURE.
Chris L. Mason
...
> is almost trivial to subvert the sandbox. The reason for it's
> effectiveness is solely that it's purpose is to protect against
> accidental installing outside of the destination directory and so
> subverting the package management (in short protecting against bad
> makefiles and ebuilds). It IS NOT SECURE.
>
So, if builds (and installs to temporary target) were done as a
regular user, wouldn't that obviate the need for a sandbox at all?
Also, this would make things a lot safer on macos (and presumably
BSD), where the sandbox does not work.
Alin Nastac
Strictly speaking, you may be more secure if you compile as a non-root
user but it doesn't fit its purpose which is make sure you don't put
files outside /var/tmp/portage/$P. As joe, you could write in /home/joe
and violate the restriction.
Besides, don't we trust gentoo dev? Or main site of a particular
package? If not, why the hell do we install their program(s) in the
first place?
Sandbox _is_ what portage need. Not security but a safe net in case
something is screwed up.
Ciaran McCreesh
wrote:
| So, if builds (and installs to temporary target) were done as a
| regular user, wouldn't that obviate the need for a sandbox at all?
| Also, this would make things a lot safer on macos (and presumably
| BSD), where the sandbox does not work.
Install to a temporary target still needs root privs...
Ned Ludd
The idea seemed simple enough to me so I wrote a real quick wrapper
script to see how hard it would be do it. few mins of hacking later..
Your right it's not so hard at all. Atleast from a wrapper script.
Here is what the end result gives us.
--- USER EBUILD_PHASE
>>> solar phase(clean)
>>> solar phase(setup)
>>> solar phase(unpack)
>>> solar phase(compile)
>>> solar phase(test)
>>> solar phase(install)
>>> solar phase(package)
--- call remaining phases with root privs
>>> root phase(setup)
>>> root phase(preinst)
>>> root phase(prerm)
>>> root phase(postrm)
>>> root phase(postinst)
I would not really consider this any more secure by any means. An
attacker can still take control of your system via other methods.
But as far as keeping ebuilds from major screwups like rm -rf ${TYPO}/*
this should do the trick.
http://dev.gentoo.org/~solar/portage_misc/emerge-wrapper
I've only tested with some fairly small packages. No idea how a kernel
module or whatever would be handled.
If you build an the idea please share your changes with me. I'm all for
handling as many phases as we can as non root. Assuming it does not lead
to us having to install some new suid bin todo it.
>
>
> Chris
>
> --
> gento...@gentoo.org mailing list
Chris L. Mason
..
Very cool. I especially like the comment after checking for uid == 0. :)
I'll test this out with a few packages.
Ed Grimm
> Hi all,
>
> I've checked the documentation and man pages and couldn't find what I
> was looking for. If I've missed something, please point me in the
> right direction.
>
> I've been trying to figure out if it is possible to have all emerges
> (especially the builds) to be done as a non-root user, and have the
> process call sudo (or similar) only for the final merge. All
> downloading, unpacking, compiling and installing to the fake target
> should be doable without root permissions. So, you'd just need to be
> in the portage group, and be configured in sudo.
>
...
>
> This is desirable both for security reasons and just to avoid
> accidentally trashing the system because of a broken build script, for
> example.
Illusion of security only. If someone competent wanted to attack your
system, they would not do it in the build script; they'd do it in the
resulting code. As such, this methodology only protects against broken
build scripts.
For those that don't understand the concept, which would you think a
cracker would more likely want: one time access to your system, or
access to your system forever, whenver they wanted?
We may find out about some malicious code updates through such
protections, but that's generally due to the cracker not knowing how to
code properly. The crackers who *do* know how to code will pass right
through your checks if you're depending upon such mechanisms to detect
them. (Admittedly, I've only heard of one decent cracker who dared Open
Source.) I would really prefer we find out about all the malicious
updates through code review and patch signature verification (this does,
of course, include the preference for finding out about all of them.).
Admittedly, build scripts tend to not get quite as much review as code
people realize is going to continue running on their systems, and I have
seen one or two packages that tried to install root kits in configure.
(They, incidentally, did not pass the signature verification check. But
I was curious.)
Ed
--
gento...@gentoo.org mailing list