security projects thoughts

[Bayard Bell]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20110406/3a3f46e5/attachment.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/20110406/3a3f46e5/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 203 bytes
Desc: This is a digitally signed message part
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20110406/3a3f46e5/attachment-0001.bin>