security projects thoughts

[Thomas de Grivel]

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 ?

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.

We should at least aim for ports correctness if not for avoiding crafted 
exploits. I know it's not the first security hole on a Mac but I think 
most MacPorts users are also developers who probably want to keep part 
of their work private. So every dev here should be concerned.

For those resisting the security implications of not using crypto to 
fetch and compile sources, I will point out that every MacPorts users 
who installed ports from a non-trusted local network are currently 
possibly leaking source code, CC numbers, passwords, and such.

Reviewing points proposed by Baynard :

1. Setting up a non-root user is a no-brainer, not a 20,000 feet level 
project.

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.

3. Ok, this may be harder and need design, but good codebase exists 
(openbsd is very good at this) and just checking root privileges as 
Baynard suggested is not so hard.

4. Upstream signatures is a never-ending work, just like ports, but the 
infrastructure itself is quite trivial.

5. Is pure overdesign given the release model of MacPorts and has 
probably left an overkill taste in your mouth. I'll join Jordan on this one.

I think 1 and 2 are outstanding issues in MacPorts and not so hard given 
the huge benefit. 3 and 4 would need more discussion but are good ideas.

Anyway, just my 2¢. Let's hope that security on a Mac will only get better.

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


Le 04/07/11 02:34, Jordan K. Hubbard a écrit :
> 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 <mailto: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.