Re: Moving existing ostree users to a new branch - take 2

[Colin Walters <walters verbum org>]

Let's dive into just this bit:

On Fri, May 12, 2017, at 06:13 AM, Alexander Larsson wrote:
> In
> particular, we need the signature on the summary, because otherwise
> we'd be vulnerable to a sidegrade attack where you switch one ref to a
> commit from another ref. If we record the ref in the commit, then we
> can possibly avoid the sidegrade attack, but that also seems like a
> weird design, commits are not supposed to be tied to one branch only.

I happened to see this go by today:
https://alephsecurity.com/2017/05/11/oneplus-ota/

Basically, the OnePlus phone updates are vulnerable to these kinds
of sidegrades and in some cases plain downgrades.

Now of course, libostree does have a timestamp check, but in practice
that only helps a bit - take the Fedora Atomic Host where there are two
active refs:

fedora-atomic/25/x86_64/docker-host
fedora/26/x86_64/atomic-host

(Yes, we're renaming it for f26)  Right now indeed we aren't signing the summary
file, so an attacker capable of MITM of TLS (i.e. until we do cert
pinning) could force a downgrade 26 -> 25 while 25 is still getting updates.  But on
the other hand, 25 is still getting updates, so hopefully it will also have the same
security fixes.  As soon as it stops being updated, "sidedown" attacks are no longer possible.

In Fedora AH today, we do migrate commits across refs indeed.  There are really 3:

fedora-atomic/25/x86_64/docker-host
fedora-atomic/25/x86_64/updates/docker-host
fedora-atomic/25/x86_64/updates-testing/docker-host

And the first ref is a "promotion" of the second.  (updates-testing is currently independent
but that's a whole subtopic)

But that said...this feels like a "developer/tester" thing.  If we expect the vast
majority of users to track a single ref, we could indeed inject into the commit
the name of the ref, and just relax the check for developer/testing scenario.

(e.g. rpm-ostree rebase --security=unbind-ref fedora-atomic/25/x86_64/updates/docker-host 
 which sets a local flag that turns off the "check commit ref" logic for that origin?)

Going up a level then, if we had this implemented, it would feel natural then to do
ref/repo redirections via commit metadata as well, right?