security concerns of using guix packages

security concerns of using guix packages

[Cook, Malcolm]

Hello Guixen (Guixers?  Guix-noscenti?)

The sys admin at my institute expresses concern that we would potentially expose ourselves to additional security risk by building scientific software stack in Guix where we might depend on alternate versions of, say, openssl.

Do you agree this is a reasonable concern, and, if so, is there a "position statement" on the matter?  

I'm guessing this is in part a matter of trust - i.e. do we trust GNU/guix gang as much as, say the Red Hat/CentOS gang.  Or am I perhaps misunderstanding the consideration?

I'd be interested in hearing any position on the matter.

Thanks for your consideration,

Malcolm Cook
Computational Biology
Stowers Institute for Medical Research

Re: security concerns of using guix packages

[John Darrington]

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

On Fri, Jul 03, 2015 at 12:38:49AM +0000, Cook, Malcolm wrote:
     Hello Guixen (Guixers?  Guix-noscenti?)
     
     The sys admin at my institute expresses concern that we would potentially expose ourselves to additional security risk by building scientific software stack in Guix where we might depend on alternate versions of, say, openssl.
     
     Do you agree this is a reasonable concern, and, if so, is there a "position statement" on the matter?  
     
     I'm guessing this is in part a matter of trust - i.e. do we trust GNU/guix gang as much as, say the Red Hat/CentOS gang.  Or am I perhaps misunderstanding the consideration?
     
     
When you install (say Redhat), like you say, you have to trust that Redhat 
hasn't (deliberately or maliciously) put malware into any of the MANY THOUSAND 
binaries that make up the OS.

When you install Guix, you have to trust that Guix hasn't put malware into any 
of the FIVE bootstrap binaries.  If you trust these five binaries, then you can 
do one of two things:

1.  Build everything else from source.  That way you know they are kosher,
    because you built it.  This can be done automatically, but takes rather
    a long time.

2.  Choose to trust the server at hydra.gnu.org, and have Guix download
    "substitutes".  This is a lot quicker, but you have to trust that
    the people who control that server haven't inserted malware. 



J'


     

-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


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

Re: security concerns of using guix packages

[Claes Wallin (韋嘉誠)]

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

On Jul 3, 2015 6:44 AM, "John Darrington" <john@darrington.wattle.id.au>
wrote:
> On Fri, Jul 03, 2015 at 12:38:49AM +0000, Cook, Malcolm wrote:

>>      The sys admin at my institute expresses concern that we would
potentially expose ourselves to additional security risk by building
scientific software stack in Guix where we might depend on alternate
versions of, say, openssl.

> When you install (say Redhat), like you say, you have to trust that Redhat
> hasn't (deliberately or maliciously) put malware into any of the MANY
THOUSAND
> binaries that make up the OS.

If I'm interpreting the OP's IT department correctly, this is not about
trusting guix or Red Hat regarding malice, not about binaries and
substitutions, but regarding competence and diligence, and the package
tree. If there are important patches coming out, will they get into
guix/Red Hat fast enough and will they get to users fast enough?

The IT department does have a point. First, Red Hat has a billion dollar
turnover  and hundreds of developers and integrators and a full-time
security team. Guix has a handful to a few dozen volunteers, depending on
how you count.

Second, users manage packages themselves, which could lead to a user
running on a two-year-old OpenSSL because they didn't do guix package -u.

On the other hand, vulnerabilities are the most serious when they are in
network-accessible services, which are probably run by the IT department
using commercial or commercial-derived packages.

I would kindly ask the sysadmin to chill. Or contribute to guix when CentOS
gets an OpenSSL security patch. ;-)

[-- Attachment #2: Type: text/html, Size: 1864 bytes --]

Re: security concerns of using guix packages

[Ludovic Courtès]

"Claes Wallin (韋嘉誠)" <clacke+gmail@lysator.liu.se> skribis:

> If I'm interpreting the OP's IT department correctly, this is not about
> trusting guix or Red Hat regarding malice, not about binaries and
> substitutions, but regarding competence and diligence, and the package
> tree. If there are important patches coming out, will they get into
> guix/Red Hat fast enough and will they get to users fast enough?

That’s a valid concern, and there’s not much we can say other than we’ve
been doing our best and will continue to do so.

That said, sysadmins don’t have to wait for upstream Guix to provide the
patch; in case of urgency, they could easily add the necessary patches
to, say,
<http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/openssl.scm#n29>,
upgrade their software, and share the patch with upstream Guix.

Of course that would be a last resort, and I hope users don’t run into
it.  But what it means is that users are more independent than with a
traditional distro.

Ludo’.

Re: security concerns of using guix packages

[Pjotr Prins]

On Fri, Jul 03, 2015 at 12:38:49AM +0000, Cook, Malcolm wrote:
> The sys admin at my institute expresses concern that we would
> potentially expose ourselves to additional security risk by building
> scientific software stack in Guix where we might depend on alternate
> versions of, say, openssl.
> 
> Do you agree this is a reasonable concern, and, if so, is there a
> "position statement" on the matter?  
> 
> I'm guessing this is in part a matter of trust - i.e. do we trust
> GNU/guix gang as much as, say the Red Hat/CentOS gang.  Or am I
> perhaps misunderstanding the consideration?

If openssl security is a concern, that would mostly be relevant for
packages that may have root privileges and/or run as an internet
service. When it comes to such exploits Red Hat and others do fix and
distribute them - which comes as public information. It is not in
their interest to hide fixes (even if they could). It is not the
nature of FOSS. That means GNU Guix will be one of the first to pick
fixes up as there are ample people running GNU Guix that are concerned
about their servers and GNU Guix packages can be updated quickly and
incrementally (Guix does not need special security repositories).

Note that most real world exploits are based on systems running older
software.

GNU Guix packages tend to be very up-to-date, though it depends on the
admin to keep track of that for a running system. I would be very
happy to run GNU Guix for critical services (such as ssh-server).

I could write a much longer E-mail, but I think what you should do is
avoid discussing particular privileged services and convince the
system administrator that all privileged services can still be Red
Hat/CentOS packages (so 'safe' in his book). All you are installing is
user land software in a nice and controlled environment.

That is no different from compiling packages by hand and installing
them in $HOME. To run the installed software as privileged you still
need to start them as root. Therefore GNU Guix installed packages can
do no more harm than self-built software.

A good system administrator should be able to grasp that. Maybe you
can have your system administrator speak with Ricardo's system
administrators. They allowed the cluster-wide network mount in an
academic setting. In science we have to be able to install our own
software on compute clusters. The current (and common)
build-it-yourself in $HOME route is laborious and error prone. 

The reason I am investing in GNU Guix is that I now have a packaging
system that allows me to leverage and share package management with
other scientists and it goes some way towards reproducible science. It
is a great step forward. The environments that 'get' this quickest
will do better than others at supporting science.

It is just a matter of time that our way of deploying software will
become the norm.

I hope that helps.

Pj.

Re: security concerns of using guix packages

[Ludovic Courtès]

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

Hi!

"Cook, Malcolm" <MEC@stowers.org> skribis:

> Hello Guixen (Guixers?  Guix-noscenti?)

Simply “Guix” (pronounced like “geeks”.)   :-)

> The sys admin at my institute expresses concern that we would potentially expose ourselves to additional security risk by building scientific software stack in Guix where we might depend on alternate versions of, say, openssl.
>
> Do you agree this is a reasonable concern, and, if so, is there a "position statement" on the matter?  

Guix provides guarantees that no traditional distro provides.

Guix users can choose to use substitutes (pre-built binaries.)  In that
case, they have to trust the binary provider:

  http://www.gnu.org/software/guix/manual/html_node/Substitutes.html

But the first big difference compared to Debian, Fedora, etc. is that
users can:

  1. Choose their binary provider–it doesn’t have to be hydra.gnu.org.

  2. Choose *not* to use binaries from a third-party, and instead build
     packages locally.

(By contrast, see the description of Debian’s “dirtiest secret” by the
former DPL in
<http://video.fosdem.org/2015/devroom-distributions/distributions_boring_solved_problem.mp4>,
at around 28 mn.)

In addition, the functional package management paradigm (see
<http://www.gnu.org/software/guix/manual/html_node/Introduction.html>)
allows users to know exactly how a package is built.  For instance,
anyone can trivially audit the recipe at
<http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/openssl.scm#n29>.
By construction, the result of ‘guix build openssl’ corresponds
precisely to the build process that this recipe and the ones it depends
on describe.


A concern could be the time it takes for the project to deploy security
fixes.  Obviously there are much fewer Guix contributors than Debian
contributors, but so far we do pretty well nevertheless (thanks to
Mark H Weaver for the most part.)

A related concern is the time it takes to actually deploy the fixed
binaries on your machine.  This is discussed at:

  http://www.gnu.org/software/guix/manual/html_node/Security-Updates.html


I hope this clarifies things!

Thanks,
Ludo’.

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

Re: security concerns of using guix packages

[Pjotr Prins]

On Sat, Jul 04, 2015 at 04:22:20PM +0200, Ludovic Courtès wrote:
> A concern could be the time it takes for the project to deploy security
> fixes.  Obviously there are much fewer Guix contributors than Debian
> contributors, but so far we do pretty well nevertheless (thanks to
> Mark H Weaver for the most part.)

I would like to add here that Guix compares to Nix in many ways (not
least they share the same daemon). Nix has been going much longer, it
has a large community, and it is interesting to note that many Nixers
are actually system administrators who choose to deploy their systems
with Nix packages.

It is not that that they chose to live dangerously ;). You could check
their track record for security fixes. You'll find that every major
fix went in quickly. Same for Guix with its short history.

Pj.

Re: security concerns of using guix packages

[Claes Wallin (韋嘉誠)]

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

On 04-Jul-2015 4:22 pm, "Ludovic Courtès" <ludo@gnu.org> wrote:

> A related concern is the time it takes to actually deploy the fixed
> binaries on your machine.  This is discussed at:
>
>   http://www.gnu.org/software/guix/manual/html_node/Security-Updates.html

Ok, this is great. Gives sysadmins a chance to affect packages users have
installed rather than having to help or force them to upgrade.

Still, if an installed package is not depending on the latest version of
the vulnerable package, the graft won't reach them. So there is still some
education and continuous information necessary if you want to be on top of
things.

Still, as was mentioned elsewhere in the conversation, if the alternative
is home-rolled software in every home directory, which is probably the
case, then guix is superior in several ways.

[-- Attachment #2: Type: text/html, Size: 1091 bytes --]

Re: security concerns of using guix packages

[John Darrington]

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

On Sat, Jul 04, 2015 at 09:51:22PM +0200, Claes Wallin (?????????) wrote:
     On 04-Jul-2015 4:22 pm, "Ludovic Court??s" <ludo@gnu.org> wrote:
     
     
     Still, if an installed package is not depending on the latest version of
     the vulnerable package, the graft won't reach them. So there is still some
     education and continuous information necessary if you want to be on top of
     things.

This is true.  However, one advantage of Guix is, that because of the rollback mechanism, 
if you suddenly hear that there was a gaping great security hole introduced into package foo
in version 1.2.3 and no fix is yet available, it is very easy to rollback to version 1.2.2


J'

-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


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