security projects thoughts

[Jeff Johnson]

On Apr 18, 2011, at 2:40 PM, Daniel J. Luke wrote:

> 
> I'm asking about creepy uncle joe's skanky package build system that the local coffee shop network has been set up to make look like it's the product of the official build system.
> 

Creepy uncle joe's skanky build system is detectable with limited RW access
to an RFC 3161 (or any other means of getting a trusted time stamp that is
trackable). 

(IMHO) You are likely getting confused by the one-time keypair generation that
RPM is undertaking because no infrastucture exists, and other policies
like
	It's only "officially" signed when released.
are usually preventing RPM package signatures from
being deployed until there is a GUARANTEE that all
packages are signed always. The one-time generation
reduces the security ritual (for RPM) to
	Check if pubkey is in both SRPM and binary RPM(s).
because of lack of registrar infrastructure. I do suggest looking
seriously at one-time keypair generation because it mostly avoids the
need to protect the private key: the private key exists for only a short
period of time within a given execution context on TOTBS.

> ie, something outside of the build system that wants to look like it came from it.
> 

SO the security ritual would invllve one of two means (largely identical
because a "trusted" 3rd party is involved):
	verify that time stamp in signed package content is/was registered
	verify that pubkey in signed package content is/was registered
The increased trust comes from limiting RW access to to the trusted registrar
(which is quite simple to cruft up in the TOTBS with certs and firewalls etc).

>>>> (which has persistent trackable history) or a pubkey registry.
>>>> 
>>>> The issue hare so far hasn't been about 3rd party distributed build systems
>>>> and how origin authentication might apply to those other, non-existent,
>>>> systems. Heck The MacPorts "package build service" is so far
>>>> just a gleem in Jordan's eye ...
>>> 
>>> I thought that the problem this was supposed to fix was to prevent installation of rogue packages (but maybe I misunderstood)?
>> 
>> No origin authentication means it came from The One True Build System and
>> nothing more. If the TOTBS is delivering malicious packages, the non-repudiable
>> signature is useful forensics even if not useful for end-users.
> 
> rogue origin packages (not in general any package that may or may not be a good idea to install).
> 

The "rogue" is detectable by lack of registration.

>>>>> My question was, how does the client know it's talking to a legitimate keyserver when it's validating the public key from the package.
>>>> 
>>>> The usual means of securing pubkey retrieval for validation is to use a different
>>>> retrieval channel, with other means of securing the pubkey retrieval that is different
>>>> from the actual package signature.
>>> 
>>> Anyone who is going to the trouble to impersonate the package server (route mangling, DNS hijacking, whatever) can also redirect flows meant for pubkey validation. I don't see what the signature buys if it can't be reliably verified.
>> 
>> Noone I know, and certainly not me.
> 
> I thought the context here was that we can't trust the network to reliably send us to the official server that contains macports packages.
> 

You have a far broader context. If you want to solve that problem,
there's nothing I'm saying that stops you from solving whatever problem
you wish to solve.

> If we _can_ trust the network, what does the signing infrastructure provide? (We could just set up a system that contains only the products of the 'trusted origin' build system).
> 

You don't trust "the network", you trust https and the certificates involved
and the fact that forged certificates will be discovered and addressed
as soon as possible (an allusion to the recent rash of security releases
based on forged security certifactae, some of which risk is mitigated
by using one-time keypairs, your threat model may vary).

And no matter what:
	WHether sudo sources have been compromised simply doesn't
	matter to a "origin authentication" model. Yes its matters in
	general, but not to the distribution model.


> If we can't trust the network, we could possibly use crypto to at least refuse to install packages that don't verify correctly.
> 
> ... but if I'm maliciously going to the effort of pretending to be 'macports-packages.macports.org' or whatever, I can also go to the effort of pretending to be 'macports-package-pubkey-registration-server.macports.org'
> 

Go ahead, pick your favorite CA, register some content there, and then consider
hos difficult that exploit is.

If you're still of a paranoide/diseased fram of mind, run your
own CA, and limit RW access to that registrar, and then rethink
the degreee of difficuly "spoofing" anything.

>> All I'm trying to establish here is "origin authentication" (however that
>> is implemented) is a mostly solvable problem
> 
> yep, just trying to understand the implementation.
> 

Read the model, not the implementation. I'm discussing a mdel, not
an implementation, and claiming that binary packaging needs only
"origin authentication".

My motivation is largely to assist in getting SOME security infrastructure
deployed by recasting the issues into narrower questions that might
be solvable with finite resources.

MHO is closer to Jordan's, where signed hashes for build elements doesn't
really solve the real problems. Meanwhile its really easy to get lost in
	What if ...
scenarios discussing creepy-toe.

>> while discussions of whether
>> sudo is tampered with (or not) are different (and largely unsolvable) issues.
> 
> yeah, I know (and am not asking about it).
> 

Good. The topic has already moved from sudo. I'm sure y'all can figger
"origin authentication" all by yourselves.

That was/is my sole intent.

73 de Jeff
> --
> Daniel J. Luke                                                                   
> +========================================================+                        
> | *---------------- dluke at geeklair.net ----------------* |                          
> | *-------------- http://www.geeklair.net -------------* |                          
> +========================================================+                        
> |   Opinions expressed are mine and do not necessarily   |                          
> |          reflect the opinions of my employer.          |                          
> +========================================================+
> 
> 
> 

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