security projects thoughts

[Jordan K. Hubbard]

On Apr 13, 2011, at 1:15 AM, Thomas de Grivel wrote:

> Lol Jordan
> 
> This man comes with a sound project, basically laying out in nice words all the needed separate steps to provide port security and you just basically TL;DR him saying it will fuck-never happen ?

Nothing personal intended, I'm just trying to be a realist. :)

> Most of the steps proposed by Baynard are actually implemented in OpenBSD and he says OpenSolaris too, and frankly any source building system should have at least half of these features. So there's plenty of code-base around, and as pointed out an obvious security hole in every box with macports.

As I said, I didn't disagree with any of his ideas from a general security standpoint, and both OpenBSD and OpenSolaris either have (or had) a strong security focus right from the very start or lots of paid engineers (in the latter case) working on Enterprise customer problems, which tends to drive innovation along the same lines.  However, just saying that Open* have such technologies is not the same as saying that all of those technologies will be easily portable to Mac OS X or that it's a good use of the MacPorts project's time to focus on that.  Mac OS X is primarily a consumer operating system with folks like Your Mom™ using it on a daily basis, an attribute which already sets it well apart from the other operating systems you mentioned.  I've also said it many times and I'll say it again:  MacPorts should not be exposed to end-users because end-users do not know how to build software nor should they have to know.  Sure, if it's just us geeks on macports-dev talking then OF COURSE we all know how to build software and probably occasionally get woodies from watching the process in action.  That does not make us the majority, however, or anything even remotely close to it, and engineers who build software for other engineers generally fail unless they're working on extremely specific technologies like developer tools.

That's why I've always said (over and over and over and ...) that the ultimate value of MacPorts is in the packages it's capable of generating, pushing the problem of actually building those packages off onto automation rather than expecting that anyone other than port maintainers will ever want to.  The process by which those packages are delivered to the end-user also needs to be secure, as does (someday) the execution environment they run under (via sandboxing), but I just don't see much value in adding security to the sausage factory itself, especially when it's still struggling to ship its first shrink-wrapped, ready-to-eat sausage to consumers.   There are a million worthy projects out there, including many in the security domain, which is why focus is important.

> Reviewing points proposed by Baynard :
> 
> 1. Setting up a non-root user is a no-brainer, not a 20,000 feet level project.

That's already done.  See the current ports execution environment.  It even throws sudo privs away if it has them - something which has screwed me up a few times.

> 2. Publish the hashes of all distributed files and sign the hashes. Check the signature on selfupdate and check hash on download. This might be less than 20 lines total once PGP is setup and would be a *huge* security gain.

Again, a "huge" security gain to a very limited audience.  What's the point of signing the hashes?  Fear that someone is going to compromise the ports tree itself?  That doesn't seem like a particularly pragmatic concern when stacked against all the others.   Similarly, I don't see a lot of win in trying to limit the execution environment of ports themselves for all the reasons I listed in my 3rd paragraph (from the top) above.  I do security for a living and I frankly am not nearly as concerned by what goes on during the port building process (if I'm really concerned, I'll just chroot the whole build environment) as I am by what the end-result does.  Let's pick the Gimp as a popular example (and not to pick on it because I have any reason to mistrust it, but simply because I need an example).  I can vet the source tarball, I can vet the process I used to build the gimp, and I can even vet the gimp binary itself (somehow) for "reasonable behavior".  Then I go and actually start using the Gimp on a daily basis for all my image editing and find out pretty quickly that all the really useful stuff is in the plugin space.  I start installing plug-ins until, ultimately, I stumble across a malicious one which compromises my Gimp process and uses the opportunity to read all of my email and send it to some compromised machine in Serbia.   At that point it's Game Over and I soon find myself trying to hide under the same rock as Aaron Barr, fighting him for the last of the stale bread rations.

What's truly irritating is that every time the subject of runtime exploit mitigation comes up, it gets even less traction than this discussion.  "Oh man, that's HARD though.  We'll never get stuff to run in a sandbox!   Developers will never co-operate!" and that's where we tend to leave things, each and every time, and go back to focusing on securing things for which the wins are infinitely smaller.

- Jordan