Security questions around using Guix to package apps

Security questions around using Guix to package apps

[Divan Santana]

Hi All,

Firstly love the work the Guix community is going and hoping to start
using it more.

I don't know too much about Guix but we considering using it and
switching from the typical RPM/yum solution we have implemented in our
large corporation here.

* Our problem

So our team manages a few thousand Linux systems for customers.

We don't allow full root access for the customes/users of the systems.

Though the customers/users require to ship applications. They normally do this
with something like RPMs and a yum repository.

The problem with this is:
1. yum/rpm requires root to install/upgrade/remove packages.
2. One can ship certain files in an RPM install it via yum and gain full root.
3. One can therefore use the RPMs/yum to gain full root.

* Consider Guix as a solution

The question is if Guix could solve the above?

I know it doesn't require root so that solves problem 1.

Though I think 2 is still a problem. Is it?

* Getting to the actual question
Therefore can one ship files in a guix package and as nonroot install this
package. Then use the files the package provided as a nonroot user to gain root?

Or written another way, if guix is installed on a system and configured to point
to substitutes that the same nonroot user has access to submit and approve
packages in, can that nonroot user on the system gain root. Therefore would one
need to review the submitted packages to avoid the user gaining root.

** Some theoretical examples of doing this

1.
One example to do this would be to create a shell script with =sudo su -= (or
similar problematic) contents then byte compile it and ship that in the
application with setuid permission bit set on it?

If this was possible with Guix, putting =/gnu= on it's own FS with mount option
of =setuid=0= should solve this.

2.
Ship a sudo file and install it in =/etc/sudoers.d= though I'm not sure if
that's possible with Guix since it's kind of it it's own chroot. Unless it
supports post-scripts section and that gets executed as root (doubt it).

Hope the above makes sense.

Greetings from South Africa
--
Divan Santana

Re: Security questions around using Guix to package apps

[Leo Famulari]

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

Hello!

On Tue, Jun 27, 2017 at 11:19:24AM +0200, Divan Santana wrote:
> Though the customers/users require to ship applications. They normally do this
> with something like RPMs and a yum repository.
> 
> The problem with this is:
> 1. yum/rpm requires root to install/upgrade/remove packages.
> 2. One can ship certain files in an RPM install it via yum and gain full root.
> 3. One can therefore use the RPMs/yum to gain full root.

[...]

> * Getting to the actual question
> Therefore can one ship files in a guix package and as nonroot install this
> package. Then use the files the package provided as a nonroot user to gain root?
> 
> Or written another way, if guix is installed on a system and configured to point
> to substitutes that the same nonroot user has access to submit and approve
> packages in, can that nonroot user on the system gain root. Therefore would one
> need to review the submitted packages to avoid the user gaining root.
> 
> ** Some theoretical examples of doing this
> 
> 1.
> One example to do this would be to create a shell script with =sudo su -= (or
> similar problematic) contents then byte compile it and ship that in the
> application with setuid permission bit set on it?
> 
> If this was possible with Guix, putting =/gnu= on it's own FS with mount option
> of =setuid=0= should solve this.

There are two ways to deploy Guix: Guix on another distro, or GuixSD.

On GuixSD, only privileged users can create setuid binaries.

For Guix on another distro, nobody can create setuid binaries from
Guix packages, at least not without root privileges, and not without
some hacks. As far as I know, while using Guix on a foreign distro,
setuid programs are not supported at all.

See the manual section Setuid Programs for more information:

https://www.gnu.org/software/guix/manual/html_node/Setuid-Programs.html

> 2.
> Ship a sudo file and install it in =/etc/sudoers.d= though I'm not sure if
> that's possible with Guix since it's kind of it it's own chroot. Unless it
> supports post-scripts section and that gets executed as root (doubt it).

Guix packages don't touch the filesystem outside of /gnu/store and /tmp
(while building). And on GuixSD, only root can add users to the sudo
group. So, we don't need to worry about this scenario.

Of course, there may be bugs. But Guix has been designed to prevent
the sort of privilege escalation you describe.

Does that answer your questions? Does anyone else have anything to add?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Security questions around using Guix to package apps

[Divan Santana]

Leo Famulari <leo@famulari.name> writes:

> Hello!
>
> On Tue, Jun 27, 2017 at 11:19:24AM +0200, Divan Santana wrote:
>> Though the customers/users require to ship applications. They normally do this
>> with something like RPMs and a yum repository.
>>
>> The problem with this is:
>> 1. yum/rpm requires root to install/upgrade/remove packages.
>> 2. One can ship certain files in an RPM install it via yum and gain full root.
>> 3. One can therefore use the RPMs/yum to gain full root.
>
> [...]
>
>> * Getting to the actual question
>> Therefore can one ship files in a guix package and as nonroot install this
>> package. Then use the files the package provided as a nonroot user to gain root?
>>
>> Or written another way, if guix is installed on a system and configured to point
>> to substitutes that the same nonroot user has access to submit and approve
>> packages in, can that nonroot user on the system gain root. Therefore would one
>> need to review the submitted packages to avoid the user gaining root.
>>
>> ** Some theoretical examples of doing this
>>
>> 1.
>> One example to do this would be to create a shell script with =sudo su -= (or
>> similar problematic) contents then byte compile it and ship that in the
>> application with setuid permission bit set on it?
>>
>> If this was possible with Guix, putting =/gnu= on it's own FS with mount option
>> of =setuid=0= should solve this.
>
> There are two ways to deploy Guix: Guix on another distro, or GuixSD.
>
> On GuixSD, only privileged users can create setuid binaries.
>
> For Guix on another distro, nobody can create setuid binaries from
> Guix packages, at least not without root privileges, and not without
> some hacks. As far as I know, while using Guix on a foreign distro,
> setuid programs are not supported at all.
>
> See the manual section Setuid Programs for more information:
>
> https://www.gnu.org/software/guix/manual/html_node/Setuid-Programs.html

Thanks for this link and reply. This link helps specifically with the
setuid concern. I figured with guix this probably wouldn't be an issue.

>> 2.
>> Ship a sudo file and install it in =/etc/sudoers.d= though I'm not sure if
>> that's possible with Guix since it's kind of it it's own chroot. Unless it
>> supports post-scripts section and that gets executed as root (doubt it).
>
> Guix packages don't touch the filesystem outside of /gnu/store and /tmp
> (while building). And on GuixSD, only root can add users to the sudo
> group. So, we don't need to worry about this scenario.

Cool, thanks I thought as much.

> Of course, there may be bugs. But Guix has been designed to prevent
> the sort of privilege escalation you describe.

Cool.

> Does that answer your questions? Does anyone else have anything to add?

Yes, I think so. Though I guess in summary my question is simple.

If guix is installed on a system and configured to point to substitutes
that the same nonroot user has access to submit and approve packages in,
can that nonroot user on the system gain root. Therefore would one need
to review the submitted packages to avoid the user gaining root.

(This is talking about guix package manager on a foreign distro like
RedHat)

I'm guessing it's not possible. Though would be nice to have
feedback from those that are more familiar with it.

It sounds like guix is designed to not allow a nonroot user to gain root
no matter what (customer) package is available in the "repositories".

Thanks for the feedback!

Re: Security questions around using Guix to package apps

[Ludovic Courtès]

Hello Divan,

Divan Santana <divan@santanas.co.za> skribis:

> If guix is installed on a system and configured to point to substitutes
> that the same nonroot user has access to submit and approve packages in,
> can that nonroot user on the system gain root. Therefore would one need
> to review the submitted packages to avoid the user gaining root.
>
> (This is talking about guix package manager on a foreign distro like
> RedHat)
>
> I'm guessing it's not possible. Though would be nice to have
> feedback from those that are more familiar with it.

We owe this design to Eelco Dolstra et al. of Nix.  There’s a very good
analysis in this paper:

  https://nixos.org/~eelco/pubs/secsharing-ase2005-final.pdf

Hopefully it answers all your questions and more.  If not, come back
here.  :-)

Ludo’.

Re: Security questions around using Guix to package apps

[Divan Santana]

Ludovic Courtès <ludo@gnu.org> writes:

> Hello Divan,
>
> Divan Santana <divan@santanas.co.za> skribis:
>
>> If guix is installed on a system and configured to point to substitutes
>> that the same nonroot user has access to submit and approve packages in,
>> can that nonroot user on the system gain root. Therefore would one need
>> to review the submitted packages to avoid the user gaining root.
>>
>> (This is talking about guix package manager on a foreign distro like
>> RedHat)
>>
>> I'm guessing it's not possible. Though would be nice to have
>> feedback from those that are more familiar with it.
>
> We owe this design to Eelco Dolstra et al. of Nix.  There’s a very good
> analysis in this paper:
>
>   https://nixos.org/~eelco/pubs/secsharing-ase2005-final.pdf
>
> Hopefully it answers all your questions and more.  If not, come back
> here.  :-)

Thanks Ludo. :-)