* Re: Guix & signed archive export/import [not found] <87ppoflg1y.fsf@gnu.org> @ 2013-12-29 20:15 ` Niels Möller 2013-12-29 21:03 ` Ludovic Courtès 0 siblings, 1 reply; 4+ messages in thread From: Niels Möller @ 2013-12-29 20:15 UTC (permalink / raw) To: Ludovic Courtès; +Cc: Guix-devel 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Guix & signed archive export/import 2013-12-29 20:15 ` Guix & signed archive export/import Niels Möller @ 2013-12-29 21:03 ` Ludovic Courtès 2013-12-30 17:45 ` Niels Möller 0 siblings, 1 reply; 4+ messages in thread From: Ludovic Courtès @ 2013-12-29 21:03 UTC (permalink / raw) To: Niels Möller; +Cc: Guix-devel 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’. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Guix & signed archive export/import 2013-12-29 21:03 ` Ludovic Courtès @ 2013-12-30 17:45 ` Niels Möller 2013-12-30 21:48 ` Ludovic Courtès 0 siblings, 1 reply; 4+ messages in thread From: Niels Möller @ 2013-12-30 17:45 UTC (permalink / raw) To: Ludovic Courtès; +Cc: Guix-devel 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Guix & signed archive export/import 2013-12-30 17:45 ` Niels Möller @ 2013-12-30 21:48 ` Ludovic Courtès 0 siblings, 0 replies; 4+ messages in thread From: Ludovic Courtès @ 2013-12-30 21:48 UTC (permalink / raw) To: Niels Möller; +Cc: Guix-devel 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’. ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2013-12-30 21:48 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <87ppoflg1y.fsf@gnu.org> 2013-12-29 20:15 ` Guix & signed archive export/import Niels Möller 2013-12-29 21:03 ` Ludovic Courtès 2013-12-30 17:45 ` Niels Möller 2013-12-30 21:48 ` Ludovic Courtès
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/guix.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.