security projects thoughts

[Thomas de Grivel]

Le 04/13/11 21:30, Jordan K. Hubbard a écrit :
>
> 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 th
en 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 s
tart 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.

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.

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.

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.

Intercepting connections to macports.org on a wifi is trivial with 
ettercap. Sending modified versions of port and sources is a matter of 
having apache around.

With your hash-only security model every macports contributor is 3h of 
work away from rooted.

On the other hand, just signing the hash makes it almost completely 
impossible to craft one in less than 1000 years. Now do you see the tiny 
effort of signing for the huge improvement for every person installing 
sudo from macports ?

Many MacPorts users are building start-ups or involved in research 
project. I feel we should not let them down just because they chose to 
work with open-source software on a Mac.


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

I'd like to watch you try to mitigate a compromised sudo installation on 
your own computer without even knowing it has happened and all your data 
used by some geek in Kazakhstan...

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