[RFC]Secure ImageBuilders

[Paul Spooren]

Hi,

Over the last month I suggested two different approaches to improve the
ImageBuilder security. The amount of feedback was fairly low, maybe
partly because it's not trivial to understand the issue. I wrote a
summary of the two approaches and the current problem, please spend the
5 minutes to read through it. It's a release goal for 20.x.

The current state of 19.07 ImageBuilders is insecure as the packages
that are missing locally are downloaded via unencrypted HTTP and then
directly installed, without any signature verification. As a
consequence, images could contain malicious binaries if an attacker was
able to intercept traffic.

For now the SNAPSHOT ImageBuilder uses HTTPS for package downloads,
which is suboptimal as HTTPS slows down the build process by about 50%,
due to missing connection pooling in OPKG. A better implementation is to
use OPKG signature checking (via `usign`), which is fast and the same
mechanism as on running OpenWrt devices.

However, the  ImageBuilder offer a special folder called `packages/`,
which contains `kernel-*.ipk`, `libc-*.ipk` and any other optional `ipk`
files provided by the user. The folder is indexed after every change.
The use case is that locally built packages can be included in images,
instead of providing them via a remote repository.

This folder adds the challenge for signature checking. OPKG can not
*only* check remote feeds and trust local feeds. Below are two possible
implementation to allow signature checking while allow a local
`packages/` feed.

## Possible implementation

Both implementation have their advantages and drawbacks, this document
summarizes two different approaches to simplify the decision.

### Add trusted feeds to OPKG

The approach adds a new feed type which is always trusted, as in *no
signature checks are done, even if globally enabled*. This was done by
adding a new feed prefix to OPKG, either `src/trusted` or
`src/gz/trusted`. The local `packages/` feed is added as `src/trusted`
and work independently of `option signature_check`.

This implementation involves changes in OPKG [here][1] with a bit of
glue code in the build system [here][2].

[1]: https://patchwork.ozlabs.org/project/openwrt/patch/20200916011041.1746959-1-mail@aparcar.org/
[2]: https://patchwork.ozlabs.org/project/openwrt/patch/20200916012457.1748220-1-mail@aparcar.org/

It is simple and the only possible attack is to modify the repositories
file and set a feed from `src/gz` to `src/gz/trusted`. In that case it
would also be possible to replace the entire feed address, therefore a
minor *security issues*.

### Let ImageBuilder create signing keys 

The approach runs the same signing key generation steps as the build
system. The keys are used to sign the local `packages/` feed and
therefore don't require any additional changes in OPKG. Arguably this
approach is a bit awkward because a feed is verified by a public key
which was created on the very same machine.

On the other hand, this approach brings the advantage that created
images can contain a `usign`/`ucert` signature, so that created images
are verifiable by the on device running `sysupgrade` process, if the
ImageBuilders local key was previously included.

This implementation exists [here][3] with the extra option to include
the locally generated key in the build images.

[3]: https://github.com/openwrt/openwrt/pull/3477

Best,
Paul