Re: Some ostree observations

[Florian Weimer <fweimer redhat com>]

On 02/21/2014 01:35 PM, Colin Walters wrote:

> > "ostree admin upgrade" is slower than "yum upgrade" and transfers
> > about 50% more data. Most time is spent in downloading, not coming
> > even close to fully utilizing my end of the pipe. Apparently, HTTP
> > pipelining is not aggressive enough.
>
> We're comparing apples to oranges a bit because "yum upgrade" isn't an
> atomic upgrade.  But yes - if you are updating multiple things, RPM +
> deltarpm is generally going to be more efficient on the network.

Surprisingly, deltarpm doesn't really change the amount of transferred 
data all that much.

In my case, the amount of data being transferred isn't the problem, it's 
the number of server round-trips.  Those really limit the transfer 
speed, and cutting them down would help more than squeezing down the 
transfer volume (unless the repository is very close by on the network).

> > The SELinux relabeling following an upgrade seems insecure because it
> > uses the full path across potentially user-writable directories, but
> > exploitation would need user-writable directories in RPMs (which are
> > fortunately rare).
>
> By "user" here are we talking about humans that log in, or system
> daemons that run as non-root?  Both?

Basically, any non-root user.

> I can't think of a threat scenario here that OSTree would be vulnerable
> to that rpm/dpkg wouldn't.  Except maybe you're thinking I should be
> using setfscreatecon()?  Oh...I *definitely* need to do that for /etc,
> otherwise there is a window in which e.g. /etc/shadow is just etc_t and
> not shadow_t.   Filed:
> https://bugzilla.gnome.org/show_bug.cgi?id=724872
>
> But I'm assuming you meant some other bug...

I see in strace that something is calling lsetxattr with a full path. 
This is racy because the "l" part only applies to the final component of 
the path.  Other SELinux utilities have this bug as well.  A complete 
fix needs kernel changes and probably a new system call (fsetxattrat).

> > The signature verification code enables downgrade attacks because it
> > does not reject stale/out-of-date signatures. Again, this is made
> > worse by not rejecting non-fast-forward commits.
>
> I think this one is covered by the timestamp now.

To some degree, yes.  It's still possible to deny upgrades without the 
user noticing the problem.

> > "ostree admin upgrade" stores .filez objects with malformed headers in
> > files in the /ostree/repo/tmp directory, causing subsequent upgrades
> > to fail even if a non-malformed object is now available for download.
> > I'm not sure what causes this, but it can't be good that
> > _ostree_repo_has_loose_object does not verify the checksum of the
> > loose object.
>
>   _ostree_repo_has_loose_object() won't look in the tmp/ directory -
> that's only used as a staging area for partial objects.  Once something
> lands in /ostree/repo/objects, it should have had its SHA256 checked.
>   (Although I am considering relaxing this for objects fetched over TLS,
> at least optionally)

This wasn't based on source code review, I saw it when running "ostree 
admin upgrade" on a hostile network.  It's not clear to me how this 
happened.  I can try to build a proper reproducer.

--
Florian Weimer / Red Hat Product Security Team