6.9 KiB
| title | date |
|---|---|
| Bits relating to Alpine security initiatives in August | 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, and last week, pushed a doas package which includes this patch with some migration scripts.
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. Mixing libc on any system is a bad idea and has not necessarily obvious security implications.
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 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!