security projects thoughts

[Bayard Bell]

On 18 Apr 2011, at 16:26, Jeff Johnson wrote:

>> There's already been some references to having some kind of automated build service/sausage factory. Could you provide more info about how this is done with rpm at Red Hat?
> 
> Disclaimer:
> 	I haven't been associated with Red Hat since 2005.
> 
> Red Hat uses a nCipher to sign packages. Note the security exercise
> that Fedora experienced in August 2009 where (my guess) the plumbing
> needed to get to the "robo-signing" implemented in hardware (we all
> trust hardware, don't we? not.) was likely (I'm making savvy guesses)
> attacked to submit arbitrtay content to the "robo-signer".
> 
> One reason I chose to implement non-repudiable signatures directly
> in the builder, plumbing "stinks".

Sorry, there's a gap in explicitness here. What's done to prevent the robo-signer and/or build system from accepting arbitrary content? This isn't relying on a trusted network, presumably there's some idea of who's allowed to request a build and specify its content, even if the source is redistributed under the robo-signer's signature, no?

>> Is the source provided with build instructions as a source rpm that's then built and signed automatically to produce the distribution rpm?
> 
> All packages (including the SRPM) both include the pubkey and
> are signed with the private key. Which also measn (for the truly
> paranoid) that one can take all produced sausages from the build
> factory and verify that indeed they all carry the same pubkey
> and are all signed with that keypair.
> 
>> There's clearly a split in horizon between what the build system signs, but what checks does it do to decide what to build, package, and sign, meaning who does it trust "backward", if I might attempt to adopt your terminology at the risk of losing your meaning?
> 
> All depends on how the "security" question is asked. Expecting
> one single mechanism (like signing packages/executables or build elements)
> simply cannot answer every possible exploit. There are thousands of
> packages in MacPorts, not just sudo, and every one of those packages
> might have a security flaw.

I'm absolutely agreed on that. And you can move on to sandboxing (which is quite hard, given that applications admit of arbitrary definition, but I digress) and see that it still leaves us with plenty of residual risk, even if the cumulative reduction is quite material. Sandboxing, packaging, and port system are part of the trusted base which is necessary but not sufficient to application security. Issues that allow these systems to be compromised necessarily present significant risks to system integrity, which is generally taken as categorically more severe. On the other hand, users take limited respite in having their credit card number stolen but being reassured that they don't need to do a system rebuild. ;->

> That problem cannot be solved simply by signing packages/executables, nor
> should the discussions bring in irrelavant (imho) other threats like
> 
> 	Assume sudo could be compromised ...
> 
> A binary software distribution scheme should prevent tampering with
> the built packages on distribution channels, not get into "keyring management"
> or delegated trust or tampered sources or run-time exploits. These issues
> cannot and will not be solved by a build system (or by inference) a
> project like MacPorts.

I'm under no illusion that signatures disable all the evils bits, just aiming for a build and distribution system that doesn't allow new evil bits to be stirred in. The Debian OpenSSL incident is again instructive when you're doing redistribution: you can do just as much harm by stripping out code for what you think are portability reasons. Or to put it differently: upstream problems are generally best fixed upstream, rather than attempting to compensate downstream, where it mostly becomes finding a balance between harm reduction and yourself doing no harm (in reverse order of priority).

Cheers,
Bayard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1515 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20110418/56224072/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 841 bytes
Desc: This is a digitally signed message part
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20110418/56224072/attachment-0001.bin>