Threat modeling and MacPorts [was Re: security projects thoughts]

[Arno Hautala]

On Tue, Apr 19, 2011 at 17:03, Jordan K. Hubbard <jkh at apple.com> wrote:
>
> Step 1:  Source tarballs on random web/ftp sites.
> [...]
>  Do we get more or less assurance by caching all of the tarballs on Mac OS
> Forge?  It restores some level of control, but it also means there's one
> centralized location to attack now, too.

This actually sounds tempting to me. It would solve the problem of
unannounced edits to the source tarball and would also provide a
consistent resource for hosting VCS snapshots where tarballs aren't
provided.

I don't know that I'd be concerned about the centralized attack. The
MacPorts binaries would already be there and the package management
systems for pretty much every *nix distribution uses a centralized
repository (even if they also use repository mirrors).

> Recommendation: 1a ... 1b ...

All this sounds good. Mirroring sources would of course solve the
issue of upstream hash failures.

> Step 2:  The runtime behavior of individual ports during the build and
> installation process.

This definitely gets into the realm of quality control. Try as hard as
possible to audit your Portfiles before submitting them and test the
software as best you can. One alternative is the Fink route with
stable and unstable branches. Personally, I'd prefer a more
restrictive submission process; something that tries to enforce that
port submitters have thoroughly audited and tested their ports.  I
don't know how effective that would be though. It could at least be a
recommendation in the port submission guide.

> Recommendation:  Run this part of the build/install process under a highly
> restrictive trace mode "chroot" [...]

You're the chroot expert. :-)

The only addition that I can think of relates to how ports are
accepted in the first place. Should any sort of tracking of the port
submitter occur? Should submitters be required to sign their
submissions? Should things all fall back to whoever commits the
Portfile? Some of this is getting to deep into the details.


> Step 3: The MacPorts infrastructure itself.

> Recommendation:
> 2a.  Sign the official MacPorts packages if they aren't already.

They are. Thanks Josh!

> 2b.  Make sure r/w access to the repository [...]

Sounds good.

> 2c.  Make sure that all of the MacPorts infrastructure files on-disk are
> properly owned by a privileged user and not easily modifiable [...]

Probably a good idea to check permissions and such, but this is where
it starts to get into the realm of trying to keep users from doing
something stupid. Or protecting against physical access attacks. Both
are good ideas, but there's only so much that is reasonable to try. I
think it'd be enough to verify the infrastructure when it is initially
installed and then provide a tool that can verify (and repair?) on
demand. _Maybe_ also during "port selfupdate"?


> Step 4:  The legendary MacPorts Binary Packages.

All that sounds good. Again, you're the chroot / sandbox expert :-)


> Step 5:  Runtime behavior of MacPorts-provided software.
> Recommendation:       This is clearly a sandbox challenge, and I'll be able
> to say a lot more about the whys and wherefores of that in the future, just
> not quite yet. :-)

That sounds deliciously cryptic and enticing.

One question about sandboxing though. What is actually restricted?
Would you not be allowed to run "rm",  for example, because it could
alter user or system files? Or is sandboxing an optional feature that
is turned on and off as needed?

Or will all be revealed soon? ;-)


> Does that about cover it?   Did I miss anything?


The only other item regards the key that is used to sign everything.
Currently it looks to be JMR's personal key. This is fine, but it
might be nice to generate an "official" MacPorts key that is
controlled by whoever is the current project lead. This key can then
be regenerated by whoever takes over as the new lead and optionally
signed by the old lead.

That's getting into the details though and can wait for a later day.
Though I'd certainly be up for a MacPorts key signing party :-)


-- 
arno  s  hautala    /-|   arno at alum.wpi.edu

pgp b2c9d448