Re: Guix & signed archive export/import

Re: Guix & signed archive export/import

[Niels Möller]

ludo@gnu.org (Ludovic Courtès) writes:

> We're using SPKI-style signatures and ACLs in Guix now, to determine
> whether to authorize the import of an archive of binaries (I say
> "SPKI-style" because we don't use your libspki, just libgcrypt and a
> bunch of higher-level sexps taken from the SPKI RFCs and drafts.)

Cool!

> For instance, libspki represents RSA public keys in the same format as
> shown in the SPKI documents whereas libgcrypt does something slightly
> different;

Incompatibilities here are unfortunate. But it should be possible to
support several variants.

> libspki/lsh supports password-protected keys, with a specific sexp
> format, whereas libgcrypt doesn't.

About this format, one known problem (if it is a problem), is that the
entire key is encrypted. It would sometimes be better to have an
expression which includes the public key in the clear, together with an
encrypted private key. And I think this code is in lsh, not libspki.

> So now the daemon has a SPKI-style access-control list (ACL), which
> lists the public keys whose imports are allowed.  The ACL is stored in
> "canonical s-expression" format, via Libgcrypt, as envisioned by SPKI
> [0] and as implemented by lsh [1].

If the files are to be human editable, which I think makes some sense
for an ACL list, it might be better to use the advanced syntax. The way
I do that in lsh, I don't want a parser for the advanced syntax in lsh
or lshd. Instead, when reading the file, I spawn an sexp-conv process to
convert it to canonical form.

And ideally, you shouldn't need a large acl list, but a single entry
with the key belonging to the machine's owner or sysadm. The sysadm then
delegates authorization to one or more "distro" keys, which can delegate
further to the keys of each build machine. Each delegation is an spki
certificate.

> Namely, /etc/guix/acl looks like this:
[...]
>     (tag (guix import))))

Can you add any additional restrictions to that tag, saying that a
certain key may sign only a subset of packages? I have thought a little
about that, and I really don't know what's the best way is to specify a
subset. Some possibilities,

  * Authorization for a single package, say

      (tag (guix import (package emacs)))

    Here, there's no limit on what the package the signer calls "emacs"
    might contain, so that's not terribly useful.

  * Authorization of packages from a certain source, say

      (tag (guix import (from http://ftp.gnu.org)))

  * Authorization to install into a particular subtree of the local file
    system, say

      (tag (guix import (dir /usr/local/emacs/)))

The tricky thing here is to define the syntax and semantics of the tags
so that one can do useful delegations using the spki tag intersection
machinery.

And maybe making best use of delegations would require more fine-grained
operating system capabilities, so one could use restrictions in the spki
tag also to limit what the package can do once it is running. But it
might be reasonably easy for packages which contain some deamon which is
going to run as its own uid anyway; then spki authorization could map to
group membership of that uid.

> In addition to the actual signature, archive signatures embed the signed
> hash and the signer's public key, like this:
>
>   (signature 
>    (data 
>     (flags pkcs1)
>     (hash sha256 #2749F0EA9F26C6C7BE746A9CFF8FA4C2F2A02B000070DBA78429E9A11F87C6EB#))
>    (sig-val 
>     (rsa 
>      (s #477143FFA2DF163036599985425A331CAF4FF7FA22083A64BA08BEA0DB3BA95472A56B1EAF5E122716FACC81E8D72FEFF0985DDA162EB22FE5579B27D333B774C89425151198DA7A094E264F18755EEA1F278592555C531ADC9DE86C7BFFB4869C70150DD93D07BC032E830F9314CD7EE204DE3ED74DCBB96F63C7D0CDCCD72A#)))
>    (public-key 
>     (rsa 
>      (n #00C1F764069F54FFE93A126B02328903E984E4AE3AF6DF402B5B6B3907911B88C385F1BA76A002EC9DEA109A5228EF0E62EE31A06D1A5861CAB474F6C857AC66EB65A1905F25BBA1869579E73A3B7FED13AF5A1667326F88CDFC2FF24B03C14FD1384AA7E73CA89572880B606E3A974E15347963FC7B6378574936A47580DBCB45#)
>      (e #010001#))))

I don't quite remember, but is this expression standard spki or not?

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.

Re: Guix & signed archive export/import

[Ludovic Courtès]

Hi, Niels,

Thanks for the quick feedback!

nisse@lysator.liu.se (Niels Möller) skribis:

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

[...]

>> libspki/lsh supports password-protected keys, with a specific sexp
>> format, whereas libgcrypt doesn't.
>
> About this format, one known problem (if it is a problem), is that the
> entire key is encrypted. It would sometimes be better to have an
> expression which includes the public key in the clear, together with an
> encrypted private key. And I think this code is in lsh, not libspki.

OK.  I was just mentioning this example in passing; it’s not really
important for our purposes at this point.

>> So now the daemon has a SPKI-style access-control list (ACL), which
>> lists the public keys whose imports are allowed.  The ACL is stored in
>> "canonical s-expression" format, via Libgcrypt, as envisioned by SPKI
>> [0] and as implemented by lsh [1].
>
> If the files are to be human editable, which I think makes some sense
> for an ACL list, it might be better to use the advanced syntax. The way
> I do that in lsh, I don't want a parser for the advanced syntax in lsh
> or lshd. Instead, when reading the file, I spawn an sexp-conv process to
> convert it to canonical form.

OK.  Both the ACL and signatures are stored in advanced syntax here,
which Libgcrypt can parse and emit.  For the ACL it’s obviously more
convenient; for signatures, it’s just that I find it clearer, and the
few bytes that’d be saved using the canonical encoding are not worth it
IMO.

> And ideally, you shouldn't need a large acl list, but a single entry
> with the key belonging to the machine's owner or sysadm. The sysadm then
> delegates authorization to one or more "distro" keys, which can delegate
> further to the keys of each build machine. Each delegation is an spki
> certificate.

Sure, but again, all we have is a small subset of SPKI, and no
delegations.  So the idea was to do have an interface like
‘lsh-authorize’ to explicitly add an entry to the ACL.

>> Namely, /etc/guix/acl looks like this:
> [...]
>>     (tag (guix import))))
>
> Can you add any additional restrictions to that tag, saying that a
> certain key may sign only a subset of packages? I have thought a little
> about that, and I really don't know what's the best way is to specify a
> subset. Some possibilities,
>
>   * Authorization for a single package, say
>
>       (tag (guix import (package emacs)))
>
>     Here, there's no limit on what the package the signer calls "emacs"
>     might contain, so that's not terribly useful.
>
>   * Authorization of packages from a certain source, say
>
>       (tag (guix import (from http://ftp.gnu.org)))
>
>   * Authorization to install into a particular subtree of the local file
>     system, say
>
>       (tag (guix import (dir /usr/local/emacs/)))
>
> The tricky thing here is to define the syntax and semantics of the tags
> so that one can do useful delegations using the spki tag intersection
> machinery.

Currently I don’t see how such tags could be used, and they may be hard
to define.

In Guix, all package binaries are collected in the “store”, a big
directory with one sub-directory per package.  It is normally populated
either by building things locally, or by downloading “substitutes”
(pre-built binaries) from another machine, such as the hydra.gnu.org
build farm.

hydra.gnu.org will sign binaries it produces with its key, but these
binaries could also be distributed from other places.  For instance, in
the longer term we want to encourage use of a distributed store, or at
least to allow the use of a diverse set of HTTP servers that distribute
binaries.

The idea here is that, if you trust hydra.gnu.org or Niels’s machine to
distribute genuine binaries, then you add them to your ACL with the
(guix import) tag, which allows you to import substitutes from them.

> And maybe making best use of delegations would require more fine-grained
> operating system capabilities, so one could use restrictions in the spki
> tag also to limit what the package can do once it is running. But it
> might be reasonably easy for packages which contain some deamon which is
> going to run as its own uid anyway; then spki authorization could map to
> group membership of that uid.

This is going way beyond what’s discussed here though.  :-)

>> In addition to the actual signature, archive signatures embed the signed
>> hash and the signer's public key, like this:
>>
>>   (signature 
>>    (data 
>>     (flags pkcs1)
>>     (hash sha256 #2749F0EA9F26C6C7BE746A9CFF8FA4C2F2A02B000070DBA78429E9A11F87C6EB#))
>>    (sig-val 
>>     (rsa 
>>      (s #477143FFA2DF163036599985425A331CAF4FF7FA22083A64BA08BEA0DB3BA95472A56B1EAF5E122716FACC81E8D72FEFF0985DDA162EB22FE5579B27D333B774C89425151198DA7A094E264F18755EEA1F278592555C531ADC9DE86C7BFFB4869C70150DD93D07BC032E830F9314CD7EE204DE3ED74DCBB96F63C7D0CDCCD72A#)))
>>    (public-key 
>>     (rsa 
>>      (n #00C1F764069F54FFE93A126B02328903E984E4AE3AF6DF402B5B6B3907911B88C385F1BA76A002EC9DEA109A5228EF0E62EE31A06D1A5861CAB474F6C857AC66EB65A1905F25BBA1869579E73A3B7FED13AF5A1667326F88CDFC2FF24B03C14FD1384AA7E73CA89572880B606E3A974E15347963FC7B6378574936A47580DBCB45#)
>>      (e #010001#))))
>
> I don't quite remember, but is this expression standard spki or not?

Well, <http://www.ietf.org/rfc/rfc2693.txt> doesn’t say anything about
that; <http://theworld.com/~cme/spki.txt> has some examples, which are
slightly different, but it does not formally define the sexp format for
signatures.

The ‘data’ and ‘sig-val’ things seem to originate in Libgcrypt; the
‘public-key’ format is also from Libgcrypt, and slightly different from
what appears in the SPKI documents.

I think “we” (i.e., Werner and you ;-)) could discuss the
standardization of these 3 items, and then ‘signature’ should be easier.

WDYT?

Thanks,
Ludo’.

Re: Guix & signed archive export/import

[Niels Möller]

ludo@gnu.org (Ludovic Courtès) writes:

> Sure, but again, all we have is a small subset of SPKI, and no
> delegations.

I think spki gets really interesting once you have delegations. I intend
to add that to lsh, for both user and host keys. But it's been some years
without any progress on that front.

> Currently I don’t see how such tags could be used, and they may be hard
> to define.
> 
> In Guix, all package binaries are collected in the “store”, a big
> directory with one sub-directory per package.

Then, it would make some sense to have a tag syntax to restrict
authorization to a single package, and not allow installation of the
packege to touch anything outside of its corresponding directory.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.

Re: Guix & signed archive export/import

[Ludovic Courtès]

nisse@lysator.liu.se (Niels Möller) skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Sure, but again, all we have is a small subset of SPKI, and no
>> delegations.
>
> I think spki gets really interesting once you have delegations. I intend
> to add that to lsh, for both user and host keys. But it's been some years
> without any progress on that front.

Yeah...

>> Currently I don’t see how such tags could be used, and they may be hard
>> to define.
>> 
>> In Guix, all package binaries are collected in the “store”, a big
>> directory with one sub-directory per package.
>
> Then, it would make some sense to have a tag syntax to restrict
> authorization to a single package, and not allow installation of the
> packege to touch anything outside of its corresponding directory.

By construction, the build process of a package can only touch its own
directory:

  http://www.gnu.org/software/guix/manual/guix.html#Introduction

Thanks!

Ludo’.