talkin' 'bout GSoC 2011

[Bayard Bell]

Rainer,

I'm limited my responses to security issues, where I'm working to understand the design and implementation by reading your comments with the existing code. I'll attempt to answer your two other questions in a separate mail. I'm still trying to understand how the security problems are defined and how the implementation is expected to deliver, so I'm trying not to get ahead of myself by making too many suggestions, although I probably indulge in a few places.

On 30 Mar 2011, at 09:23, Rainer Müller wrote:

>> My interests in macports are pretty diverse, so I'll start with some
>> more blue sky ideas I have based on previous experience. I'd like to see
>> macports become a more distributed system with broader capabilities
>> across the development lifecycle (e.g. able to do automated building and
>> testing, able to build and distribute packages, or to provide builds
>> software for running off of network storage). 
> 
> What exactly would be required to do automated building in MacPorts
> itself? For example we have MPAB which wraps around port to implement
> automated building.

Spending a little time with MPAB, I end up with pretty severe reservations. Using chroot() as a security mechanism provides limited benefits for limiting filesystem access. When you don't drop privileges inside of the jail, it's a jail with papers walls–the Wikipedia entry for chroot starts of the limitations section with the following: "The chroot mechanism is not intended to defend against intentional tampering by privileged (root) users" and goes onto list several ways to abuse a chroot environ if you've got privileged access. Given my understanding of the general weaknesses of macports security and its reliance on root, it looks to me like MPAB misapprehends the problem definition, but my understanding is basic on a pretty cursory inspection.

By way of contrast, when Sun was providing allowing community supported binary packages for OpenSolaris via SourceJuicer, they had a system that built and then destroyed a virtual machine for each package built.

>> I kinda think security's going to be a profound problem for macports as
>> long as so many commands are run as root under sudo, and the Portfiles
>> are scripts rather than configuration files per se, running without in
>> any kind of sandbox or sanitisation.
> 
> Yes, a lot of things rely on review here. Trace mode is intended to
> limit and detect file accesses, but currently it's used as a development
> tool for maintainers only.

More to the point, it looks like what's emitted by the trace is essentially at the discretion of what's being traced–under the current system, if I don't want anything to appear in the log, I use system to invoke my script and use something like the exec shell mechanism to prevent further output from appearing in the log (or whatever equivalent to replacing the inherited stdout/stderr). I should add, the same fundamentally insecure mechanism used to update the Portfiles via rsync also updates the code, so if I'm doing an MITM attack against a macports user, I can just as easily compromise the core code and strip out or alter the trace facility. These aren't characteristics of a system that can be protected by being tamper-evident.

I think one priority should be securing the update mechanism to use a secure channel and authenticate the source, but I don't think the story ends there.

>> Also on the topic of security: as I see it, pretty much the only place
>> that root is consistently needed is for the install step (as opposed to
>> fetch, extract, configure, build, etc.), but the way the system
>> currently works, people use it as root most of the time. Other than
>> that, running the code as a non-privileged user, who would own most of
>> the filesystem data, seems far more sane, and running client-server
>> might allow much more of the current start-up time to be passed along to
>> the server, making the client a lot snappier.
> 
> On trunk, MacPorts drops privileges to nobody if root permissions are
> not required. On 1.9 the functionality is in place, but not used by default.

I'm working back from https://trac.macports.org/wiki/gsoc08-privileges, as it looks like this is largely a matter of setting macportsuser in ${prefix}//share/macports/Tcl/macports1.0/macports_autoconf.tcl at install time.

I don't think such functionality amounts to much, however: all you're doing is changing effective uid and gid and continuing to run in the same process, so it's trivial to recover the saved credentials. (Given what I've seen of the initialisation time for Tcl, sub-processes aren't that appealing, but that's a different problem.) There are reasons that set-id isn't a preferred model for limiting access to privilege these days: it's far better to factor privileged operations into separate services and have clean IPC for requesting privileged operations, running without privilege elsewhere (and doing so on a process level). (Postfix is a notable example of this approach, dating back over a decade.) If you hear Apple talking about security architecture in OS X (e.g. at their Google TechTalk about launchd), they're pretty clear in saying that they are removing setuid and replacing it with service-based implementations. 

I'm still getting up to speed on the code, but, at the risk of again editorialising for emphasis, my reading of it is that all security mechanisms can't meaningfully scrutinise or limit the Portfiles because they are effectively trusted extensions to the core code, which has an execution model that makes it hard to remove privilege robustly.

Cheers,
Bayard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20110330/a785c1cf/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/20110330/a785c1cf/attachment-0002.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/20110330/a785c1cf/attachment-0003.bin>