security projects thoughts

[Bayard Bell]

So, let's take it that security is the cumulative property of the tools, the process, and the hosting arrangement.

For starters, I think a fundamental question is what kind of signatures to use and how things are signed. ASF, for example, does a pretty job of laying this out in one page:

http://www.apache.org/dev/release-signing

I'm not saying it's perfect, let's rip this off (ASF are solving somewhat different problems), just taking an example that shows how one community tries to make all the pieces fit. All of that's to say: it's not just a matter of how to code in security but to add it in a way that people see it as mutually enabling, even if it's not as simple as doing without. It therefore seems reasonable to ask some questions to help people understand how it might impact them and draw up requirements from there. I also take to heart your suggestion that this needs to be made as bite-sized as possible so that it actually happens.

I've read back on the threads from March about binary packaging and appreciate better what constraints were accepted to simplify deployment. The signed Macports releases in distfiles that Anders pointed me to is signed with GPG. Given that we're talking about developer tools rather than packaging, is it reasonable to add this to the base requirements for macports? Are people fine with the idea of using PGP with macports and openssl with the packaging system? If you go the GPG route for macports, do you want individual developers signing things with their own keys, or do you want to have a common key, as do the major RPM and apt distros? If the current deployment model is that updates are applied to the SCM and then dumped to the rsync repo and mirrored, do you want something robo-signing what's dumped, or do you want manifests extracted from the SCM that already provide detached signatures? How, in any case, will you manage the keyring used by macports, which presumably would be distinct (e.g. how do you not repeat Debian's key rotation problem)? And how do you publish your keys so that they can be verified? What gets signed? Individual ports (Portfile + files, the base)? Manifests? How are signatures packaged (e.g. nested tarballs, as MIT does or something like tarballs with a signed manifest, as Anders suggested for packaging)? Is the impact on the update mechanisms acceptable? Is the objective just to protect ports and the base while they're being shipped around the network, or are other integrity needs? (At least for the initial exercise, limiting the exercise to protecting Portfiles in transit might be enough, while considering some kind of paranoid mode for robo-building down the line that only builds signed ports, such that you don't cause headaches for the considerable number of people who are both porters and Portfile consumers but, to follow your previous analogy, do put meat inspectors inside the sausage factory.)

As far as privilege reduction goes, is the idea to have a distinct macports user (e.g. macports)? What identifies ports needing to run as root? Is it sufficient to use a non-privileged user, try robo-building the existing stock of ports, and find out what breaks? What does the execution model look like? Is port invoked without sudo and some kind of lightweight wrapper that then decides whether to run as root or macports and then has the user authenticate appropriately? What about ports with prerequisites that don't have the same privilege requirements? Is the initial ambition just to separate out ports requiring root from others, saving for later determination of which phases require root? (Just as I'd bet that more than 80% of packages don't require root at all, I'd bet that more than 80% of packages that do require root only require it for installation, but I'd probably be happy banking just the first 80% and coming back later for the rest.)

And, while you're at, is there any appetite to do some lint checks before shipping packages. One thing that's not clear to me is whether packages can be redistributed in binary form without licensing information, at least under some license terms. I believe there's a fair chunk of packages that don't have this, which perhaps means that linting is required before en masse package builds and that there needs to be some hook-up between linting and automated builds that generates fatal errors. Another thing to lint is source retrieval over insecure transports and maybe throw in some automation to try to identify sane alternatives (that doesn't need to be code committed to the base, it can just be a spring cleaning mop) so that there are less cases where build-on-demand could be trivially exploited via name service attacks. Signature-based checks on non-macports source would be something to implement after/if that's a problem macports solves for itself.

Cheers,
Bayard

On 17 Apr 2011, at 18:49, Jordan K. Hubbard wrote:

> 
> On Apr 16, 2011, at 1:00 PM, Arno Hautala wrote:
> 
>> It also doesn't seem unreasonable at all to enter into a discussion
>> about what can be done to improve security, what the tradeoffs are,
>> and where priorities should be placed, without making an initial
>> contribution of code.
> 
> An entirely fair point, and just to be clear, I wasn't trying to say "If you have no patches, shut up!" or even imply that, I was simply saying that we had been debating the topic for awhile and if it was possible to take it out of the realm of debate and into more concrete "here's specifically what I mean in the form of patches" territory, that would be desirable, particularly when the topic is somewhat controversial.
> 
> - Jordan
> 
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20110418/c07a854a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1515 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20110418/c07a854a/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 841 bytes
Desc: This is a digitally signed message part
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20110418/c07a854a/attachment-0003.bin>