Authenticated downloads & summary file

[Dan Nicholson]

On Sun, Feb 16, 2020 at 11:38 PM Daniel Drake <drake at endlessm.com> wrote:
>
> Hi,
>
> I'm working on an OS-level feature around managing OS aspects which
> are not managed by ostree itself:
> https://mail.gnome.org/archives/ostree-list/2020-February/msg00000.html
>
> Working through this in our product context, I am facing the necessity
> of authenticated access to ostree branches. Right now I just need a
> design - the implementation can come later. And naturally adopting the
> same design as flatpak would be ideal.
>
> Looking through the current flatpak authenticated downloads work, I
> have a couple of questions.
>
> 1. Am I right in saying that the current design does not protect the
> summary file? The ref name and commit ID for all private flatpak refs
> can be seen by anyone, without authentication?

Yes, currently the summary file and ostree-metadata commit are
readable by anyone. Likewise the appstream commits which contain the
presentation information for flatpaks.

> In this case, I would like to have private refs that cannot be
> enumerated by anyone who doesn't already know that they are there. In
> other words, I would like to protect the textual info expressed in the
> ref name from the general public. (Obfuscating it would be one option,
> but not an ideal one).
>
> I experimented with ostree (without the authenticated downloads bits).
> If there is no summary file on the server, I get the desired
> behaviour, refs can't be enumerated by a remote client, but known refs
> can be pulled.
>
> If there is a summary file though, ostree will trust it as a full list
> of refs. If you try to access a ref that is not listed there, the
> ostree client will fail, even if the ref truly exists and removing the
> summary file would actually make it accessible.
>
> Omitting the summary file on a production server doesn't appear
> practical, because static delta functionality relies on it being
> there.
>
> Hopefully ostree's client behaviour could be tweaked to allow access
> to refs even though they aren't listed in any summary file which
> actually exists.
>
> If so, is there room in the flatpak authenticated download design to
> allow for authenticated access to such "ghost" refs? Or is their
> presence in the summary file a fundamental part of this access control
> feature?

The summary is pretty vital to flatpak (a lot of custom metadata is
added to the summary so that clients can get useful information), so
it would be pretty hard to have flatpak leave out some refs. Making a
client fall back to direct ref access when the summary exists would
have to be fixed in ostree, but the flatpak client would be missing a
lot of useful information that's normally gathered from the summary.

I think to fix that you'd have to add a flatpak remote option that
tells the client that the repo metadata (summary, ostree-metadata,
appstream) also requires authentication. Then the client would go
through the authentication process before gathering repo metadata.
This would still be all or nothing, though - the information in the
metadata would still be entirely exposed once the user authenticated.
This would obviously need matching functionality on the server (i.e.,
flat-manager) with an option to protect access to the metadata URLs.

Making it so that the metadata only exposed what the user was
permitted to access would be a more invasive change. The server would
have to build and sign custom metadata on the fly for consumers. I
think it's possible, but it would be some work and it would be pretty
resource intensive on the server.

> 2. Are static deltas protected?
> If a static delta corresponds to a protected ref, the delta will be
> listed in the summary file (in terms of which commits the delta can be
> applied from and to). Is the download of such static delta content
> protected in the same way as the commit object is?
>
> In this case, it is desired that the static delta download is authenticated.

They are. What's protected by the current flatpak authentication
implementation is commit objects. The thinking is that without the
commit object then you don't know the checksums for the content
objects and therefore won't be able to easily obtain the content in
the commit. This information is in the actual commit object as well as
the delta superblock where the commit object is embedded. So,
flat-manager currently protects objects/*/*.commit and
deltas/*/*/superblock. It then parses the ref bindings in the commit
objects to see if they match the allowed refs in the authentication
token.

--
Dan