security projects thoughts

Wed Apr 6 17:34:00 PDT 2011

Hi Baynard,

While I don't disagree with any of these ideas from an overall security standpoint, I think it's also fair to say that none of this will ever happen.  Why?  Two reasons:

1. Again, all of your proposals seem to revolve around securing "ports" and the whole process of building software in general, right down to establishing the provenance of the original source tarballs.

2. These proposals are complicated in nature and not easily broken down into a more tractable set of near-term steps for getting even slightly closer to the goal.  Big picture initiatives tend to die from starvation in the MacPorts project, and if something can't be done as a series of small steps for which there are clear rewards at each and every increment, it won't get done.

I'm not saying that your proposal isn't desirable from some 20,000 foot level where the notion of software which can be built 100% reproducibly and in a trustworthy fashion is quite interesting to contemplate, I'm just saying that it's too high-falutin' a goal for this project, where even being able to create binary, end-user-centric packages is still a distant goal despite having been discussed literally for years.

To use an analogy, you're coming in with several cases of rare wine and talking about doing an elaborate tasting with imported french brie and baguettes whereas the project has only just discovered light beer and corn chips and thinks that's as good as life can possibly get. ;-)

- Jordan

On Apr 6, 2011, at 9:53 AM, Bayard Bell wrote:

> I've been chewing on how to tackle the security issues I've attempted to lay out previously, including what feedback I've already received from Rainer in particular. Hoping to carry the conversation forward, I'd like to float the following for feedback.
> 
> 1) changing the privilege levels in macports so that there is a distinct macports user, which will be the normal euid/egid, while root is used only for steps requiring privilege (there's nothing special about nobody, and it's probably not a good thing to have the contents of macports owned by a user who's supposed to have no privileges because that ends up making that user privileged)
> 2) provide a system and policies for implementing signatures for the distribution, Portfiles and related content, and binaries used either locally or for packaged redistribution
> 3) arrive at a safe Portfile evaluation and execution model, minimally so that ports can't reclaim privilege without additional signature-based controls (e.g. a Portfile might treated as a quasi-trusted input once the signature has been verified, but to have an operation run as root would require an additional signature from a source like security at macports.org or one set by local policy, such that Portfiles taken from untrusted parties can't directly and trivially exploit Macports as a means to system compromise)
> 4) implement a signature-based system for verifying downloaded source (in preference to the current checksum-based system) and provide warnings where code attribution (because it isn't signed) or integrity (not only is it unsigned but is downloaded without a secure transport) can't be verified, and, where hashing alone is available, upgrade digest algorithms to support at least SHA256 and deprecate MD5 (plenty of projects still use this when providing digest-based signatures, but the algorithm isn't considered fit for purpose by reasonably authoritative sources like NIST)
> 5) provide an additional concept of test and fingerprint packages and with package-level signing so that releases can be promoted or catalogued based on hygiene, reproducibility, testing, compatibility and variant checking (I sketched out a few more details in another way, suggesting that a fairly mature packaging system such as IPS might be easily adapted to serve as a kind of message bus for several kinds of communications channels and workflows)
> 
> I mentioned something about the idea of test packages previously, and I was chewing on the possibilities suggested by multiple signatories to a package in IPS (image packaging system, the new packaging system for OpenSolaris, which continues to be FOSS and advertised by Oracle as supporting OS X), as well as "fat" packaging with variant support. Here's the write-up:
> 
> http://src.opensolaris.org/source/xref/pkg/gate/doc/signed_manifests.txt
> 
> I'm intrigued by the suggestion of multiple signatures and having the QA organisation sign a release before it's published to customers, and I've been trying to think through how that might work in a community-controlled model, such that there's peer review for changes before they become widely available and community feedback before they become designated as stable. There are a lot of ways that this could be done, but what I'm most curious to know is how the macports developer would anticipate or want this to work as a process level rather than in terms of the implementing technology.
> _______________________________________________
> 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/20110406/73e0336a/attachment-0001.html>