security projects thoughts

[Jeff Johnson]

On Apr 18, 2011, at 11:14 AM, Bayard Bell wrote:

> On 18 Apr 2011, at 15:55, Jeff Johnson wrote:
> 
>> Note no "key management" or "delegated trust" through signing by
>> developers or other "central authority" other than what the build system
>> chooses to use, thereby simplifying the needed deployment.
>> 
>> And its the "build system" not the upstream sources nor the "branding"
>> that is the appropriate place to "trust". The build system isn't
>> responsible for other factors such as tampered upstream sources or
>> anything that happens prior to the build starting. The added non-repudiable
>> signature secures the contents going "forward", not "backward", in time.
> 
> 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".



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

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.

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/b7dc9c39/attachment.bin>