security projects thoughts

Mon Apr 18 05:27:33 PDT 2011

On Apr 18, 2011, at 1:29 AM, Thomas de Grivel wrote:

> Le 04/16/11 20:56, Jordan K. Hubbard a écrit :
>> 
>> On Apr 16, 2011, at 7:59 AM, Thomas de Grivel wrote:
>> 
>>> I can't believe you actually mean that. I think you do not understand the problems fixed by this security proposition. And this limited audience is the one reading here, you're talking about *our* private data.
>> 
>> Hurmph.  Again, if you care that much about your private data and don't trust the MacPorts build process, create a chroot environment for building software and don't build it as root (who can easily escape a chroot) in there!   I have done this myself many times and it's not particularly difficult.  If you're already knowledgable enough to install the developer tools, install MacPorts, use the command line environment in Terminal.app then you're already several orders of magnitude more geeky than the average Mac user and should be able to manage your own security just fine and that's all I've really been saying all the time.  I'm not saying that developers don't need security - they do.  I'm just saying that they're already likely to be so firewalled and Little Snitch'd (for outgoing connections) and generally "in charge" of their own data that the engineering return in "securing" them is much lower than it would be were the same amount of time and energy invested in securi
> ng
>>   the package runtime (which, I know, does not exist yet, thus providing all the more reason why we should work on that).
> 
> I don't really see the point of the chroot : once your infected sudo is built and you install it because you trust the hash, what good is it ?
> 
> And once it is packaged this way and distributed to unknowing end users ?
> 
> The problem is that you don't even know the sources have been infected.
> 
> How can you ever know ? With a cryptographic signature ! This way you can verify that you retrieved the sources that the port maintainer intended you to, and that every other MacPorts dev too : anyone can review the same code, signed by the maintainer.
> 

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.

> 
>> Now, all that said, we've been debating this whole topic in something of a rarified atmosphere.  If you have a small pile of patches that you are sitting on which actually implement "securing the supply chain" in building ports then that's obviously a different story since you're not only asking for this feature, you're "putting your money where your mouth is" (an english colloquialism not meant to be taken literally) and actually doing the work involved, in which case you should submit them for review and see what people think of your implementation.  If the patches fit nicely into the existing system (or at least don't bend it too badly) and the port masters (of which, BTW, I am NOT one) approve, then woot!  You will get this done to your satisfaction and the developers will get a bit more security, redundant or not, leaving everyone else free to figure out this whole packages thing (which, it might be pointed out, was the actual GSoC project that started this whole extre
> me
>>  ly tangental discussion).  Sounds fair, no?
> 
> Of course, no harm intended, and nothing personal, I don't know anyone here. I have no code to contribute. I was just amazed by your answer to OP and pointing at some fairly trivial but maybe not so apparent security issues. I was also addressing to anyone on this list silently letting us both troll alone about this issue. Dorks.
> 
> 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.

> 
>>> If your network is not trusted, like almost any open wifi network, compromising the macports tree and sources is trivial. And if you really do not see why I'm making this point then maybe you should think about resigning from your security responsibilities whatever they are unless you implement them in a world with no network.
>> 
>> Heh.  That is an interestingly self-canceling argument.  "If you are not willing to go out of your way to facilitate my own unwise usage of the machine in a completely unsecured environment, then you are a baaaaad security professional!" ;-)   To those watching this discussion from the cheap seats:  Please don't do that.  If you must use untrusted wifi environments, and we all find that necessary from time to time, then either confine that usage to scenarios where information leakage / MITM attacks don't particularly matter (looking for a map on google maps or a restaurant on yelp) or use a frickin' VPN set to route *all* of your traffic!  That's what VPNs are for!  Learn from the whole firesheep saga!   Sorry, erm,</rant>.
> 
> This is not about trusting the environment but about who you are actually letting modify your data and thus the installed ports. Without cryptographic signatures, anyone controlling the network can. Whether they own it, work as admins, or just hacked it.
> 
> The network operator should definitely not be allowed to inject code into my system.
> 

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.
> 
>>> Imagine I dispose of a modified version of sudo which actually installs a keyloger on the machine. I could write that in 2h tops. Generating a new hash for the modified source is trivial. Writing the ports file too.
>> 
>> Which is one reason why specific priv-elevation tools like sudo are bundled with the system (and signed) - installing setuid tools like this with untrusted provenance is just asking for trouble in almost any scenario.  But sure, you could also go after something non-privileged and use it to export other valuable user data.  Here, however, is where we seem to be more in violent agreement rather than disagreement.  I don't like that scenario either, and I've been consistently arguing more for runtime mitigation on the grounds that you can sandbox things *regardless* of their source.  You, on the other hand, are arguing that you want to put that same attention into the build process.  Fine, there are potential wins in both categories, I'm just keener on the first one because it seems like more bang for the buck.
> 
> There is a "sudo" port that gets updated like other ports.
> https://trac.macports.org/browser/trunk/dports/sysutils/sudo/Portfile
> 

Correct: MacPorts contains sudo which is built and installed *AS ROOT*
just like every other package.

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