On Fri, 23 May 2014, Matthew Miller wrote: > More generally, it'd be nice to have security review of this plan: > https://lists.fedoraproject.org/pipermail/infrastructure/2014-May/014345.html The point of the plan seems to be to isolate signing keys from the rest of Copr backend and put them in a separate box--let us call it a "signing oracle"--presumably in order to protect those keys if the rest of backend were compromised, but it is not stated explicitly. It is a good idea in general but I am afraid there is a catch if the keys are used to sign code. The oracle may be able to protect the keys against theft but it is much less likely it would protect them against abuse. Let us assume an attacker who got to the point where he or she would able to steal the key if it stayed on the build system and were not stashed in the oracle. It seems to me such an attacker would probably be able to coax the oracle to sign an arbitrary package, most likely a package including a trojan horse. Even if the breach is discovered and further abuse of the oracle is prevented, the existing signed "trojanized" package or packages will not disappear. Is there a way to neutralize such packages that does not involve explicit replacement of signing keys on every system trusting the abused keys? I suspect the answer is negative and the impact of a key having been abused would not be much lower than the impact of a key having been stolen. Indeed, there are other benefits of stashing keys in a signing oracle. First, the keys do not leak when the confidentiality (but not integrity) if the main system is compromised, e.g. when a backup copy is made public by accident. (Of course, this assumes such blunders can be avoided when the oracle itself is being handled.) Second, one can keep a trusted record of all signing operations at the oracle. It would not protect keys against abuse but at least it could make it possible to determine--after the fact--whether a particular key has been abused. (This has been already mentioned by Nikos Mavrogiannopoulos.) obs-sign appears to record every operation but signed data are represented by their hash. I think it would be better if more detailed information about the data, perhaps a complete copy, were recorded. On the other hand, that would make it necessary to transfer a complete file from the client to the daemon. On the other hand, there are also risks because the oracle adds more points of failure. Namely, it must make a correct decision whether a certain signing operation is authorized or not. This seems to be a rather weak point of obs-sign because the daemon relies on identity sent (in plaintext!) by the client and the assumption that unprivileged user are not able to spoof the expected source IP and a low source port--a mechanism that should have gone extinct together with rsh & al. Not to mention that all code seems to be supposed to run as root. Setuid-root at the client to make things more... stimulating for adrenal glands. I think checks based on source IP & port should be supplemented (if not replaced) with an appropriate cryptographic mechanism, such as digital signatures. Moreover the client should be split into an ordinary non-setuid program doing all complicating things and sending requests via a unix socket to a trusted proxy that would do nothing but add (trusted) information about the client's identity and forward the request to the oracle. One final comment: The plan suggests to put all eggs into one basket. It goes as far as to call that "ideal (and most paranoid) setup" assuming the basket is sturdy enough. But we all know sturdiness of baskets is often overrated. I suggest to consider an alternative approach where private keys are split using some N out of M scheme among multiple parties with sufficient diversity to reduce the risk of N+ parties being compromised simultaneously. -- Pavel Kankovsky aka Peak "Que sais-je?" -- security mailing list security@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/security
