Some geeky traditions did continue in 2020, including FOSDEM — the Free and Open Source Software Developers’ European Meeting. The special 20th-anniversary edition still went off as scheduled in Brussels in early February, giving the community’s developers a chance to hear from one another.
And last week the videos finally appeared online — including a talk by often-controversial systemd creator Lennart Poettering, “Let’s bring the UNIX concept of Home Directories into the 21st century.”
Speaking in the “Distributions devroom” track, the German software engineer (and Red Hat employee) made his case against our current system, where every new user account also requires a corresponding entry in etc/passwd — and telling us how systemd will start making it better.
“Home directories are so unspectacular in their nature, it wouldn’t usually cross anyone’s mind to even consider to change anything about them,” the technology blog Hackaday quipped a few months earlier. “And then there’s Lennart Poettering…”
With systemd-homed, Poettering “is aiming to unite all the separate configuration entities around user management into one centralized system, flexible enough to handle everything the future might require,” Hackaday summarized.
Since at least 2019 Poettering’s been talking up the systemd-homed project, described on its repository at GitHub as “a new component for systemd, that reworks how we do home directories on Linux, adds strong encryption that makes sense, supports automatic enumeration and hot-plugged home directories and more.”
During his talk, Poettering shared an even more ambitious vision. “I personally think we should go towards systems where etc/ is generally not writeable,” except when an actual reconfiguration is taking place. He argues that creating or updating users just shouldn’t be a configuration change.
Or, as his slide puts it, the current Unix architecture “mixes state and configuration.”
But there another basic downside of our current system. Each user’s unique user identifier number (or UID) has to be shared among all the systems (for controlling access). “We do all this infrastructure for propagating, but I think we shouldn’t… I think it would be way better if the UID would actually be an artifact of the local system.”
YubiKeys from Day One?
And then there’s the fact that there’s also no built-in encryption in home directories. “That is weird,” Poettering argues. Imagine booting up a laptop using full-disk encryption, supplying your decrypting password — and then being asked to supply another lesser password to access your account on the network. Poettering calls it the password “which actually doesn’t protect your data, which just does access control.”
“We should figure out how to encrypt the stuff — how to lock the stuff — to the actual credentials you want to lock them to.”
How would that work? While the system should be locked with its own asset management system, “Your data should be locked to something you control” — like your own private password or a hardware authentication device like YubiKey.
Poettering contrasts that with our world today, where “What you protect the data with is a system property, not a user property.”
And this leads to a larger criticism: the absence of “modern” authentication mechanisms. “By that I mean we live in a world now where YubiKey has become a thing, but everything is bound, still, to one single password in etc/passwd…” Even in a world with strong biometric security options like fingerprint-based Touch ID systems and even security based on facial recognition, “The inherent user database design of Unix is around passwords and nothing else…”
In fact, the last item on Poettering’s Goals list is “YubiKeys, from Day #1” — which he explains means not just YubiKeys, but also accommodating the whole universe of modern hardware authentication devices. “It’s not all passwords anymore,” he says. And he’d like to see a world where “We actually truly use them properly, not just for authentication, but also for the encryption part.”
This ultimately ties in another of his goals: unifying passwords with encryption keys. “If I can decrypt the home directory, this is the same thing, to me, as authentication. And authentication should always be: the ability to decrypt the home directory.”
Poettering argues the focus should be on human users (and not for the processes and accounts associated with daemons), and particularly the modern-day laptop user. But he also revisited one of his pet peeves: when a disk-encrypted system is suspended, the decryption key could still be held in memory. He’d ultimately like to see a fully self-contained “migratable” home directory — what he calls “home-on-a-stick.”
In this world you’re not just making a copy of your home directory on a USB stick; instead that portable storage medium becomes your home directory. “Meaning that you can plug it into this laptop today, log in and it just works. And then you can take it out and put it in another laptop tomorrow, log in there, and it all just works.”
One major advantage? “Security-paranoid people will love this, because it basically means you never leave actual payload data on the system when you’re logged out, because you just have it in your pocket, and take it to the other device.” And it also makes for easier transitions when you buy a new laptop. “The key of what I’m trying to design here really is very clear lifecycles — that you basically say, when you’re logged out, you’re logged out. When you’re logged in, you’re logged in. And while you’re logged in, the system will get access to the device, but when you’re logged out, it should not be possible to access your device.”
But how do we get there? Poettering ultimately spent some time describing one of the new and improved concepts that had recently been finalized in systemd. The availability of Linux Unified Key Setup (LUKS)-encrypted home directories in loop-back files could give encryption an obvious boost. (“[T]he encryption is directly coupled to the user login itself,” notes Hackaday, “meaning not only is the disk automatically decrypted once the user logs in, it is equally automatic encrypted again as soon as the user logs out, locks the screen, or suspends the device.”)
Jumping to JSON
One of Poettering’s other issues with our current system of user accounts is they’re not extensible. The data structure for passwords is still the same as it was in 1985, with the same six fields — user name, user ID, group ID, real name, home directory, and the login shell. So where, for example, does that leave SSH keys? Poettering points out that the authorized keys in your home directory end up in “sidecar databases” that extend the user record. Besides being messy, there’s also a risk that they’ll get out of sync.
So Poettering emphasized another recently finalized feature in systemd: the ability to write user records in JavaScript Object Notation (JSON) format, making them fully and easily extensible. Or, as systemd’s official web page explains, “systemd optionally processes user records that go beyond the classic UNIX (or glibc NSS) struct passwd.” Just one interesting possibility the documents suggest: Additional user metadata, like a picture, email address, location, timezone, or preferred language.
“You can denote lots and lots of different properties in systemd if you provide these JSON user records. We’ll actually do resource management for you, a couple of security things and other runtime parameters. But we can agree on some form of a more modern way of talking about users.”
systemd-homed service merged: It will change how you manage your home directories in Linux
* pull request https://t.co/7lvC85kBDY
* Why systemd-homed service needed? https://t.co/2LmIJmRpNT
* systemd-homed https://t.co/Av5gPBGvar
— The Best Linux Blog In the Unixverse (@nixcraft) February 11, 2020
From the audience, someone asked whether JSON user records had become a standard yet — and Poettering’s answer got a laugh. “Well… I’m not a standards organization. I mean, I kind of am, but also I’m not.” But then he pulls up the URLs where they’ve been defined at systemd.io, quipping “That’s where the standard is.”
“This specification is supposed to be a living specification,” notes the web page for user records. “If you need additional fields, please consider submitting them upstream for inclusion in this specification. If they are reasonably universally useful, it would be best to list them here.”
Or, as Poettering puts it at the end of his talk, “It’s extensible in that fashion where you’re not supposed to even talk to me if you want your own field. Just take it — just namespace it properly. I’m not interested in being this person in the middle who manages everybody’s fields. That’s, explicitly, not what I want. Just pick a field you want, namespace it properly by just using a name that’s unlikely to collide with everybody else’s, and then add whatever you like.
“It’s supposed to be distributed like Linux is.”
WebReduce
- The Air Force’s chief data officer discusses the U.S. Defense Department’s new data strategy.
- San Jose’s “Smart City” vision earns its recognition as America’s most innovative local government.
- “Space is waiting!” Japan’s astronaut Soichi Noguchi tells the next generation before blasting off on a Falcon 9 rocket.
- Home-buying during a pandemic: photos from drones and robot real estate brokers.
A company named Ori offers a robotically-transforming home. - BMW creates a flying electric wingsuit that goes 186 miles per hour.
