security projects thoughts

[Jeff Johnson]

On Apr 18, 2011, at 9:27 AM, Arno Hautala wrote:

> On Mon, Apr 18, 2011 at 08:27, Jeff Johnson <n3npq at mac.com> wrote:
>> 
>> You are assuming a threat vector reasoning that starts:
>>        0) assume sudo is "infected" maliciosly.
>>        ...
>>        42) anything is possible, including other ppkgs infected and distributed.
>> 
>> The answer there is not using an possibly infected sudo in the build system.
> 
> You may as well just say, "don't use a possibly compromised system",
> or in other words, "don't use a system".

Yes. That is in fact what I said, and what I meant to say.

> The example given isn't "assume sudo is infected", but "assume sudo
> could become infected. How can that be mitigated?"
> 

I fail to see the difference between the statements
	assume sudo is "infected" maliciously
and
	assume sudo could become infected
There are non-malicious infections, and the use of "could" adds
little additional meaning to "assume".
	
>>> I've not been over the MacPorts sources in a long time, I'm just realizing how easy it would have been for any of the hackers around me during my studies to completely own any of my Mac laptops back then. Them and the bloody sysadmins.
>> 
>> Presumably you already "own" ... "any of my Mac Laptops" ... by definition.
> 
> Ah, common mis-spelling. He meant "0wn".
> 

The word "0wn" isn't in the dictionary. Nor was the problem stated in
any fashion that might be analyzed.

> 
>> Its you trust decision: The corollary to your stated constraint "network operator should ... not be allowed to inject code"
>> is either
>>        TUrn off your netwwork.
>> or
>>        Don't use MacPorts.
> 
> Then why do we have things like SSL, GPG, and passwords in general?

There is no "why?" in security. Arguing backwards from the existence
of solutions to the problems that are solvable ignores other threats
and other solutions.

> They're there to enhance the security of an insecure channel and
> authenticate the client and server. Of course there are still ways to
> compromise the system (forge an SSL certificate, log a password,
> etc.). You can't protect against everything, but you can take steps to
> get better.
> 

And without a threat model, all you will have is the false security
provided by the existence of digital signatures and passwords.

>> Correct: MacPorts contains sudo which is built and installed *AS ROOT*
>> just like every other package.
> 
> So let's say you're for some reason using the MacPorts sudo instead of
> the system shipped version (maybe the system version is out of date
> and insecure). You're updating your ports at a cafe and someone spoofs
> the update for the sudo port. With signed portfiles and packages they
> can't [1]. With the current scheme, they can spoof the portfile and
> replace the package source and hash.
> 

Sure "Let's say ..." whatever. The answer is the same:
	If you are worried abt sudo in MacPorts as a threat vector, nuke it.
There's no loss of functionality using the system sudo.

> [1] Or at least they'd have to spoof the initial MacPorts
> installation, but at least signed packages and portfiles have shut
> down some exploit avenues.
> 

How has the existence (or not) of digital signatures "shut down some exploits"?
Which exploits? Name them please.

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