security projects thoughts

[Jeff Johnson]

On Apr 18, 2011, at 12:23 PM, Bayard Bell wrote:

> 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?
> 

If you can't protect your build system from arbitrary content submissions,
well you have a fairly serious problem that cannot be solved in the
already compromised build system.

The specific answer is this:
	Nothing prevents "arbitrary content" from receiving a non-repudiable
	signature. All the content to the build system is in fact "arbitrary".

The goal is origin authentication. If you can manage to submit what
you are calling "arbitrary" content, it will indeed receive a non-repudiable
signature.

You are best off controlling the submission channel, not muck-a-bout with
the non-repudiable signature, which guranatees no tampering after, not before,
the build occurs.

>>> 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. ;->
> 

What "credit cards" and "open sores" softeware have to do with each
other escapes me. You better believe that I don't put my credit
card numbers in RPM (even though you can find my phone number if you look carefully ;-)

>> 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).
> 

Does a non-repudiable signature scheme solve some of the issues in
your security proposal or not?

I am indeed interested in "forward" and "better", not yet another
discussion that starts
	What if ...
scenarios that quickly become unimplementable with finite resources.

73 de Jeff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4645 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20110418/3888ed85/attachment.bin>