security projects thoughts

Sat Apr 16 11:56:56 PDT 2011

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 securing the package runtime (which, I know, does not exist yet, thus providing all the more reason why we should work on that).

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 extremely tangental discussion).  Sounds fair, no?

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

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

- Jordan