Kernel.org news: two-factor authentication and more

Kernel developers depend heavily on kernel.org for the hosting of Git repositories and the management of patch flow in general, so it is not surprising that the annual Kernel Summit sets aside a slot to discuss what is happening with this site. In recent years, there has been a lot of change to discuss, mostly relating to the reorganization of kernel.org management resulting from the compromise of the site in 2011. The 2014 kernel.org discussion, run by Konstantin Ryabitsev, shows that, in a lot of ways, the pace of change is slowing, but the kernel.org maintainers are still working to improve their support and make it more secure.

There are, Konstantin said, now 286 developer accounts on kernel.org — 34 more than one year ago. The number of Git trees hosted has grown considerably; there are now 604 repositories on the site, most of which are clones of the mainline kernel repository. The Git "alternate" mechanism is used to store these repositories, though, so there is only one copy of each distinct object on the site. That means that, despite hosting over 600 repositories, kernel.org only dedicates about 20GB of disk space to that task.

There is a new front-end system being installed in Montreal; full off-site backups will be performed to that system. Once that is in place, Konstantin said, the west coast of the United States could disappear entirely. "We'll miss you," but kernel.org will be able to recover and continue serving repositories.

Two other front-end systems are in operation now, one in Palo Alto (hosted by ISC) and one in Portland (hosted by the Tizen Association). Previous efforts to place front-end systems outside of North America seem to have fallen by the wayside for the time being; these systems are expensive to run and the sponsorship support just isn't there. The good news is that the problem has been somewhat "sidestepped" with the creation of a set of mirrors on kernel.googlesource.com. These servers are located all around the world and should only be a few minutes behind the main kernel.org servers. Developers wanting to clone trees can use this resource if kernel.org is too slow from their location.

Access in mainland China remains a bit problematic, though; the Google servers are not reachable from there. Konstantin said that the problem is being worked on, but he offered no thoughts on when a China-based server might become available.

Systems installed for kernel.org tend to be big, since they must support a planet full of developers. The recently installed "Si-Pi" system is an exception, though. It is a Raspberry-Pi-based system charged with the generation of SHA hashes for files stored on the site. This little machine is plugged directly into the main storage array and goes about its task without bothering the rest of the network.

Getting back to big systems, there is a new mirrors.kernel.org system going into service in the near future. The mirror network provides access to distributions and more; it needs a lot of space. The new box will feature 60TB of storage, a significant increase from the 16TB offered by the current system. There will be two mirror nodes, again hosted in Palo Alto and Portland. A European mirror is high on the list of things they would like to have, but the funding isn't there. These mirrors consume a lot of bandwidth, so it is hard to find a host willing to take one on.

Two-factor authentication

The biggest change at kernel.org this year, though, is arguably the addition of two-factor authentication for write access to repositories. The 2011 compromise almost certainly started with the acquisition of SSH keys from one or more developer laptops; it is important to be less exposed to that type of attack in the future. The removal of shell access has certainly helped in that regard, but an attacker with access to an SSH key could still corrupt a repository. Two-factor authentication aims to mitigate that risk.

The use of two-factor authentication is optional, at least for now, and can be enabled on a per-repository basis. It is not being forced on anybody, and there will be no flag day where it must be used. Only operations that change repositories are affected by two-factor authentication; repositories remain readable to all as always. Authentication via HOTP (as found in hardware tokens like the Yubikey devices) and TOTP (a time-based mechanism) is supported.

The kernel.org mechanism comes down to the whitelisting of IP addresses. Each repository can have a list of one or more user/address pairs that have been authenticated for write access. When a user attempts to push a repository update to kernel.org, the system will check to see if the originating address has been whitelisted already; if so, the update proceeds normally. Otherwise, the push will be rejected. The developer would then run a command like:

    ssh git.kernel.org 2fa val token

Where token is a magic one-time token provided by the authentication device. Assuming the token validates, the originating IP address will be whitelisted for the next 24 hours. Optionally, developers can ask for a longer whitelisting period up to 30 days.

Authentication is per-user; in cases where multiple users have access to the same repository, each must validate separately. There are two modes for the enabling of two-factor authentication on a repository; the "opt-in" mode only enforces two-factor authentication for users who are enrolled, while the "required" mode requires all users to be enrolled.

For developers who want to use TOTP, there are a few options available. The proprietary Google Authenticator system is supported, as is Authy. The best option, though, according to Konstantin, is FreeOTP, which was forked from Google Authenticator before it went proprietary. In the end, though, most developers may opt for hardware-based authentication instead. To help in that regard, Konstantin was passing out Yubikey devices from a bag donated by Yubico.

Linus Torvalds and Greg Kroah-Hartman, it seems, have been using two-factor authentication for about a month without any serious ill effects. With a couple of the toughest customers already satisfied, chances are that the new two-factor authentication mechanism will catch on without much in the way of major hitches. And that, in turn, should help to improve the security of kernel.org and boost confidence in the security of the kernel code base going forward.

Index entries for this article
Kernel	Development tools/Infrastructure
Kernel	Kernel.org
Conference	Kernel Summit/2014

---

to post comments