security projects thoughts

[Thomas de Grivel]

Le 04/16/11 16:59, Thomas de Grivel a écrit :
> 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...

...or more probably someone near you geographically.

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