Reinventing Home Directories
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Poettering, Lennart
Let's bring the UNIX concept of Home Directories into the 21st century. The concept of home directories on Linux/UNIX has little changed in the last 39 years. It's time to have a closer look, and bring them up to today's standards, regarding encryption, storage, authentication, user records, and more. In this talk we'll talk about "systemd-homed", 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.
 Hi, I'm Leonard Pottering and I'm going to take away your home directories now. I'm a bit sick, so I hope I'm not going to lose my voice in the middle of this talk. But yeah, I'm talking about something that has not been versioned to system yet, but hopefully will. It's about reinventing home directories as the title says, because I mean reinvention is what we do with system era. Anyway, I think I have good reasons for this stuff and I hope to explain why and I hope to also explain what precisely I've in mind that we do. So what am I talking about? I'm talking really about your home directories, right, dollar home or Tilda, whatever you want to call it. It's that stuff that is paired with an entry net C past WOD and makes up your user record and your user data set, if you so will. Like after working with Linux and Unix for a long time, I came to see quite a few problems with the approach we so far had. I'm pretty sure everyone of you knows how this works, right, like Unix with Etsy past WOD and home some directory, right? I don't need to repeat how that works, right? I saw a couple of problems with this. First of all, the way we currently manage user directories in Linux is basically it requires a writable Etsy to create a user, right? So far, we always have this goal that if a system's configuration not supposed to change, Etsy should be immutable ideally even and hence the requirement that if a user is created or removed or modified or whatever, you need a writable Etsy kind of sucks because a user's existence is not really configuration, at least in my view, right? So the concept that MixerState, I believe that the user record is state, it's not configuration, and the rest in Etsy is generally understood to be configuration. There's this semantical, this philosophical problem already that Etsy MixerState in configuration and then this propagates into the problem that Etsy needs to be writable. There's also this problem with Etsy past WOD and home management that user ID assignments on Unix need to be propagated between systems, right? There is a lot of infrastructure in this world for LDAP databases, how user records are distributed among many systems, how NFS has user ID translation, demos and whatnot because everything is bound to user IDs like numeric, Unix user IDs like these 32-bit values where zero means root. And the meanings of those in context of Unix network file systems always need to be propagated between systems. And that to me sounds so backward because it basically means that every system you have only exists within a very specific institution like organization because only within that very specific institution and organization you can say that user lennard has numeric user ID 555556 or something, right? So yeah, I think the classic model worked as long as you had few systems, right? And as soon as people tried to scale it to more systems they came up with this massive complexity that is LDAP and things like that and they end up managing this user ID that nobody actually really cares about which is just an artifact of the implementation and there's nothing something people should really care about. And in a world of today where we scale to the internet, user IDs are complete an artifact of the 1970s. Like if I have a Google account or Facebook account or whatever account on the internet there's no user ID assigned to it because it makes no sense. Nobody wants that, right? I mean there are reasons why user accounts have user names, there are reasons why they have passwords but the reasons for them having a numeric user ID on a specific system are a little bit weird. So yeah, I see that as a problem. There's another problem. This model means the way we deploy it right now, no encryption, right? Home is generally not encrypted by anything that is directly related to the user, right? Slash home, like you might have full disk encryption, right? You might have encryption of slash home as a whole, right? But this is system wide, if you say well. It's not specific to the user and that's weird, right? Like because right now, like at least on my laptop, the way I installed it in Fedora like a couple of years ago, I got the full disk encryption so I boot up, I type in a password, that is my password but also it's not my password because it's actually my laptop's password, right? Then I authenticate against my system, that decrypts the hard disk. Now this is the password that actually matters, right? Like after it booted up, I have to reauthenticate a second time into my actual user account and that password doesn't really matter that much because at that point, all the data of the home directory is already fully available to anything on the system that ever wants to see this. So I see there is this really weird discrepancy, like this mismatching encryption that we protect, like the stuff that's actually associated with user account is not what protects your data. It's the other stuff that protects your data that is system wide that if we actually had multiple user systems, like where multiple users use the same machine, where they would have to share that password, that makes no sense. The only way why we so far got away with this is because most laptops are single user systems effectively even though Unix concept can support more, right? So I think this is like, this stems from, yeah, nobody wanted to touch the way how Unix user management worked and so we came to the discrepancy and we got away with it because we effectively are single user systems. I also see the problem, yeah, Etsy, PassWD only knows Unix passwords, right? Password, as you know them, it doesn't know anything else, right? Everything else how you might want to authenticate these days, UB keys, whatever else, cannot be an Etsy PassWD because it's not extensible, right? So anything more modern, anything, if you even want to authenticate with a pattern, right, like which is what phones do and which you might want to do in your laptop too if you have a touchscreen, doesn't really fit into that model because, yeah, there's no way how that's available there. It's not extensible, this is actually a massive problem, right? Like Etsy PassWD, this database was designed in 1985 or something like this, has not been modified once since then. There has been this extension like the shadow database which added like five more fields or something like this, but everybody wants to add their own fields. And this is like fucking ugly if you ask me because they created these site card databases, right? These databases that extend the user record but they're not actually stored in Etsy PassWD in the user database itself but at some other place. And that other place means something very different regarding where you're looking. So for example, Etsy Shadow was the first site card database that was introduced and it contains information about the actual password used and like account, like validity restrictions, things like that. But then accounts demo is like this good own thing, they wanted to add a picture for each user so they have a site card database for that and a couple of other things. Samba has one because they wanted to have a GUID like in Windows context. They created their own one, it's also somewhere in VAR, there's SSH which wanted to have the authentication key, right, like the authorized keys thing in your home directory, right, which is part of the user identity, it's how you authenticate, it's like your password in many ways. But no, we can't put it in the password file because it's not extensible so we put it in the home directory and then SSH tries to read from that and it's highly problematic because you have a privileged demo that goes into the unproved user directory and it's dangerous as shit. So then we have PAM limits which is about resource management, right, like people want to be able to set limits on specific users, they want to make sure that some users can have more presence than others. The way they do it is they came up with their own configuration file which is not even a database but a configuration file in Etsy security limits.contra something like this. So yeah, we ended up with this, yeah, simply because it's not extensible, we ended up with a distributed thing that you can't even manage centrally, like even if you use LDAP and try to manage centrally, it usually covers like a fraction of this, usually the Unix records and maybe the shadow stuff but then as soon as you go into sharing pictures of users with LDAP, that's strange territory. Yeah, this is kind of the same thing, there's no resource management, doable was Etsy past WD and I think resource management matters a lot, right, because not all users are equal. So you want to be able to assign specific resources, memory, disk space, whatever else to users and yeah, Etsy past WD can't explain this. Then they create another secondary database for this which is a quota database on disk but yeah, so resource management is as soon as you think about multiple users, you also want to think about the differences between multiple users and how many resources you assign to each. But we can't really do this with Etsy past WD except through this mess of sidecar databases. So this is, yeah, so far like a number of the problem, they think there are a lot more, this is kind of the problems that I saw that I wanted to fix with what I'm talking about here. So, let's talk a little bit about the focus of what I'm suggesting here. First of all, it's only about human users, right, I don't care about system users in this context, right, like system users being the stuff that demons run under, this is about human users like me and you, right, that the stuff that you have on a laptop, it's not the stuff that you have on a server so much. The goals that I want to be able to deliver with what I'm talking about here is first of all, migratable home directories, right. Migratable home directories means that you can take a home directory as one unit from this laptop to your new laptop or to your third laptop and it will always work and be self consistent in itself and comprehensive and hence migratable, right, so this basically means that as little as necessary should leak into the system surrounding it and particularly when it comes to configuration, which is very different from what was there before, right, like before home directories user accounts were not migratable, right, like because as mentioned we have all these sidecar databases and there's no way you can sensibly migrate all that metadata that is distributed in all these configuration files and etsy and all the weird sidecar databases and var and what not from one system to another. I want to go to this way where home directories are, yeah, somebody didn't turn off his phone. I wanted to go, I want this to go to the way where they're truly migratable, right, like all the way to the point where you have a USB stick like this one and that this can be a home directory and you plug it into my laptop and it can work there and it can take it out and put it into another laptop and it can work there, but this USB stick actually is my user account, that it is my home directory and it's truly and natively migratable without any magic bullshit of propagating configuration into the system, right, so it's about isolation, it's about unification, everything into the home directory itself and cleaning this up. I already mentioned this a bit, it's about self-contained home directories, right, so right now as mentioned if you want to have a user account you have files everywhere, you have files in etsy, you have an entry in etsy shadow, you probably also have an entry in etsy group and etsy gshadow, you have the home directory itself, you have all the sidecar databases. The goal with this is, yeah, self-contained home directories, that everything that is on the stick comprehensively describes the home directory, by the way I'm putting this stick here always in your face but it's not supposed to be just about the stick, right, like the fact that we can have home directors on the stick is kind of a nice side effect of what I'm doing, but my main focus is actually not that, I want, most people probably want to have the home directory on the laptop, I know this and that's what I want myself, I just want to make the point that it should be that migratable that you can have it on the stick and it kind of makes sense. So yeah, self-contained home directories, right, the metadata about the user should not be distributed across the system with all its information about the user itself, with all the resource management and stuff, it should be part of the home directory itself. This then means that the mere existence of the home directories file where everything stored should synthesize the user account in full, right, it should make sure that if you call get pw.nam or something like this, like the classic Unix APIs to query user, the mere existence of the user file store should synthesize everything else, right. In a way you could say I want that, yeah, you know Unix, everything's a file, that yeah, users should be a file too, right, like where you just have one concept in the file system and that everything else comes from there during runtime and is not propagated persistently anywhere else. One of the goals that I also have is UID assignments should be a local artifact, right. I want that if I stick this USB stick into this laptop that I might get a UID, stick it to another one and that UID is already used by another account there, they get a different one and it shouldn't matter, right. This is a hard problem. We have to cut some corners to implement this, but yeah, I want that it is a local artifact. It's like when this home directory is bound to this specific laptop, it gets a user ID assigned and that's how it is, but if it's bound to a different laptop as well, it might get a different one there so that the propagation of the actual UID numeric value is not necessary and all this infrastructure having centralized databases like LDAP and stuff to stabilize this are not necessary. I also wanted a unification of the user password and encryption key, right. This is what I already mentioned earlier. So far, we had the encrypted password and NC Shadow, right, like this Unix password string, $1, $6 or something and we have usually the hardest encryption like the Luxe password. I don't want this to be two different things. I want this to be the same thing, right, like if you're capable of decrypting a home directory, that's good enough as authentication that you're also allowed to and also the reverse should be true, right, that if you're allowed to lock in, only then there should be any chance for you to access the home directory. So yeah, I want these two concepts to just be merged and be the same thing. Also, this is really important, we should have like in 2019, extensible user records, right, like so that people can put in these user records whatever they want, right, and we propagate that through our APIs to have a wants to know this. And yeah, so that we are not stuck to struct pass WD, right, this five field structure defined in 1985 or something, but people can stick in there whatever they want, like if they have some weird requirement for their own company, they can put something there. And if other people have different requirements, they can put something else there. But we agree on a common basic vocabulary, but are highly extensible. Also, one of my really important goal actually is to lock Luxe on system suspend. So nowadays, I'm pretty sure that first of all, most of you probably use hottest encryption on your laptop. And second of all, I think most of you probably don't even turn off the computers anymore at all, right, like usually just close the screen and that suspense the system. And then when you come back, you just authenticate again. But it systematically, I mean, it kind of defeats the encryption, like the encryption that you have there, because basically the way it's currently implemented, you use hard disk, like full disk encryption. So while the system is up suspended or running, we are up in that context, the decryption key is a memory. So if I go through customs to a country that I don't trust and I have the laptop with me and it's suspended and they pick up the laptop, in that memory, you'll find the decryption key from a hard disk. And that's something I think we should not do, right? We should. And this is something that people might not find important, but I think it's actually one of the most important things in this entire approach at all, is, yeah, when you suspend the system, the decryption keys need to be removed from memory, right? So that I know for sure that if somebody steals my laptop in suspended state, because that is the most common state that they will probably steal my laptop in, they should not be capable of getting any access to my hard disks, right? Again, this is something you really, really should care about, because it basically so far defeated all kind of encryption that you had, because as long as you did system suspend and everybody does that, if somebody steals the laptop, they can get extract everything they want. So doing this is actually much harder than it sounds at first, because the reason why we're not doing this on general systems right now is because, yeah, if you use full disk encryption, then the operating system itself is encrypted, right? So if you come back, like if you actually flash out the cryptographic keys when you go down for suspend, and then you need to require them from the suspend, who's going to ask the question if it can't even be loaded into memory because it itself resides on that encrypted partition that you want the password for, right? So there's a bit of a chicken act problem and nobody solves this so far. With this, I want to solve this, right? So that when I suspend my machine, the operating system itself is independent of the individual home directory, so that we can suspend the home directories independently of the system itself and hence solve the problem. Also, I kind of indicated this already. I think we need to move to more modern ways of authenticating yourself to the system. Password's great, but also maybe we should do something better. So, yeah, one thing I want to be able to deliver from day one of this system to home, this thing is UB key support, right? I mean, UB key, I put in the sense of like how you would use the word Google for search engine, right? It's not just about UB keys. It's about anything that is like a like authentication token that implements PKCS 11, right? And I think we should do it properly, meaning that we actually use the cryptographic properties that a UB key provides and hence, yeah, if you don't have the UB key that there's no way in the world, the cryptographic key for unlocking your account and for accessing the encrypted data on disk can even be retrieved. So, that's the goal, the goals that I have. There's some complications with all of this. SSH logins, right? I mentioned that I wanted that user authentication and decryption of the hard disk is the same thing, right? This is inherently incompatible with how SSH traditionally works, right? Like, because as mentioned, if you authenticate via SSH, it goes via the authorized keys file in the home directory. So, if you want to authenticate something that is inside of the home directory so that you can access the home directory, where does the decryption key come from to access the home directory, right? You follow what I mean? It's there's a chicken neck problem. You're reading out the key that allows you access from the encrypted thing which you only can after you authenticate it, right? So, my answer to that is we don't allow SSH logins as long as you have not locked in first locally. Because, I mean, allowing SSH logins the way that they're traditionally done means that inherently the home directory of the user needs to be accessible before the user locks in. And I think that's something I really don't want to have, right? I really want that when I'm locked out here, that not me, but not also anything else in the system can even access my home directory. That includes open SSH to read the keys from that. So, yeah, my answer to this is SSH logins into systems that use this can only be done after I logged in locally, which decrypts the hard disk, makes it accessible, and then SSH can access everything. Also, by the way, actually the authorized keys file is something I think we already implemented even, should be part of the user record, like the successful user record, so that you can actually, yeah, it's just there. And, yeah, this already actually works. This space assignments are a bit of a problem, right? We probably should come back to this one later a little bit when I talked about how the storage of what I'm doing is actually done. Another problem is UID assignments. I kind of already indicated that. So, the problem is if we want the UID to be specifically local to the system, right, it might happen because the range of user ID is very small, like it's just 32-bit, that there will be collisions, right? Like that if I have my home directory on this laptop and then take out the USB stick, put in another laptop that somebody else might have already used the UID that I used here, yeah, this is very likely because the space is so small. Ideally, the kernel would help us with this, right? Because we had something like ShiftFS, so that it doesn't matter what's actually on disk, that as the moment where I log in, I get assigned the UID and then I mount virtually all the files to the right UID. We can't do this, so we go for the next best thing, which is churning recursively if we have to and try to avoid really hard having to do this if we can. Thankfully, churning recursively surprisingly fast, actually, if we actually have to do this. And I'm kind of okay with the behavior of this because, I mean, we tried very hard to make the UID assignments stable. So, for example, we hash it from the username, but that's never going to be enough because the name space is so small. But this basically means that probably in real life, if it's just Leonard and I have like three machines and I take this one out and move between them, I will probably never need the churning. But it's there to make this safe. And ideally, sooner or later, we don't have to do the churning anymore. Yeah, looks locking. I already mentioned that this is kind of complicated, but there's also a couple of other complications. If we do the looks locking on suspend, right, where we remove the cryptographic keys from memory as we go into suspend mode, we need something that queries for the password again when the machine resumes because until that happens, the home directories are locked completely locked and cannot be accessed because there's no cryptographic key known for them. So, we actually need cooperation for this from the UI, like everything else that I'm doing here I can do without any UI involvement. But in this case, we need some cooperation from the UI, specifically meaning that when the system comes back from looks, your display manager, like GDM, whatever you use, will have to re-assenticate the user because, I mean, mostly, effectively, they already do this, but they do it the wrong way right now because mostly the way that they do it is that the screen lock that is turned on on suspend actually runs under the user identity of the user itself. This doesn't work if we suspended the home directory of the user because we can't run code until, under the user's own identity until the home directories resumed again. So, what we need here is that GDM, for example, is patched that when the system comes back from resumed, it asks the password again so that we can unlock the home directory and then can switch back to the user's login session. So, I know this is a lot of material so far. Let's now actually have a look at the actual stuff I did on the actual code concepts. Yeah. There are two new concepts. One of them is I want to go for JSON user records. I think we should just start using that for our user records. Yeah. The reason why JSON is because it's just the most basic thing. It's supposed to be machine readable. It's not supposed to be something you write. It's something computers write for you and things like that. And it's also what probably most of the internet-facing user databases probably use anyway when they exchange information about users across the network. So, that's the first thing. JSON user records. It's supposed to be a superset of the NSS. NSS is a name service which of Glipsy. It's like a generic term. Glipsy uses for struct past WD instruct group, which for the ones who don't know Unix so much, that's how user records are done by Lipsy since then 1985. These JSON user records are supposed to be queryable via varling interface. Varling for those who don't know is a very simple IPC system. It's just used JSON and it's supposed to be the most trivial IPC in the world so that as long as you have your own JSON parser, you don't actually need any kind of other code base. I have a slide later why varling is the right answer here and not deburse. There are good reasons for this. So, yeah. The idea is also that from these JSON user records that are queryable via varling interface, we can convert forth and back between this and the classic ones. In one direction, of course, it's lossy, right? Like because JSON stuff can have any kind of metadata, while struct past WD instruct group cannot. How does this specifically look like? This is an example. Now, if I had a laser pointer, I could show you. I think some of them, this is pretty much self-explanatory, right? Like username, you guessed it, is username. This position is just, yeah, ignore that. But nice level, for example, configures that when this user called Groby logs in that all his processes get nice level five, right? It's pretty self-explanatory. Member off means, yeah, this user is supposed to be member of the group wheel, I think, yeah. What's interesting here is the binding thing. Binding is supposed to bind a specific user record onto a specific system. The reason why this is a sub-object and not part of the main thing is simply because depending on specific systems, resource management is probably going to be different, right? Like if I have a user record for Leonard on my desktop, my super beefy desktop, and I want to put a size limit on it, it should be specific to that desktop because it has so much more memory than my laptop might have, right? So the binding concept here basically, you see the hack string, that's actually the Etsy machine ID. Basically it just says, yeah, the following properties apply only if this is bound to a specific system. And then, yeah, GID is the, GID, UID is the UID. What do you see? Else there is like meta information about how the actual storage is done. We'll talk about this a little bit later. This continues. Privileged is a special section that contains a privilege information. It's basically what Etsy shadow is. The reason why it's a sub-object is so that we can strip it if somebody is not supposed to see it, right? So the idea basically is that all the information that is an Etsy shadow traditionally, plus all the new stuff that people want to come up with, should be in a specific sub-object so that whenever somebody who shouldn't see this information wants to see the record, we can automatically remove it. Anyway, I don't want to go too much detail about the structure of these records. There's documentation plenty about this. What's also interesting is you can sign these. We'll talk about this later, why that's interesting. So that was concept A. Extensible, JSON, user records, plus an API, how to query them, kind of replacing, get PWN, but also compatible. Concept B is I want that home directories are encrypted lux loopback files in slash home, right? So that, you know, if I have a user called foobar in slash home, traditionally there was slash home slash foobar and was a plain directory. I want that there now is slash home slash foobar dot home and it's a file and it's actually a lux loopback image and then when the user logs in, what do we do? We set it up via lux stuff as a loopback file and then we finally mount it after validating that everything's okay. These extensible user records are supposed to be stored inside of that image inside of file.identity. That's nothing magic about that. This stuff is supposed to be managed by a tiny diamond and it's actually not, it's really small because it doesn't do much. That is called system.homedi.service. What does that thing do? It's okay, I have not much time left. There's so much more awesome stuff in this, but let me finish this quickly. So system.homedi is what it actually does is it just, the thing that sets up these home directories as you log in. It also provides NSS interfaces so that the old APIs all work so that you can get to end on the shell, for example, to get the user database and find then automatically all these user records and everything works. This concept B, like these encrypted lux stuff, can be used, it relies on concept A, but concept A you can actually use without it. So if you just care about the extensible user records, that's totally fine and you should by the way because even if you have to eld up on these more classic user databases, you might want to be able to hook up, hook into system.homedi resource management because all this new stuff is hooked into system.homedi's user management. For example, there's PAM system.D that has been around for a while, but what it does actually takes the JSON record, pulls all the resource control that makes sense from the nice level as you have already seen the classic resource limit but also environment variables and that kind of stuff and sets it for all the pros that log in. There is also support and system.D log in at service which kind of does the same thing when you log in, but it applies it to the C group stuff, so that it applies to the user as a whole. So if you are into eld up and provide these extensible user records, just by doing that, you get this integration to get all the fancy resource management you ever dreamt of. So I think this, I kind of already explained this. I care about encrypted home directories and loopback files. I care about encrypted home directories on block devices like this USB stick for example, so that we have something truly migratable there. While this is what I tell people I'm going for, like encrypted lock stuff, actually the system.homedi component does not just support that as a backend, it actually has four backend like classic plain directories for compatibility, but are SAP volumes, FS, crypts, SIFs and looks. But again, looks that backend is the one I want to push towards, people's towards, because it's the only thing that's actually fully secure because not just the payload of the user but also the metadata is encrypted and it's fully featured in all these kind of things, industry standard and stuff like that. This is after all an exercise and not coming up too much new stuff but just taking what's already there and that is looks for example and just sticking up in a more nicer way. But anyway, my time's over. I'm fully aware that I totally did not finish all the beautiful slides I have there. These slides have been online for a while, but I probably should take some questions at least. Yeah, somebody has a question there. Can you read that? There's a mic. Thanks. In the user, the JSON structure, there was a list of groups for the user. That needs to be somehow verified by the system. How do you approach that? Because user can change whatever groups he is and then it will automatically gain access on whatever systems they look in. The explanation isn't this thing, the signature. Basically, the user records are supposed to be changeable by only privileged like the administrator or whoever manages user record and then you're supposed to sign them and each system will only accept the user records that are signed by the right people where the signature can be verified and the key is known for this. This is actually, it's not an option. At least if you manage stuff with system to home, it will insist that everything is signed. We live in a world where cryptography is everything. This stuff will refuse allowing you to log in on a random use B stick. It will only allow you to log in with random use B sticks that have a user record on it that is signed by some key that is recognized by your specific laptop and you can recognize as many as you want. You can change that file as much as you want, but if you do, you just lock yourself out because you can't sign it because you don't know the private key being used. Yes, so the question was whether you need privileges to change the SSH key of your own user account. Yes, you do. It's the same way as it always was for changing your password. That also requires privileges. This is hidden from you usually by suing suede and it's the same way we can hide through policy kit. But yes, there's no way that your code pass that run until your user identity makes these changes and I'm pretty sure that's how it should be. If there is desire to allow on-privileged users to change some artifacts of the user records, it always needs to go through privileged component that's policy kit, whatever else to allow this. So if I got you correctly, you said before that you need to log in first in your account before being able to do an SSH login to that. Let's say I'm a university student and I have an account on the university lab and I'm at home and I want to access my account on the university lab computer, but of course the system was rebooted overnight so I cannot travel 200 kilometers. How would we handle that use case? Would it be possible for instance to store the SSH key as a looks key and to change up an SSH to unlock my home folder? I mean SSH doesn't deal in passwords, right? It gives you a challenge and you're supposed to respond to that. And if that kind of stuff means that the only way you can do things is the other side you're syndicating against is an active program, right? That's not how looks works. Looks, you authenticate against a disk image, right? So this is inherently incompatible. You cannot use like at least I don't see how you could use SSH authentication to decrypt a home directory that is semantically incompatible. So my answer to this is if you really want that this system can come up on its own and decrypt your data, don't use this stuff. This is about security. This is not about giving up any kind of access to your data. This is about supposed to protect the system, to protect your data from the system as much as possible so that when you're not locked in, it's really cut off and like mathematically cut off. And regarding to SSH, what about having like SSHFS reverse as your local home folder you already decrypted and opened is used over there and then the credentials inside of that is somehow unlocking over there the homes. You know what I mean? Yeah, I mean, this of course always works, right? Like, I mean, yeah, if you, so, you know, for the UB key support, right? Like, I'm not sure if you know, UB key stuff, like this is generally accepted API for accessing security tokens. It's called PKCS 11. And there is a project inside of Red Hat. And that's actually, I think, including Fedora and everything which allows you to propagate PKCS 11 devices across the network through SSH, for example, right? And with that kind of stuff, you can make all the security, like the encryption keys and all that stuff that is available locally, also viable on a remote system to do that kind of propagation. I was interested in this because I wanted to make it possible. Like, I have a UB key in this device and I would ideally would like to just use that to authenticate through SSH onto another system that runs system be home D and so that, yeah, the crypto key is sanely encrypted through that. So there are certainly things possible there, right? Through this PKCS 11 forwarding. I'm not sure how realistic that is in the short term, but I'm kind of, yeah, well, let's see how that works. But again, I mean, the other way, right, that we were just talking about like logging over SSH into my laptop, I'm not so sure that's that much of a common case because my laptop is a client. It's not a server, right? Like you usually lock from it into other systems. You usually don't lock so much into your laptop from from from the outside. It's like philosophically, yeah. Sorry, having Oh, on the other system, I mean, sure. Yeah, I mean, there's the solutions like I mean, one thing that is actually kind of nice is like, you could even share these locks files via NBD. And then they show up on other systems. And then they, if you can log in there and we'll just work because yeah, use B stick is not very different from from NBD or something like that. But that's out of focus for everything. I mean, my main focus really, I want my own laptop is finally secure that I can suspend about this. I mean, this is kind of like the this is a summary after all, right? I want these problems to be solved finally because we never could solve them. And I want to solve for my own machine because I care about the security and these kind of things. Right? So if you remove the lux encryption key on suspend, does that mean that you have to log out? So all processes terminated? No. And then follow up question. If the process are not terminated, there might still be some private data in the memory and running applications, right? Sure. Okay. So yeah, I mean, there's data and there's data. There's crypto keys. And there's your private data. Yes. If like, I mean, if I would, if I steal your laptop and try to extract the memory, the first thing I'm looking for is having the crypto keys. That's the one we definitely should kick out. People using crypto swap and these kind of things. I don't know, maybe we should, there's something more to solve there so that as much as possible, the kernel flushes out all the memory onto disk into swap or something and then it's encrypted and stuff like that. But that's outside of my area of expertise and what I can solve. I just want to solve like the really obvious stuff. Yeah. But anyway, when the system goes down, we will suspend the lux device and that does, that basically means that any process accessing it at the time will hang while it does that until we resume it again. This is, this sounds ugly and is ugly, but also it's not much of a problem because we go down anyway into system suspend. There's not going to be any process that might hang because the CPU holds it anyway. So yeah. So if I want to have my home directory migratable, but also as a backup, let's say I back this up to a separate disk, then I also need to back up the signing key of the signature file, identity file, the key that was used to sign as I can look back into the system if I have to restore it. I mean, this stuff, it doesn't, ultimately it's just a lux file system. You can use the classic lux, like crypt it up to look into this and do whatever you want. Lux of course has no understanding of user records or signed user records. For backup, it really doesn't matter that you retain the original signing key there. The signing keys controls who can log in. It does not control who can access the data if he knows the password, right? So for backup, it's totally sufficient to just take that one file and back that up. By the way, it's, I mean, this is something people should never forget, right? Because this says that the user record and the home directory all become one file, you can just take that file from one laptop to another laptop and you don't need to do anything at all anymore. It just pops up there and is there. And for the backup case, I think it would even make a ton of sense that if the backing file system of the show is something like XFS or BrutterFest or something, you can do a raffling copy every day of something, of that one file and there you go. You have perfect time machine kind of stuff. I mean, this opens up really nice possibilities as soon as we unify everything into one file. Because yeah, in Unix, most things are focused on one file. Anyway, I think my time is mostly over, but maybe one more question there. Okay. How do you plan to deal with different distributions and versions of distributions because we have different versions of software and even if you use common home directory, it would be not working. Well, this... So, I mean, system.ly.home is a part of system.ly. That's kind of the goal, right? And unless people patch around this heavily in the distributions, hopefully it's kind of going to be the same thing in all the distributions. All the stuff that I'm explaining here is not supposed to replace or modify the existing users that you might have, right? This is an add-on, right? So that if you have a home directory like this, great. It will show up in your user database and everything's great and because it's in this version, it's going to be compatible. But if you're talking about the software that is inside the home directory, people kind of solve this because NFS shared home directories always work like this already, right? And it's a mess and I don't care so much. It's a problem I'm not going to solve for you, right? I'm not going to make sure that every version of Emacs packaged by any version of any distribution can read the same configuration files. That's something other people have to solve. I at least want to make it possible that the home directories are truly migratable and, yeah, how migratable they are between the distributions, that's not my problem to solve. The lower levels, they will be perfectly migratable because, I mean, Lux, if I compile a, if I format a volume on Fedora and then run it on sues, it just works. They did not break compatibility and since this is really just Lux, yeah. Any very last question or are we done? If you...
 Hi, I'm Leonard Pottering and I'm going to take away your home directories now.  I'm a bit sick, so I hope I'm not going to lose my voice in the middle of this talk.  But yeah, I'm talking about something that has not been versioned to system yet, but  hopefully will. It's about reinventing home directories as the title says, because I mean  reinvention is what we do with system era. Anyway, I think I have good reasons for this  stuff and I hope to explain why and I hope to also explain what precisely I've in mind  that we do. So what am I talking about? I'm talking really about your home directories,  right, dollar home or Tilda, whatever you want to call it. It's that stuff that is paired  with an entry net C past WOD and makes up your user record and your user data set, if  you so will. Like after working with Linux and Unix for a long time, I came to see quite  a few problems with the approach we so far had. I'm pretty sure everyone of you knows  how this works, right, like Unix with Etsy past WOD and home some directory, right? I  don't need to repeat how that works, right? I saw a couple of problems with this. First  of all, the way we currently manage user directories in Linux is basically it requires a writable  Etsy to create a user, right? So far, we always have this goal that if a system's configuration  not supposed to change, Etsy should be immutable ideally even and hence the requirement that  if a user is created or removed or modified or whatever, you need a writable Etsy kind  of sucks because a user's existence is not really configuration, at least in my view,  right? So the concept that MixerState, I believe that the user record is state, it's not configuration,  and the rest in Etsy is generally understood to be configuration. There's this semantical,  this philosophical problem already that Etsy MixerState in configuration and then this  propagates into the problem that Etsy needs to be writable. There's also this problem  with Etsy past WOD and home management that user ID assignments on Unix need to be propagated  between systems, right? There is a lot of infrastructure in this world for LDAP databases,  how user records are distributed among many systems, how NFS has user ID translation,  demos and whatnot because everything is bound to user IDs like numeric, Unix user IDs like  these 32-bit values where zero means root. And the meanings of those in context of Unix  network file systems always need to be propagated between systems. And that to me sounds so  backward because it basically means that every system you have only exists within a very  specific institution like organization because only within that very specific institution  and organization you can say that user lennard has numeric user ID 555556 or something, right?  So yeah, I think the classic model worked as long as you had few systems, right? And  as soon as people tried to scale it to more systems they came up with this massive complexity  that is LDAP and things like that and they end up managing this user ID that nobody actually  really cares about which is just an artifact of the implementation and there's nothing  something people should really care about. And in a world of today where we scale to  the internet, user IDs are complete an artifact of the 1970s. Like if I have a Google account  or Facebook account or whatever account on the internet there's no user ID assigned to  it because it makes no sense. Nobody wants that, right? I mean there are reasons why  user accounts have user names, there are reasons why they have passwords but the reasons for  them having a numeric user ID on a specific system are a little bit weird. So yeah, I see  that as a problem. There's another problem. This model means the way we deploy it right  now, no encryption, right? Home is generally not encrypted by anything that is directly  related to the user, right? Slash home, like you might have full disk encryption, right?  You might have encryption of slash home as a whole, right? But this is system wide, if  you say well. It's not specific to the user and that's weird, right? Like because right  now, like at least on my laptop, the way I installed it in Fedora like a couple of years  ago, I got the full disk encryption so I boot up, I type in a password, that is my password  but also it's not my password because it's actually my laptop's password, right? Then  I authenticate against my system, that decrypts the hard disk. Now this is the password that  actually matters, right? Like after it booted up, I have to reauthenticate a second time  into my actual user account and that password doesn't really matter that much because at  that point, all the data of the home directory is already fully available to anything on  the system that ever wants to see this. So I see there is this really weird discrepancy,  like this mismatching encryption that we protect, like the stuff that's actually associated  with user account is not what protects your data. It's the other stuff that protects your  data that is system wide that if we actually had multiple user systems, like where multiple  users use the same machine, where they would have to share that password, that makes no  sense. The only way why we so far got away with this is because most laptops are single  user systems effectively even though Unix concept can support more, right? So I think  this is like, this stems from, yeah, nobody wanted to touch the way how Unix user management  worked and so we came to the discrepancy and we got away with it because we effectively  are single user systems. I also see the problem, yeah, Etsy, PassWD only knows Unix passwords,  right? Password, as you know them, it doesn't know anything else, right? Everything else  how you might want to authenticate these days, UB keys, whatever else, cannot be an Etsy  PassWD because it's not extensible, right? So anything more modern, anything, if you  even want to authenticate with a pattern, right, like which is what phones do and which  you might want to do in your laptop too if you have a touchscreen, doesn't really fit  into that model because, yeah, there's no way how that's available there. It's not extensible,  this is actually a massive problem, right? Like Etsy PassWD, this database was designed  in 1985 or something like this, has not been modified once since then. There has been this  extension like the shadow database which added like five more fields or something like this,  but everybody wants to add their own fields. And this is like fucking ugly if you ask me  because they created these site card databases, right? These databases that extend the user  record but they're not actually stored in Etsy PassWD in the user database itself but  at some other place. And that other place means something very different regarding where  you're looking. So for example, Etsy Shadow was the first site card database that was  introduced and it contains information about the actual password used and like account,  like validity restrictions, things like that. But then accounts demo is like this good own  thing, they wanted to add a picture for each user so they have a site card database for  that and a couple of other things. Samba has one because they wanted to have a GUID like  in Windows context. They created their own one, it's also somewhere in VAR, there's SSH  which wanted to have the authentication key, right, like the authorized keys thing in your  home directory, right, which is part of the user identity, it's how you authenticate,  it's like your password in many ways. But no, we can't put it in the password file because  it's not extensible so we put it in the home directory and then SSH tries to read from  that and it's highly problematic because you have a privileged demo that goes into the  unproved user directory and it's dangerous as shit. So then we have PAM limits which  is about resource management, right, like people want to be able to set limits on specific  users, they want to make sure that some users can have more presence than others. The way  they do it is they came up with their own configuration file which is not even a database  but a configuration file in Etsy security limits.contra something like this. So yeah,  we ended up with this, yeah, simply because it's not extensible, we ended up with a distributed  thing that you can't even manage centrally, like even if you use LDAP and try to manage  centrally, it usually covers like a fraction of this, usually the Unix records and maybe  the shadow stuff but then as soon as you go into sharing pictures of users with LDAP,  that's strange territory. Yeah, this is kind of the same thing, there's no resource management,  doable was Etsy past WD and I think resource management matters a lot, right, because not  all users are equal. So you want to be able to assign specific resources, memory, disk  space, whatever else to users and yeah, Etsy past WD can't explain this. Then they create  another secondary database for this which is a quota database on disk but yeah, so resource  management is as soon as you think about multiple users, you also want to think about the differences  between multiple users and how many resources you assign to each. But we can't really do  this with Etsy past WD except through this mess of sidecar databases. So this is, yeah,  so far like a number of the problem, they think there are a lot more, this is kind of  the problems that I saw that I wanted to fix with what I'm talking about here. So, let's  talk a little bit about the focus of what I'm suggesting here. First of all, it's only  about human users, right, I don't care about system users in this context, right, like system  users being the stuff that demons run under, this is about human users like me and you,  right, that the stuff that you have on a laptop, it's not the stuff that you have on a server  so much. The goals that I want to be able to deliver with what I'm talking about here  is first of all, migratable home directories, right. Migratable home directories means that  you can take a home directory as one unit from this laptop to your new laptop or to  your third laptop and it will always work and be self consistent in itself and comprehensive  and hence migratable, right, so this basically means that as little as necessary should leak  into the system surrounding it and particularly when it comes to configuration, which is very  different from what was there before, right, like before home directories user accounts  were not migratable, right, like because as mentioned we have all these sidecar databases  and there's no way you can sensibly migrate all that metadata that is distributed in all  these configuration files and etsy and all the weird sidecar databases and var and what  not from one system to another. I want to go to this way where home directories are,  yeah, somebody didn't turn off his phone. I wanted to go, I want this to go to the way  where they're truly migratable, right, like all the way to the point where you have a  USB stick like this one and that this can be a home directory and you plug it into my  laptop and it can work there and it can take it out and put it into another laptop and  it can work there, but this USB stick actually is my user account, that it is my home directory  and it's truly and natively migratable without any magic bullshit of propagating configuration  into the system, right, so it's about isolation, it's about unification, everything into the  home directory itself and cleaning this up. I already mentioned this a bit, it's about  self-contained home directories, right, so right now as mentioned if you want to have  a user account you have files everywhere, you have files in etsy, you have an entry  in etsy shadow, you probably also have an entry in etsy group and etsy gshadow, you have  the home directory itself, you have all the sidecar databases. The goal with this is,  yeah, self-contained home directories, that everything that is on the stick comprehensively  describes the home directory, by the way I'm putting this stick here always in your  face but it's not supposed to be just about the stick, right, like the fact that we can  have home directors on the stick is kind of a nice side effect of what I'm doing, but  my main focus is actually not that, I want, most people probably want to have the home  directory on the laptop, I know this and that's what I want myself, I just want to make the  point that it should be that migratable that you can have it on the stick and it kind of  makes sense. So yeah, self-contained home directories, right, the metadata about the user should  not be distributed across the system with all its information about the user itself,  with all the resource management and stuff, it should be part of the home directory itself.  This then means that the mere existence of the home directories file where everything  stored should synthesize the user account in full, right, it should make sure that if  you call get pw.nam or something like this, like the classic Unix APIs to query user,  the mere existence of the user file store should synthesize everything else, right.  In a way you could say I want that, yeah, you know Unix, everything's a file, that yeah,  users should be a file too, right, like where you just have one concept in the file system  and that everything else comes from there during runtime and is not propagated persistently  anywhere else. One of the goals that I also have is UID assignments should be a local  artifact, right. I want that if I stick this USB stick into this laptop that I might get  a UID, stick it to another one and that UID is already used by another account there,  they get a different one and it shouldn't matter, right. This is a hard problem. We have to  cut some corners to implement this, but yeah, I want that it is a local artifact. It's like  when this home directory is bound to this specific laptop, it gets a user ID assigned  and that's how it is, but if it's bound to a different laptop as well, it might get a  different one there so that the propagation of the actual UID numeric value is not necessary  and all this infrastructure having centralized databases like LDAP and stuff to stabilize  this are not necessary. I also wanted a unification of the user password and encryption key, right.  This is what I already mentioned earlier. So far, we had the encrypted password and  NC Shadow, right, like this Unix password string, $1, $6 or something and we have usually  the hardest encryption like the Luxe password. I don't want this to be two different things.  I want this to be the same thing, right, like if you're capable of decrypting a home directory,  that's good enough as authentication that you're also allowed to and also the reverse  should be true, right, that if you're allowed to lock in, only then there should be any  chance for you to access the home directory. So yeah, I want these two concepts to just  be merged and be the same thing. Also, this is really important, we should have like in  2019, extensible user records, right, like so that people can put in these user records  whatever they want, right, and we propagate that through our APIs to have a wants to know  this. And yeah, so that we are not stuck to struct pass WD, right, this five field structure  defined in 1985 or something, but people can stick in there whatever they want, like if  they have some weird requirement for their own company, they can put something there.  And if other people have different requirements, they can put something else there. But we  agree on a common basic vocabulary, but are highly extensible. Also, one of my really  important goal actually is to lock Luxe on system suspend. So nowadays, I'm pretty sure  that first of all, most of you probably use hottest encryption on your laptop. And second  of all, I think most of you probably don't even turn off the computers anymore at all,  right, like usually just close the screen and that suspense the system. And then when  you come back, you just authenticate again. But it systematically, I mean, it kind of  defeats the encryption, like the encryption that you have there, because basically the  way it's currently implemented, you use hard disk, like full disk encryption. So while  the system is up suspended or running, we are up in that context, the decryption key  is a memory. So if I go through customs to a country that I don't trust and I have the  laptop with me and it's suspended and they pick up the laptop, in that memory, you'll  find the decryption key from a hard disk. And that's something I think we should not  do, right? We should. And this is something that people might not find important, but  I think it's actually one of the most important things in this entire approach at all, is,  yeah, when you suspend the system, the decryption keys need to be removed from memory, right?  So that I know for sure that if somebody steals my laptop in suspended state, because that  is the most common state that they will probably steal my laptop in, they should not be capable  of getting any access to my hard disks, right? Again, this is something you really, really  should care about, because it basically so far defeated all kind of encryption that you  had, because as long as you did system suspend and everybody does that, if somebody steals  the laptop, they can get extract everything they want. So doing this is actually much  harder than it sounds at first, because the reason why we're not doing this on general  systems right now is because, yeah, if you use full disk encryption, then the operating  system itself is encrypted, right? So if you come back, like if you actually flash out  the cryptographic keys when you go down for suspend, and then you need to require them  from the suspend, who's going to ask the question if it can't even be loaded into memory because  it itself resides on that encrypted partition that you want the password for, right? So  there's a bit of a chicken act problem and nobody solves this so far. With this, I want  to solve this, right? So that when I suspend my machine, the operating system itself is  independent of the individual home directory, so that we can suspend the home directories  independently of the system itself and hence solve the problem. Also, I kind of indicated  this already. I think we need to move to more modern ways of authenticating yourself to  the system. Password's great, but also maybe we should do something better. So, yeah, one  thing I want to be able to deliver from day one of this system to home, this thing is  UB key support, right? I mean, UB key, I put in the sense of like how you would use the  word Google for search engine, right? It's not just about UB keys. It's about anything  that is like a like authentication token that implements PKCS 11, right? And I think we should  do it properly, meaning that we actually use the cryptographic properties that a UB key  provides and hence, yeah, if you don't have the UB key that there's no way in the world,  the cryptographic key for unlocking your account and for accessing the encrypted data on disk  can even be retrieved. So, that's the goal, the goals that I have. There's some complications  with all of this. SSH logins, right? I mentioned that I wanted that user authentication and  decryption of the hard disk is the same thing, right? This is inherently incompatible with  how SSH traditionally works, right? Like, because as mentioned, if you authenticate  via SSH, it goes via the authorized keys file in the home directory. So, if you want to  authenticate something that is inside of the home directory so that you can access the  home directory, where does the decryption key come from to access the home directory,  right? You follow what I mean? It's there's a chicken neck problem. You're reading out  the key that allows you access from the encrypted thing which you only can after you authenticate  it, right? So, my answer to that is we don't allow SSH logins as long as you have not locked  in first locally. Because, I mean, allowing SSH logins the way that they're traditionally  done means that inherently the home directory of the user needs to be accessible before  the user locks in. And I think that's something I really don't want to have, right? I really  want that when I'm locked out here, that not me, but not also anything else in the system  can even access my home directory. That includes open SSH to read the keys from that. So, yeah,  my answer to this is SSH logins into systems that use this can only be done after I logged  in locally, which decrypts the hard disk, makes it accessible, and then SSH can access  everything. Also, by the way, actually the authorized keys file is something I think we  already implemented even, should be part of the user record, like the successful user  record, so that you can actually, yeah, it's just there. And, yeah, this already actually  works.  This space assignments are a bit of a problem, right? We probably should come back to this  one later a little bit when I talked about how the storage of what I'm doing is actually  done. Another problem is UID assignments. I kind of already indicated that. So, the problem  is if we want the UID to be specifically local to the system, right, it might happen because  the range of user ID is very small, like it's just 32-bit, that there will be collisions,  right? Like that if I have my home directory on this laptop and then take out the USB stick,  put in another laptop that somebody else might have already used the UID that I used here,  yeah, this is very likely because the space is so small. Ideally, the kernel would help  us with this, right? Because we had something like ShiftFS, so that it doesn't matter what's  actually on disk, that as the moment where I log in, I get assigned the UID and then  I mount virtually all the files to the right UID. We can't do this, so we go for the next  best thing, which is churning recursively if we have to and try to avoid really hard  having to do this if we can. Thankfully, churning recursively surprisingly fast, actually, if  we actually have to do this. And I'm kind of okay with the behavior of this because, I  mean, we tried very hard to make the UID assignments stable. So, for example, we hash it from the  username, but that's never going to be enough because the name space is so small. But this  basically means that probably in real life, if it's just Leonard and I have like three  machines and I take this one out and move between them, I will probably never need the  churning. But it's there to make this safe. And ideally, sooner or later, we don't have  to do the churning anymore. Yeah, looks locking. I already mentioned that this is kind of complicated,  but there's also a couple of other complications. If we do the looks locking on suspend, right,  where we remove the cryptographic keys from memory as we go into suspend mode, we need  something that queries for the password again when the machine resumes because until that  happens, the home directories are locked completely locked and cannot be accessed because there's  no cryptographic key known for them. So, we actually need cooperation for this from the  UI, like everything else that I'm doing here I can do without any UI involvement. But in  this case, we need some cooperation from the UI, specifically meaning that when the system  comes back from looks, your display manager, like GDM, whatever you use, will have to re-assenticate  the user because, I mean, mostly, effectively, they already do this, but they do it the wrong  way right now because mostly the way that they do it is that the screen lock that is  turned on on suspend actually runs under the user identity of the user itself. This doesn't  work if we suspended the home directory of the user because we can't run code until,  under the user's own identity until the home directories resumed again. So, what we need  here is that GDM, for example, is patched that when the system comes back from resumed,  it asks the password again so that we can unlock the home directory and then can switch  back to the user's login session. So, I know this is a lot of material so far. Let's now  actually have a look at the actual stuff I did on the actual code concepts. Yeah. There  are two new concepts. One of them is I want to go for JSON user records. I think we should  just start using that for our user records. Yeah. The reason why JSON is because it's  just the most basic thing. It's supposed to be machine readable. It's not supposed to  be something you write. It's something computers write for you and things like that. And it's  also what probably most of the internet-facing user databases probably use anyway when they  exchange information about users across the network. So, that's the first thing. JSON user  records. It's supposed to be a superset of the NSS. NSS is a name service which of Glipsy.  It's like a generic term. Glipsy uses for struct past WD instruct group, which for the  ones who don't know Unix so much, that's how user records are done by Lipsy since then  1985. These JSON user records are supposed to be  queryable via varling interface. Varling for those who don't know is a very simple IPC  system. It's just used JSON and it's supposed to be the most trivial IPC in the world so  that as long as you have your own JSON parser, you don't actually need any kind of other  code base. I have a slide later why varling is the right answer here and not deburse. There  are good reasons for this. So, yeah. The idea is also that from these JSON user  records that are queryable via varling interface, we can convert forth and back between this  and the classic ones. In one direction, of course, it's lossy, right? Like because JSON  stuff can have any kind of metadata, while struct past WD instruct group cannot.  How does this specifically look like? This is an example. Now, if I had a laser pointer,  I could show you. I think some of them, this is pretty much self-explanatory, right? Like  username, you guessed it, is username. This position is just, yeah, ignore that. But nice  level, for example, configures that when this user called Groby logs in that all his processes  get nice level five, right? It's pretty self-explanatory. Member off means, yeah, this user is supposed  to be member of the group wheel, I think, yeah. What's interesting here is the binding  thing. Binding is supposed to bind a specific user record onto a specific system. The reason  why this is a sub-object and not part of the main thing is simply because depending on  specific systems, resource management is probably going to be different, right? Like if I have  a user record for Leonard on my desktop, my super beefy desktop, and I want to put a size  limit on it, it should be specific to that desktop because it has so much more memory  than my laptop might have, right? So the binding concept here basically, you see the hack string,  that's actually the Etsy machine ID. Basically it just says, yeah, the following properties  apply only if this is bound to a specific system. And then, yeah, GID is the, GID, UID is the  UID. What do you see? Else there is like meta information about how the actual storage is  done. We'll talk about this a little bit later. This continues. Privileged is a special section  that contains a privilege information. It's basically what Etsy shadow is. The reason why  it's a sub-object is so that we can strip it if somebody is not supposed to see it,  right? So the idea basically is that all the information that is an Etsy shadow traditionally,  plus all the new stuff that people want to come up with, should be in a specific sub-object  so that whenever somebody who shouldn't see this information wants to see the record,  we can automatically remove it. Anyway, I don't want to go too much detail about the  structure of these records. There's documentation plenty about this. What's also interesting  is you can sign these. We'll talk about this later, why that's interesting. So that was  concept A. Extensible, JSON, user records, plus an API, how to query them, kind of replacing,  get PWN, but also compatible. Concept B is I want that home directories are encrypted  lux loopback files in slash home, right? So that, you know, if I have a user called foobar  in slash home, traditionally there was slash home slash foobar and was a plain directory.  I want that there now is slash home slash foobar dot home and it's a file and it's actually  a lux loopback image and then when the user logs in, what do we do? We set it up via  lux stuff as a loopback file and then we finally mount it after validating that everything's  okay. These extensible user records are supposed to be stored inside of that image inside of  file.identity. That's nothing magic about that. This stuff is supposed to be managed  by a tiny diamond and it's actually not, it's really small because it doesn't do much. That  is called system.homedi.service. What does that thing do? It's okay, I have not much  time left. There's so much more awesome stuff in this, but let me finish this quickly. So  system.homedi is what it actually does is it just, the thing that sets up these home  directories as you log in. It also provides NSS interfaces so that the old APIs all work  so that you can get to end on the shell, for example, to get the user database and find  then automatically all these user records and everything works. This concept B, like  these encrypted lux stuff, can be used, it relies on concept A, but concept A you can  actually use without it. So if you just care about the extensible user records, that's  totally fine and you should by the way because even if you have to eld up on these more classic  user databases, you might want to be able to hook up, hook into system.homedi resource  management because all this new stuff is hooked into system.homedi's user management. For  example, there's PAM system.D that has been around for a while, but what it does actually  takes the JSON record, pulls all the resource control that makes sense from the nice level  as you have already seen the classic resource limit but also environment variables and that  kind of stuff and sets it for all the pros that log in. There is also support and system.D  log in at service which kind of does the same thing when you log in, but it applies it to  the C group stuff, so that it applies to the user as a whole. So if you are into eld up  and provide these extensible user records, just by doing that, you get this integration  to get all the fancy resource management you ever dreamt of.  So I think this, I kind of already explained this. I care about encrypted home directories  and loopback files. I care about encrypted home directories on block devices like this  USB stick for example, so that we have something truly migratable there. While this is what  I tell people I'm going for, like encrypted lock stuff, actually the system.homedi component  does not just support that as a backend, it actually has four backend like classic plain  directories for compatibility, but are SAP volumes, FS, crypts, SIFs and looks. But again,  looks that backend is the one I want to push towards, people's towards, because it's the  only thing that's actually fully secure because not just the payload of the user but also  the metadata is encrypted and it's fully featured in all these kind of things, industry standard  and stuff like that. This is after all an exercise and not coming up too much new stuff  but just taking what's already there and that is looks for example and just sticking up  in a more nicer way. But anyway, my time's over. I'm fully aware that I totally did not  finish all the beautiful slides I have there. These slides have been online for a while,  but I probably should take some questions at least. Yeah, somebody has a question there.  Can you read that? There's a mic. Thanks. In the user, the JSON structure, there was  a list of groups for the user. That needs to be somehow verified by the system. How  do you approach that? Because user can change whatever groups he is and then it will automatically  gain access on whatever systems they look in. The explanation isn't this thing, the  signature. Basically, the user records are supposed to be changeable by only privileged  like the administrator or whoever manages user record and then you're supposed to sign  them and each system will only accept the user records that are signed by the right people  where the signature can be verified and the key is known for this. This is actually, it's  not an option. At least if you manage stuff with system to home, it will insist that everything  is signed. We live in a world where cryptography is everything. This stuff will refuse allowing  you to log in on a random use B stick. It will only allow you to log in with random  use B sticks that have a user record on it that is signed by some key that is recognized  by your specific laptop and you can recognize as many as you want. You can change that file  as much as you want, but if you do, you just lock yourself out because you can't sign it  because you don't know the private key being used.  Yes, so the question was whether you need privileges to change the SSH key of your own  user account. Yes, you do. It's the same way as it always was for changing your password.  That also requires privileges. This is hidden from you usually by suing suede and it's the  same way we can hide through policy kit. But yes, there's no way that your code pass that  run until your user identity makes these changes and I'm pretty sure that's how it should be.  If there is desire to allow on-privileged users to change some artifacts of the user  records, it always needs to go through privileged component that's policy kit, whatever else  to allow this.  So if I got you correctly, you said before that you need to log in first in your account  before being able to do an SSH login to that. Let's say I'm a university student and I have  an account on the university lab and I'm at home and I want to access my account on the  university lab computer, but of course the system was rebooted overnight so I cannot  travel 200 kilometers. How would we handle that use case? Would it be possible for instance  to store the SSH key as a looks key and to change up an SSH to unlock my home folder?  I mean SSH doesn't deal in passwords, right? It gives you a challenge and you're supposed  to respond to that. And if that kind of stuff means that the only way you can do things  is the other side you're syndicating against is an active program, right? That's not how  looks works. Looks, you authenticate against a disk image, right? So this is inherently  incompatible. You cannot use like at least I don't see how you could use SSH authentication  to decrypt a home directory that is semantically incompatible. So my answer to this is if you  really want that this system can come up on its own and decrypt your data, don't use  this stuff. This is about security. This is not about giving up any kind of access to  your data. This is about supposed to protect the system, to protect your data from the  system as much as possible so that when you're not locked in, it's really cut off and like  mathematically cut off.  And regarding to SSH, what about having like SSHFS reverse as your local home folder you  already decrypted and opened is used over there and then the credentials inside of that is  somehow unlocking over there the homes. You know what I mean?  Yeah, I mean, this of course always works, right? Like, I mean, yeah, if you, so, you  know, for the UB key support, right? Like, I'm not sure if you know, UB key stuff, like  this is generally accepted API for accessing security tokens. It's called PKCS 11. And there  is a project inside of Red Hat. And that's actually, I think, including Fedora and everything  which allows you to propagate PKCS 11 devices across the network through SSH, for example,  right? And with that kind of stuff, you can make all the security, like the encryption  keys and all that stuff that is available locally, also viable on a remote system to  do that kind of propagation. I was interested in this because I wanted to make it possible.  Like, I have a UB key in this device and I would ideally would like to just use that  to authenticate through SSH onto another system that runs system be home D and so that, yeah,  the crypto key is sanely encrypted through that. So there are certainly things possible  there, right? Through this PKCS 11 forwarding. I'm not sure how realistic that is in the  short term, but I'm kind of, yeah, well, let's see how that works. But again, I mean, the  other way, right, that we were just talking about like logging over SSH into my laptop,  I'm not so sure that's that much of a common case because my laptop is a client. It's not  a server, right? Like you usually lock from it into other systems. You usually don't lock  so much into your laptop from from from the outside. It's like philosophically, yeah.  Sorry, having  Oh, on the other system, I mean, sure. Yeah, I mean, there's the solutions like I mean,  one thing that is actually kind of nice is like, you could even share these locks files  via NBD. And then they show up on other systems. And then they, if you can log in there and  we'll just work because yeah, use B stick is not very different from from NBD or something  like that. But that's out of focus for everything. I mean, my main focus really, I want my own  laptop is finally secure that I can suspend about this. I mean, this is kind of like the  this is a summary after all, right? I want these problems to be solved finally because  we never could solve them. And I want to solve for my own machine because I care about the  security and these kind of things. Right? So if you remove the lux encryption key on  suspend, does that mean that you have to log out? So all processes terminated? No. And  then follow up question. If the process are not terminated, there might still be some  private data in the memory and running applications, right? Sure. Okay. So yeah, I mean, there's  data and there's data. There's crypto keys. And there's your private data. Yes. If like,  I mean, if I would, if I steal your laptop and try to extract the memory, the first thing  I'm looking for is having the crypto keys. That's the one we definitely should kick out.  People using crypto swap and these kind of things. I don't know, maybe we should, there's  something more to solve there so that as much as possible, the kernel flushes out all the  memory onto disk into swap or something and then it's encrypted and stuff like that. But  that's outside of my area of expertise and what I can solve. I just want to solve like  the really obvious stuff. Yeah. But anyway, when the system goes down, we will suspend  the lux device and that does, that basically means that any process accessing it at the  time will hang while it does that until we resume it again. This is, this sounds ugly  and is ugly, but also it's not much of a problem because we go down anyway into system suspend.  There's not going to be any process that might hang because the CPU holds it anyway. So yeah.  So if I want to have my home directory migratable, but also as a backup, let's say I back this  up to a separate disk, then I also need to back up the signing key of the signature file,  identity file, the key that was used to sign as I can look back into the system if I have  to restore it. I mean, this stuff, it doesn't, ultimately it's just a lux file system. You  can use the classic lux, like crypt it up to look into this and do whatever you want.  Lux of course has no understanding of user records or signed user records. For backup,  it really doesn't matter that you retain the original signing key there. The signing keys  controls who can log in. It does not control who can access the data if he knows the password,  right? So for backup, it's totally sufficient to just take that one file and back that up.  By the way, it's, I mean, this is something people should never forget, right? Because  this says that the user record and the home directory all become one file, you can just  take that file from one laptop to another laptop and you don't need to do anything at  all anymore. It just pops up there and is there. And for the backup case, I think it  would even make a ton of sense that if the backing file system of the show is something  like XFS or BrutterFest or something, you can do a raffling copy every day of something,  of that one file and there you go. You have perfect time machine kind of stuff. I mean,  this opens up really nice possibilities as soon as we unify everything into one file.  Because yeah, in Unix, most things are focused on one file. Anyway, I think my time is mostly  over, but maybe one more question there.  Okay. How do you plan to deal with different distributions and versions of distributions  because we have different versions of software and even if you use common home directory,  it would be not working.  Well, this...  So, I mean, system.ly.home is a part of system.ly. That's kind of the goal, right? And unless  people patch around this heavily in the distributions, hopefully it's kind of going to be the same  thing in all the distributions. All the stuff that I'm explaining here is not supposed to  replace or modify the existing users that you might have, right? This is an add-on,  right? So that if you have a home directory like this, great. It will show up in your  user database and everything's great and because it's in this version, it's going to be compatible.  But if you're talking about the software that is inside the home directory, people kind  of solve this because NFS shared home directories always work like this already, right? And  it's a mess and I don't care so much. It's a problem I'm not going to solve for you,  right? I'm not going to make sure that every version of Emacs packaged by any version of  any distribution can read the same configuration files. That's something other people have  to solve.  I at least want to make it possible that the home directories are truly migratable and,  yeah, how migratable they are between the distributions, that's not my problem to solve.  The lower levels, they will be perfectly migratable because, I mean, Lux, if I compile a, if I  format a volume on Fedora and then run it on sues, it just works. They did not break  compatibility and since this is really just Lux, yeah.  Any very last question or are we done? If you...
Reinventing_Home_Directories_ZwjzfdLJtX4_0_131.png Reinventing_Home_Directories_ZwjzfdLJtX4_132_1235.png Reinventing_Home_Directories_ZwjzfdLJtX4_1236_1427.png Reinventing_Home_Directories_ZwjzfdLJtX4_1428_1763.png Reinventing_Home_Directories_ZwjzfdLJtX4_1764_2015.png Reinventing_Home_Directories_ZwjzfdLJtX4_2016_2267.png Reinventing_Home_Directories_ZwjzfdLJtX4_2268_3299.png Reinventing_Home_Directories_ZwjzfdLJtX4_3300_14651.png Reinventing_Home_Directories_ZwjzfdLJtX4_14652_14711.png Reinventing_Home_Directories_ZwjzfdLJtX4_14712_14879.png Reinventing_Home_Directories_ZwjzfdLJtX4_14880_15419.png Reinventing_Home_Directories_ZwjzfdLJtX4_15420_17867.png Reinventing_Home_Directories_ZwjzfdLJtX4_17868_18467.png Reinventing_Home_Directories_ZwjzfdLJtX4_18468_18707.png Reinventing_Home_Directories_ZwjzfdLJtX4_18708_29339.png Reinventing_Home_Directories_ZwjzfdLJtX4_29340_29387.png Reinventing_Home_Directories_ZwjzfdLJtX4_29388_29555.png Reinventing_Home_Directories_ZwjzfdLJtX4_29556_30203.png Reinventing_Home_Directories_ZwjzfdLJtX4_30204_30263.png Reinventing_Home_Directories_ZwjzfdLJtX4_30264_36995.png Reinventing_Home_Directories_ZwjzfdLJtX4_36996_37451.png Reinventing_Home_Directories_ZwjzfdLJtX4_37452_42155.png Reinventing_Home_Directories_ZwjzfdLJtX4_42156_43235.png Reinventing_Home_Directories_ZwjzfdLJtX4_43236_43307.png Reinventing_Home_Directories_ZwjzfdLJtX4_43308_43535.png Reinventing_Home_Directories_ZwjzfdLJtX4_43536_46307.png Reinventing_Home_Directories_ZwjzfdLJtX4_46308_47315.png Reinventing_Home_Directories_ZwjzfdLJtX4_47316_47711.png Reinventing_Home_Directories_ZwjzfdLJtX4_47712_48263.png Reinventing_Home_Directories_ZwjzfdLJtX4_48264_48623.png Reinventing_Home_Directories_ZwjzfdLJtX4_48624_49223.png Reinventing_Home_Directories_ZwjzfdLJtX4_49224_49559.png Reinventing_Home_Directories_ZwjzfdLJtX4_49560_49607.png Reinventing_Home_Directories_ZwjzfdLJtX4_49608_50027.png Reinventing_Home_Directories_ZwjzfdLJtX4_50028_58511.png Reinventing_Home_Directories_ZwjzfdLJtX4_58512_58559.png Reinventing_Home_Directories_ZwjzfdLJtX4_58560_58607.png Reinventing_Home_Directories_ZwjzfdLJtX4_58608_66515.png Reinventing_Home_Directories_ZwjzfdLJtX4_66516_66664.png