security projects thoughts

[Thomas de Grivel]

On 04/18/11 15:55, Jeff Johnson wrote:
>
> 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.

"Remote execution of arbitrary code" ? I picked sudo as an example but 
without signing it is also possible to replace any package to run any 
code and install it in the system as setuid if the Makefile says so. 
sudo is just more discreet as it already is setuid.

Unless you ensure some trust with the sources, for example by signing 
them with public crypto, you are fetching, compiling, and using code 
from a source possibly unknown to MacPorts.

-- 
Thomas de Grivel