Some ostree observations

[Florian Weimer <fweimer redhat com>]

Colin asked me to have a look at OSTree.  Here is what I found.

In the images, the root account has no password.  This is even true for 
the images that run gnome-initial-setup, where it should be unnecessary.

/etc/machine-id is not generated at first boot.

The SSH host keys are generated *before* the kernel random subsystem is 
fully initialized:
Feb 20 10:50:46 localhost kernel: random: systemd urandom read with 3 
bits of entropy available
Feb 20 10:50:52 localhost sshd-keygen[691]: Generating SSH2 RSA host 
key: [  OK  ]
Feb 20 10:50:52 localhost sshd-keygen[691]: Generating SSH2 ECDSA host 
key: [  OK  ]
Feb 20 10:50:52 localhost sshd[739]: Server listening on 0.0.0.0 port 22.
Feb 20 10:50:52 localhost sshd[739]: Server listening on :: port 22.
Feb 20 10:50:55 localhost kernel: random: nonblocking pool is initialized
Feb 20 11:02:33 localhost sshd[739]: Received signal 15; terminating.
Feb 20 11:02:36 localhost kernel: random: systemd urandom read with 3 
bits of entropy available
Feb 20 11:02:42 localhost sshd[698]: Server listening on 0.0.0.0 port 22.
Feb 20 11:02:42 localhost sshd[698]: Server listening on :: port 22.
Feb 20 11:02:46 localhost kernel: random: nonblocking pool is initialized

Some images have no networking by default.

SELinux runs in permissive mode.

The images I tried used rawhide debugging kernels, which are ... slow.

The manual page does not describe all the sub-commands, and they are not 
discoverable at the command line interface, either.

"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.

The progress indicator during "ostree admin upgrade" downloads sometimes 
runs backwards and overlaps with the previously printed line.

Switching between different trees does not work reliably.  The command 
line tools indicate that the switch has happened, but a reboot loads the 
previous state.

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).

Non-fast-forward tree updates are not rejected in "ostree admin upgrade".

The name of the repository head is not covered by the GnuPG signature. 
As a result, a man-in-the-middle attack can cause an image to upgrade to 
a totally unrelated head from the same repository (because it is signed 
with the same trusted key).

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.

"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.

I still need to review what is signed by GnuPG and how the hash chaining 
works.  Unless there is some documentation I've missed, this will take 
quite a but of time because I have to reverse-engineer the data 
structures from the source code itself.

I didn't look at the generation side (rpm-ostree etc.) or anything 
beyond "ostree admin upgrade" because I couldn't find descriptions of 
actual usage scenarios, which makes it very hard to evaluate how things 
stand security-wise.

--
Florian Weimer / Red Hat Product Security Team