guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Guix & signed archive export/import


From: Niels Möller
Subject: Re: Guix & signed archive export/import
Date: Sun, 29 Dec 2013 21:15:16 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (usg-unix-v)

address@hidden (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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]