security projects thoughts

[Daniel J. Luke]

On Apr 18, 2011, at 2:29 PM, Jeff Johnson wrote:
> 
> On Apr 18, 2011, at 2:16 PM, Daniel J. Luke wrote:
>> On Apr 18, 2011, at 2:01 PM, Jeff Johnson wrote:
>>> 
>>> Differentiating a 3rd party package that originated outside of
>>> The One True Build System needs either a trusted time stamp
>> 
>> how does a trusted time stamp tell you that the origin wasn't from the one true build system?
> 
> Because a trusted time stamp comes from a CA that is required
> to maintain a record in context of the time stamp.
> 
> You can of course set up RFC 3161 access through https with all the
> usual certification rituals. But the CA records where the request
> came from and is mostly unforgeable if correctly used.
> 
> And it just instn't that hard to set up a build system with RW access
> dolely from the build system, and RO access publically.

You keep bringing this up, but it's not what I'm asking about.

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.

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

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

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

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

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'

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

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

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