security projects thoughts

Thomas de Grivel billitch at gmail.com
Sun Apr 17 22:29:00 PDT 2011


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.


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


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


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

-- 
  Thomas de Grivel
  http://b.lowh.net/billitch


More information about the macports-dev mailing list