Bug 1272550 - RFE: Ability to automate signing
RFE: Ability to automate signing
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: sigul (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Patrick Uiterwijk
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-10-16 13:28 EDT by Dennis Gilmore
Modified: 2016-10-01 15:14 EDT (History)
5 users (show)

See Also:
Fixed In Version: sigul-0.201
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-10-01 15:14:34 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dennis Gilmore 2015-10-16 13:28:22 EDT
Description of problem:

In order to fully automate the atomic two week release we need to have a way to automate the signing of the checksums. We also have a desire to to sign rawhide rpms, repo metadata for all releases and updates, all of which require us to be able to sign without manual intervention, something that is not possible today.

The driver here is to fully automate the two week atomic release.
Comment 1 Miloslav Trmač 2015-10-17 01:19:44 EDT
What exactly is missing?

sigul has, from the very start, support for --batch which allows a client to supply a passphrase in a non-interactive fashion; in fact https://git.fedorahosted.org/cgit/releng/tree/scripts/sigulsign_unsigned.py is already using it.

Putting this into a cron job or something should just work.
Comment 2 Dennis Gilmore 2015-10-20 00:49:11 EDT
sigulsign_unsigned.py runs get-public-key first to setup some things that is specific to the key in use. so you have to manually sign even with --batch.  perhaps I just do not understand it correctly.

What I would like to see if some kind of authentication token that we can use with any key from a specific host only. the way things work in fedora infrastructure quite a few people have access to the ansible-private repo where the password will live.  I would like to see a much more secure way to lock things down and minimise the risk and ability to use the auth token.
Comment 3 Miloslav Trmač 2015-10-20 10:42:04 EDT
(In reply to Dennis Gilmore from comment #2)
> sigulsign_unsigned.py runs get-public-key first to setup some things that is
> specific to the key in use. so you have to manually sign even with --batch. 
> perhaps I just do not understand it correctly.

Well, --batch is more --noninteractive; it does not allow you to run two different actions with a single execution of the client; but it does allow sending the key passphrase noninteractively, so just run the client two or more times, each time with --batch and supplying the same passphrase.

And again, sigulsign_unsigned is _already doing this_.

If you get an interactive passphrase prompt from sigulsign_unsigned, it is from something like https://git.fedorahosted.org/cgit/releng/tree/scripts/sigulsign_unsigned.py#n340 , not a prompt from sigul.


> What I would like to see if some kind of authentication token that we can
> use with any key from a specific host only. the way things work in fedora
> infrastructure quite a few people have access to the ansible-private repo
> where the password will live.  I would like to see a much more secure way to
> lock things down and minimise the risk and ability to use the auth token.

(0. sigul is fundamentally designed so that knowledge of the password is both necessary and ~almost sufficient: anyone with a copy of the password and a disk image of the vault can extract the raw key; any other permission/group membership/access checks protect only sigul client connections using its protocol, not against direct access. So if the passphrases are widely available to Fedora contributors, especially contributors with any other kind of access to the vault (or ability to grant themselves access to the vault), I would strongly suggest reconsidering that design.)


1. What is the difference between a password and the token you want? Where would you be storing the token so that it is accessible to fewer people than the passphrase, and why can’t you store the password there?

2. As a special case of 1., for anything like this to work, you need to limit ability to execute anything on the autosigning host (both interactively or just by pushing scripts to it) just as much as the ability to read the ansible-private repo, otherwise an admin can exfiltrate the autosigning passphrase/token (or, well, just proxy requests and have the autosigning host sign something unwanted). Is it really the case that control of the autosigning host will be _more restricted_ than read access to ansible-private?


3. As things stand, it is impossible to give an user a token which is usable without knowing the passphrase; even the vault cannot use the key without the passphrase, so _something_ needs to supply a passphrase to the sigul client. Of course it is always possible to add one more level of indirection…

4, If the core of the request is the “from a specific host only” part, AFAICS that would work just as well without any token, just by implementing a key+IP address check in the bridge (not the vault, the vault doesn’t know).  But 2. still applies.


5. A possible alternative, if you can store local state on the autosigning host (not sure how relevant this would be to your setup): When installing the autosigning host, have a key admin for the relevant key run (sigul grant-key-access $autosigning_host_user) with a random passphrase, store the passphrase on the autosigning host, and _only_ there (i.e. not in any repo). This would require access to the key admin passphrase when reinstalling the host, but minor configuration changes on the autosigning host can be done without access to any sigul passphrases.  But 2. still applies (and the autosigning passphrase could be used to extract raw keys from a vault disk image just as well as the admin passphrase, if you are worried about this).


I guess tl;dr is that if you are worried about sharing the sigul passphrases with too many people, the only way to fix this is to stop doing that. A (key, IP address) ACL can be added to the vault, but would it really restrict the number of people you trust?
Comment 4 Nikos Mavrogiannopoulos 2015-10-27 04:46:51 EDT
(In reply to Miloslav Trmač from comment #3)

> > What I would like to see if some kind of authentication token that we can
> > use with any key from a specific host only. the way things work in fedora
> > infrastructure quite a few people have access to the ansible-private repo
> > where the password will live.  I would like to see a much more secure way to
> > lock things down and minimise the risk and ability to use the auth token.
> 
> (0. sigul is fundamentally designed so that knowledge of the password is
> both necessary and ~almost sufficient: anyone with a copy of the password
> and a disk image of the vault can extract the raw key; any other
> permission/group membership/access checks protect only sigul client
> connections using its protocol, not against direct access. So if the
> passphrases are widely available to Fedora contributors, especially
> contributors with any other kind of access to the vault (or ability to grant
> themselves access to the vault), I would strongly suggest reconsidering that
> design.)

I am still checking the issue, but my recommendation for the vault is to be treated as a security module and be as _simple_ as possible. That is only a single key for enabling it (possibly entered on boot), and logging in its code base. Anyone more it will make it unmanageable as a security module. Any authentication with tokens etc., should be done and audited externally to the vault.
Comment 5 Nikos Mavrogiannopoulos 2015-11-02 08:41:42 EST
Let me explain my understanding of the request here. The title is a bit misleading. My understanding is that we need to restrict access for signing to a particular host/computer. That we can currently do by involving hardware tokens, e.g., a yubikey, or a smart card, which will be used for client authentication. If the user has the associated key in the card, he will be granted access to sign. So signing can be restricted to a single PC by plugging the token to that PC.

Is that an accurate depiction of the RFE in this bug, and is the solution an acceptable one?
Comment 6 Till Maas 2015-11-28 03:11:57 EST
FYI: sigulsign_unsigned.py already supports using gpg-agent to cache a passphrase to make it possible to run unattended: https://pagure.io/releng/blob/master/f/scripts/sigulsign_unsigned.py#_351
Comment 7 Kevin Fenzi 2016-01-18 13:44:11 EST
I think an isolated hardware machine (much like what we have for the current vaults with no ssh access, limited users, etc) with a gpg-agent/etc on it is the only way forward here at this time. Any other thoughts Dennis?
Comment 8 Till Maas 2016-01-18 14:23:47 EST
(In reply to Kevin Fenzi from comment #7)
> I think an isolated hardware machine (much like what we have for the current
> vaults with no ssh access, limited users, etc) with a gpg-agent/etc on it is
> the only way forward here at this time. Any other thoughts Dennis?

this is more or less autosign01 (limited user access, but SSH access).
Comment 10 Fedora Admin XMLRPC Client 2016-08-09 10:55:16 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 11 Patrick Uiterwijk 2016-09-22 07:00:12 EDT
This has now been implemented as robosignatory, together with the passphrase binding in sigul server/client.

Note You need to log in before you can comment on or make changes to this bug.