63 lines
6.9 KiB
Markdown
63 lines
6.9 KiB
Markdown
---
|
||
title: "Bits relating to Alpine security initiatives in August"
|
||
date: "2021-09-07"
|
||
---
|
||
|
||
As always, the primary focus of my work in Alpine is related to security, either through non-maintainer updates to address CVEs, new initiatives for hardening Alpine, maintenance of critical security-related packages or working with other projects to improve our workflows with better information sharing. Here are some updates on that, which are slightly delayed because of the long weekend.
|
||
|
||
## `sudo` deprecation
|
||
|
||
One of the key things we discussed in the last update was our plan to deprecate `sudo`, by moving it to `community`. `sudo` exists in a similar situation as `firejail`: it allows for some interesting use cases, but the security track record is not very good. Additionally, the maintenance lifecycle for a release branch of `sudo` is very short, which makes it difficult to provide long-term support for any given version.
|
||
|
||
As such, the security team proposed to the Technical Steering Committee that we should deprecate `sudo` and move to an alternative implementation such as `doas`. This required some work, namely, `doas` needed to gain support for configuration directories. I wrote a patch for [`doas` which provides support for configuration directories](https://github.com/Duncaen/OpenDoas/pull/71), and last week, pushed a [`doas` package which includes this patch with some migration scripts](https://gitlab.alpinelinux.org/alpine/aports/-/commit/0d85d8f3ef9d3a98ecc6df434fafe2fd67baee14).
|
||
|
||
At this point, basically everything which depended on `sudo` for technical reasons has been moved over to using `doas`. We are just waiting for the `cloud-init` maintainer to finish testing their support for `doas`. Once that is done, `sudo` will be moved to `community`.
|
||
|
||
## OpenSSL 3.0
|
||
|
||
OpenSSL 3.0 was released today. It is my intention to migrate Alpine to using it where possible. As OpenSSL 3.0 will require a major rebuild, after talking with Timo, we will be coordinating this migration plan with the Technical Steering Committee. Switching to OpenSSL 3.0 should not be as invasive as the OpenSSL 1.0 to 1.1 migration, as they did not change the APIs that much, and will give us the benefit of finally being free of that damn GPL-incompatible OpenSSL license, as OpenSSL 3 was relicensed to use the Apache 2.0 license.
|
||
|
||
I have already done some test rebuilds which covered much of the `aports` package set, and did not see much fallout so far. Even packages which use the more lowlevel APIs, such as those in `libcrypto` compiled without any major problems.
|
||
|
||
A nice effect of the license change is that we should be able to drop dependencies on less audited TLS libraries, like GNU TLS, as many programs are licensed under GPL and therefore not compatible with the original OpenSSL license.
|
||
|
||
## Reproducible Builds
|
||
|
||
We are starting to take steps towards reproducible packages. The main blocker on that issue was determining what to do about storing the build metadata, so that a build environment can be recreated precisely. To that extent, I have a patch to `abuild` which records all of the details exactly. A rebuilder can then simply install the pinned packages with `apk add --virtual`.
|
||
|
||
We will need some way to archive historically built packages for the verification process. Right now, the archive only ships current packages for each branch. I am thinking about building something with ZFS or similar which snapshots the archive on a daily basis, but suggestions are welcome if anyone knows of better approaches.
|
||
|
||
Once these two things are addressed, we need to also add support for attempting rebuilds to the `rebuilderd` project. In general, we should be able to model our support based on the support implemented for Arch Linux.
|
||
|
||
I am expecting to make significant progress on getting the `.BUILDINFO` file support merged into `abuild` and support for `rebuilderd` over the next month. kpcyrd has been quite helpful in showing us how Arch has tackled reproducibility, and we have applied some lessons from that already to Alpine.
|
||
|
||
If you're interested in this project, feel free to join `#alpine-reproducible` on `irc.oftc.net`.
|
||
|
||
## secfixes-tracker
|
||
|
||
I am working on overhauling the JSON-LD documents which are presently generated by the `secfixes-tracker` application, so that they are more aligned with what the UVI vocabulary will look like. At the same time, the UVI group have largely endorsed the use of Google's new OSV format for use cases that do not require linked data.
|
||
|
||
Accordingly, I am writing a Python library which translates UVI to OSV and vice versa. This is possible to do without much issues because UVI is intended to be a superset of OSV.
|
||
|
||
However, we need to request two mime-types for OSV documents and UVI JSON-LD documents. In the meantime, the secfixes tracker will support querying with the `.osv+json` extension for querying our security tracker in the OSV format.
|
||
|
||
Anybody with experience requesting mime-types from IANA is encouraged to provide advice on how to do it most efficiently.
|
||
|
||
## Best practices for Alpine installations
|
||
|
||
A couple of weeks ago, a kerfuffle happened where Adoptium [planned to ship builds of OpenJDK with a third-party glibc package for Alpine](https://github.com/adoptium/containers/issues/1). Mixing libc on any system is a [bad idea and has not necessarily obvious security implications](https://ariadne.space/2021/08/26/there-is-no-such-thing-as-a-glibc-based-alpine-image/).
|
||
|
||
As one option intended to discourage the practice of mixing musl and glibc on the same system, I proposed installing a conflict with the `glibc` package as part of the `musl` packaging. We asked the Technical Steering Committee for guidance on this plan, and ultimately the TSC decided to solve this with documentation.
|
||
|
||
Therefore, I plan to work with the docs team to document practices to avoid (such as mixing libc implementations and release branches) to ensure Alpine systems remain secure and reliable.
|
||
|
||
## Distroless, for Alpine
|
||
|
||
Google's [Distroless project](https://github.com/GoogleContainerTools/distroless) provides tooling to allow users to build containers that include _only_ the runtime dependencies to support an application. This has some nice security advantages, because images have less components available to attack. There has been some interest in building the same thing for Alpine, so that users can take advantage of the `musl` C library, while also having the security advantages of distroless.
|
||
|
||
It turns out that `apk` is capable of easily building a tool like this. I already have a proof of concept, and I plan on expanding that into a more fully featured tool over the next week. I also plan to do a deep dive into how that tool works once the initial version is released.
|
||
|
||
## Acknowledgement
|
||
|
||
My activities relating to Alpine security work are presently sponsored by Google and the Linux Foundation. Without their support, I would not be able to work on security full time in Alpine, so thanks!
|