[gentoo-dev] Non-root emerges

[gentoo-dev] Non-root emerges

[Chris L. Mason]

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 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

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Non-root emerges

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 673 bytes --]

On Thu, 30 Sep 2004 10:24:46 -0300 "Chris L. Mason" <clmason@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"...

-- 
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Non-root emerges

[Chris L. Mason]

On Thu, 30 Sep 2004 14:28:12 +0100, Ciaran McCreesh <ciaranm@gentoo.org> wrote:
> On Thu, 30 Sep 2004 10:24:46 -0300 "Chris L. Mason" <clmason@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)

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Non-root emerges

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1020 bytes --]

On Thursday 30 September 2004 15:39, Chris L. Mason wrote:
> 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: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Non-root emerges

[Luke-Jr]

[-- Attachment #1: Type: text/plain, Size: 687 bytes --]

On Thursday 30 September 2004 2:04 pm, Paul de Vrieze wrote:
> 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.
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...
-- 
Luke-Jr
Developer, Utopios
http://utopios.org/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Non-root emerges

[Stephen P. Becker]

Luke-Jr wrote:
> On Thursday 30 September 2004 2:04 pm, Paul de Vrieze wrote:
> 
>>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.
> 
> 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?

Steve


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Non-root emerges

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 879 bytes --]

On Thursday 30 September 2004 18:38, Stephen P. Becker wrote:
> >
> > 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.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Non-root emerges

[Simon Stelling]

[-- Attachment #1: Type: text/plain, Size: 549 bytes --]

Paul de Vrieze wrote:

> 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Non-root emerges

[Chris L. Mason]

On Thu, 30 Sep 2004 19:50:13 +0200, Simon Stelling <blubb@gentoo.org> wrote:
> 
> 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.


Chris

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Non-root emerges

[Stephen P. Becker]

>>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.

Which is the point of userpriv and usersandbox, which is already 
included in portage.

Steve


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Non-root emerges

[Chris L. Mason]

On Thu, 30 Sep 2004 14:40:52 -0400, Stephen P. Becker <geoman@gentoo.org> wrote:
> 
> 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.


Chris

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Non-root emerges

[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.

Steve




--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Non-root emerges

[Chris L. Mason]

On Thu, 30 Sep 2004 15:04:44 -0400, Stephen P. Becker <geoman@gentoo.org> wrote:
> 
> 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.


Chris

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Non-root emerges

[Stephen P. Becker]

  > 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.
> 

...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.

Steve



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Non-root emerges

[Ned Ludd]

[-- Attachment #1: Type: text/plain, Size: 1138 bytes --]

On Thu, 2004-09-30 at 15:21, Stephen P. Becker wrote:
>   > 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.
> > 
> 
> ...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.

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
> 
> 
> 
> --
> gentoo-dev@gentoo.org mailing list
-- 
Ned Ludd <solar@gentoo.org>
Gentoo (hardened,security,infrastructure,embedded,toolchain) Developer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Non-root emerges

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 993 bytes --]

On Thursday 30 September 2004 21:55, Ned Ludd wrote:
> 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.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Non-root emerges

[Chris L. Mason]

On Fri, 1 Oct 2004 11:30:42 +0200, Paul de Vrieze <pauldv@gentoo.org> wrote:
... 
> 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.
> 

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.

Thanks,


Chris

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Non-root emerges

[Alin Nastac]

[-- Attachment #1: Type: text/plain, Size: 1251 bytes --]

Chris L. Mason wrote:

>On Fri, 1 Oct 2004 11:30:42 +0200, Paul de Vrieze <pauldv@gentoo.org> wrote:
>... 
>  
>
>>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.
>>
>>    
>>
>
>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.
>
>  
>
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.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: [gentoo-dev] Non-root emerges

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 538 bytes --]

On Fri, 1 Oct 2004 13:01:26 -0300 "Chris L. Mason" <clmason@gmail.com>
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...

-- 
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Non-root emerges

[Ned Ludd]

[-- Attachment #1: Type: text/plain, Size: 2236 bytes --]

On Thu, 2004-09-30 at 14:39, Chris L. Mason wrote:
> On Thu, 30 Sep 2004 19:50:13 +0200, Simon Stelling <blubb@gentoo.org> wrote:
> > 
> > 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.

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
> 
> --
> gentoo-dev@gentoo.org mailing list
-- 
Ned Ludd <solar@gentoo.org>
Gentoo (hardened,security,infrastructure,embedded,toolchain) Developer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Non-root emerges

[Chris L. Mason]

On Fri, 01 Oct 2004 17:41:45 -0400, Ned Ludd <solar@gentoo.org> wrote:
..
> 
> 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.
> 

Very cool.  I especially like the comment after checking for uid == 0.  :)

I'll test this out with a few packages.


Chris

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Non-root emerges

[Christian Birchinger]

On Thu, Sep 30, 2004 at 04:20:32PM +0000, Luke-Jr wrote:
> On Thursday 30 September 2004 2:04 pm, Paul de Vrieze wrote:
> > 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.
> 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...

Well i don't use modules on my servers and i sure wont start
using them only for portage.

Christian

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Non-root emerges

[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.


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Non-root emerges

[Ed Grimm]

On Thu, 30 Sep 2004, Chris L. Mason wrote:

> 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

--
gentoo-dev@gentoo.org mailing list