 Hi, I'm Leonard Butler and I work on system D and yeah, you probably knew that Today I'm going to talk about reinventing home directory. So my goal is to take away Like after we took away system five in it from you. We're now going to take away your home directory, but Yeah, I think we have good reasons to This talk is really about Explaining this and explaining why this matters. It's like one of the stuff that I'm going to talk about is this kind of Desktop-ish focused. It's not so much so stuff. He doesn't so we don't have home directories But while implemented there's a lot of stuff actually came out for the server as well But basically as a side effect, so it shouldn't even be interesting for server people in some direction. So Let's talk a little bit about home home directories, right? Like dollar home. That's your home directory or tilde my home directory is kind of like an Linux traditionally or Unix traditionally it's a Distributed concept right like first of all you have your directory in slash home. That's called like for my user It's called Leonard. It's home that but there's also etsy an entry in Etsy past WD Which actually would just to this as a user for the system I see problems with this first of all needs a writable Etsy Right like whenever a user is added or removed or he just wants to change his password We need to make a change to Etsy. I think in in general we should probably move to a World where unless they're actually configuration changes made Etsy can be mutable read only another change Now the question is if the existence of a user and his password actually configuration or just state of a specific user, right? like usually If you change something in Etsy, that's a highly privileged operation that changes the configuration of the system and I have doubts that user registrations and user passwords are that It also mixes I mean this kind of the same thing it makes a state in configuration because suddenly in Etsy We have more than just stuff that is purely configuration because as mentioned. Yeah, I use I don't think it's configuration There's also this general problem with how we traditionally manage users is that you do UID assignments like the numeric Unix UID assignments need to happen at the time the user should just isn't and they stay stable And if you ever want to change the home directory like share it between multiple systems You have to propagate the the UID as well that creates massive problems, right? Like it creates massive problems with NFS and LDAP and these kind of things Problems that we kind of created ourselves, right? Like we because we created this this concept of UIDs that is small like its range is too small to be universally Valid so it's only valid within some the realm of some company or some organization and then we created all these massive infrastructure to Yeah, make sure that my user Leonard and all of Red Hat's deployments always gets the same number So, yeah, I think that the concept of UID as a global artifact in a even though It's inherently not global is a problem and something we should address Also home directories are generally not encrypted. I mean sure there are solutions to do this But it's the encryption that we usually deploy like for example, Lux have full this encryption or encryption of slash home It's kind of weird because it actually doesn't cover. There's a mismatch. It doesn't cover as a specific user It covers the whole thing, right? We talk a little bit about that later. So at its very core Encryption is not built into the user Concept on let us and I think we live in a world now like where was all snowden and also all these kind of things Where I think yeah, I mean my Android phones better encrypted. I think and then semantically better to encrypted than My home directory on my Laptop, that's kind of weird. So I think we need to go for a world where every encryption is just there It's nothing to think about. So, yeah Yeah, as medicine, it's kind of a mismatch of encryption by mismatching encryption I mean that you know the way if you install Fedora and to do heartless encryption You get asked during boot for the password of the whole operating system, right? And this is like a passphrase a luxe passphrase and this is what protects the opera rating system as a whole It's the one password that actually matters Then after you type that in the system continues booting up and then eventually get asked for your username and password and selling us I think it's a second time, but this one doesn't actually matter so much It doesn't actually unlock any any any any any cryptographic anything. It's just the data is already Decrypted it's just like all the programs can already read it. It just does authentication at that point So, yeah, this like I mean we think that Linux is a multi-user system But the concept that every user who wants to use our multi-user system has to have a Same password that he memorized and shares with everybody else is really plain weird if you ask me, right? The way I think it should always work is you ask again a syndicate a user You provide a password for that user and that unlocks your stuff and nothing else And you don't have to share a secret password or anything with anybody else and yeah There's also a problem The way how we do users generally like natively doesn't support anything but passwords, right? There are admittedly solutions like That hook it up with pkcs11 to do you be key authentication whatnot, but these generally are not you know You won't find them an ac pasta of UD. They are Secondary to that glued on top in a not very natural way because I mean if you can make changes to the user deleted Even all these side card databases stay around. It's not extensible. It's kind of the same problem Right like since basically 1981 we stayed with the same struck past WD, right? It has a space for a shell you have a space for a username a pretty name you already in guidance kind of it, right? So then people tried really really hard to extending that like some of things in worked out really well like Etsy shadow Something like of an extension of Etsy past WD and kind of generally accepted But everybody else added their own stuff in a sidecar database and most of that it did not get adopted universally So yeah, we have plenty sidecar databases think of Etsy shadow as the first one But that's also like the unknown people came up with accounts them and because they wanted to have a picture with users and couple of other things Then Samba wanted to share they like have a per user Windows GUID thing Sid or something. It's called that they have another a sidecar database As his age has a sidecar database, it's the authorized keys file in your home directory It's like all these things are inherently properties of the user But because our user database is kind of set in stone since 1981 It's sheds this it's managed somewhere else easily gets out of sync I mean the infrastructure that we have alone to keep Etsy shadow and Etsy past WD in Sync is already crazy enough, but usually these tools don't care at all What Samba does SSH does or even Pam limits does right like because Pam limits is how you said said resource limits per per user Right like and it's a configuration file This is completely separate even people don't think about that and then a couple of other more sidecar databases like that That's here are the messiest different semantics generally not synchronized together. So There's also this problem that I think user management Like one key thing Next to authentication these kind of things should be resource management, right? Like if I log in on my laptop doesn't matter much But if you ever live in a multi user environment, you should be able to control that that user may use these many resources This much memory this much CPU and things like that and that user a different amount, but yeah, we currently have no Sane infrastructure for doing that we have 10 limits it controls resource limits But these resource limits are like per process and that makes them pretty much useless We have Infrastructure in the currently stays like what the previous talk was about C groups that would allow us to actually Do this properly, but we have no sane way to do this right now. This is something I think we should change I think user management to a massive amount should actually be about resource management It's kind of said that we never solved that But these were the problems that I saw with the current status quo that it's like it's lots of stuff Then we inherit it and that is deeply established in how we do these things, but it's not pretty and very limiting What we can do with it so Everything I'm talking about in the rest of the talk is now about solving these problems To make this clear and with this stuff here I'm focusing on real on regular users as opposed to system users, right? This is about me like Leonard logging in into a system It's not about I don't know some I don't know ansible agent logging into something and doing stuff This is about real users like you users you have passwords that they type into a keyboard users that have UV keys that they stick into their laptop, right so if Yeah, there's a primary point there are a couple of things that then leak into the other kinds of users the system users, but In general from everything that I'm trying to do here is really about human users and particularly laptop users like Users that are defined in a in a world that is inherently mobile and mobile between Like organizations like for example my laptop today I'm using it as a computer science faculty in Brno But I sometimes use it at the redhead office, but I also use it at home Right this laptop is inherently mobile and it's conceptually problem Saying that it is part of the redhead network because right now it isn't really like I mean It's part more of the computer science department. So this concept of making a laptop a member of a I don't know Kerberos domain or something and leaving it like that is I don't know probably Was right in the 90s where could laptops weren't the way how people work, but nowadays I think we need to put Emphasis on having laptop users meaning mobile users meaning laptops that change position and they're always And we're sometimes connected to the internet, but always from different locations so I Formulated a couple of goals that I actually want to do is what I'm doing One of these things is migratable home directories migratable home directories means that I have a home director on my laptop and it is All the data that is related to his home directory is unified in this stuff And then I can just take it as one file and put it onto another laptop And it should that should entirely suffice to have the user there We are not at that world again because of all the sidecorner databases, right? Like I I might be able to tar up my home directory, but that doesn't give me Etsy past W That doesn't give me Etsy shadow entry that doesn't give me the summer entries That doesn't give me the pen our limits or anything like that so For me migratable home directories is that we unify everything at one place so that this one thing I can then move wherever I want This has interesting Implications like for I could copy my home directory then to another host and would just work But I can also do funny stuff like I don't know say that my USB storage stick is now my home directory And if I plug into this laptop, I can log on to this laptop and everything's fine But because all the data is monopolized on the USB stick I can just rip it out and put another laptop. It should just work there, right? This isn't an interesting application of having migratable home directories It's not the primary use case I'm going for but I hope you get the gist of like if it's truly migratable This is one of the things you can actually do with them So yeah self-contained home directories. They should have the full description of what the user is Meaning resource management meeting authentication stuff all inside of there So it's yeah unified This means for example that Yeah, I have one File object that I can drop into slash home and this not only means that I have a home directory there But it synthesizes the user record as well Implicitly and you can just by doing that already log in One of the other goals I kind of already talked about this earlier is that you are ID assignments in my scheme should not necessarily But ideally and I think in most users case. They should be a local artifact, right? There should be something that because Linux is the way Implemented the way it is Happens when I log in I get a UID, but it's not necessarily a global artifact Well, I like if I take the USB stick out of there and put another laptop It should be fine if I get a different UID assigned there because yeah I want to turn this into entirely something local that makes sense in the local system and we can remove this Necessity to always synchronize it everywhere else I can I indicated this already as well Like I want the unification of a user password and the encryption key meaning specifically like the separation where we first unlock the Lux Hard disk and then much later actually unlock the home directory So we have the separation between encryption and authentication And one is bound to the system and the other one is bound to the to the user I want inherently that is all as the same thing meaning if I log in Provide a password this password both controls whether I actually can use that stuff, but also is the actual Key that is used for decrypting a hard disk so that one Authentication mechanism is one one secret is enough to actually be able to unlock the whole thing Another goal is this should be inherently extensible right like because the need for the cited car database We all we had it's a valid one right so if I implement a couple of new properties in For a user record and in the system you contact it doesn't mean I should be the only one Everybody should be able to do some I should be able to add something No, people should be able to add something everybody should have their own fields. It needs to be inherently extensible without Anyone owning everything and controlling everything and then having a process, but he adds something right another goal I had is You know if I if you look at how people actually use laptops these days they almost never actually shut them down anymore, right like we We close the lid and then the suspense right like my laptop for example I haven't shut down like I don't know weak or something and I think this is reality right like but the way we currently use the Look stuff right like full this encryption is That yeah at boot you provide the password and then stays in memory all the time it never gets removed again Right like it's it during system suspended still in RAM somewhere and this is inherently a problem because it kind of defeats the purpose of Encrypting everything because if anybody steals my laptop while suspended it's physically still there I like if it's if the person who steals this is sufficiently technically equipped like NSA or something It is not particularly different for them a difficult for them to actually read out the memory and they you find the unencrypted key for my heart is so Accepting that this is how we actually use computers these days I think it's absolutely essential that remove all crypto keys the instant you suspend the machine And then we when you resume the machine you have to re-supply all the authentication He's meaning your password basically never get about a thing gets unlocked because then I can be safe If I submit my machine put in my backpack and somebody steals the back part It's not useful for them right even if they're the NSA the key is not available on that system They can do whatever they want and they have to break the crypto itself So this was always difficult for us to implement because if you do fill this encryption right Then this basically means that when you go to suspend you would have to flush this out and then we come back But then you have this thing where the operating system runs off the encrypted volume But now you don't have the crypto keys to access the the the volume anymore So you have this problem that unless everything you possibly could need to Reauthenticate and unlock the thing again you will deadlock right like because you have to unpage the the binary from this You have to read them or this but you can't because you have to re-authenticate first, but that's exactly what you're trying so by Changing things so that every user gets his own encrypted Home directory and that is what we protect this problem pretty much goes away because the system can't stay Accessible doesn't matter anymore because we flush out every home directory that basically means we need to suspend All the processes that actually access that home directory, but generally we know that these are only the user's process It's not the system so the system stays active and can start programs when it comes back as much as it wants It's not affected for the by the fact that the home directory starts suspended Also one of the gold wars we live in a world now where where I in the passwords kind of work But also everybody knows that they're risky because usually people Have them too simple and things like that so With this I really wanted to put emphasis on more modern ways of authentication And this means you be keys from day one and this means you be keys in a different way than we traditionally use them Right like because if you install you be key support in Linux right now what you do get is that they help you with authentication, right? What you don't get easily like I mean you can download some weird scripts and it's madness But what you don't get is that the actual encryption of the hot Hardware is bound to the to the UB key itself because that's kind of actually how you want to use the UB key It's a smart card. It can do it has a private key on it that can decrypt Encrypted keys that actually can unlock the hardware and that's how we actually want to use it So one of the emphasis is let's use UB key that builds this properly So that is a UV key that actually provides the key to unlock the hard disk with that basically means that Yeah, you get the full protection that you should be getting By the way, I'm talking a lot and I know that you have questions and most people probably have the question at the end But actually I prefer it if you have the questions right away So if you have any doubts questions about what I'm saying totally interrupt me. I like it that way Yeah, a couple of complications right like if we come to this model Well, we now encrypt the home directories and you need to authenticate first you need to provide the password first before the the home director can be accessed this is a problem like for example for SSH logins because SSH logins work This way like the SSH logins that most people use they work this way that You put in your home directory some public keys that can be used for authenticating to your account Then if you log in from the outside SSHD looks for these keys in your home directory and Chacks if you have the right private key and everything's good and then allows you to go in but it's systematic incompatible with this model right like because we said It's the password you supply that unlocks the home directory So that basically means that if SSHD comes along and tries to access the home directory to check if you are allowed to look in Home directory is not accessible as long as nobody provided that passphrase. So it basically means Yeah, there's some complications with SSH logins I don't think it's much of a problem because as mentioned I focus on laptop users and as is aging into laptops users Certainly something people do I do that too when I break my machine for example But it's generally like usually the laptop is the client not the server you log into so but I don't know It's actually not that bad as it sounds even because we actually can make it work to some degree So basically as long as the password was supplied once As is age logins work the way they always work because if they supplied once we can unlock the thing Then it's unlocked that can you mess as HD can look into this also I I actually like with this stuff you can actually and that the SSH public keys into the user record itself, right like because it's user credentials should be part of the user record And if you do that then actually If you log in via SSH we can use that information then SSH can say okay everything's good And then you can get prompted for the password to unblock actually your home directory and then everything goes through it's Yeah, it's doable. I like there are a couple of things missing because we cannot offer the password in the time But anyway, let's not talk about the specific part. It's just saying this is a complication There's a problem when it's disk space assignments right like if we give every user his own Lux volume and then you have 10 users on the machine How do you actually make sure that everybody can use whatever he wants right like because you have the like Lux volumes and the way I Designs this stuff is that everybody gets a loopback file there that has a lux volume inside of that and then has a file system on top if Then I have my Laptop here and I'm a single user system. It's fine I can just size the loopback file to the size of the underlying file system and everything's good But as soon as I have multiple users, there's this problem was disk space assignments. I need to figure out somehow Yeah, which user gets how much and then it's relatively static It's not as bad as it sounds again because we nowadays to live in a world where actually resizing file systems is really simple It's one I octal in the kernel you have to call But it's I mean I would be lying if I say it's it's it's perfect because it's kind of a little bit of a volume management That is not as flexible as we want like for example in XFS if you use XFS inside of the loopback device You cannot shrink of XFS volumes For better, as you can do all everything Dynamically, so we could even like in a user manager allow you to Drag something it will instantly apply though. So that's all great But yeah, I'm not saying that it works perfectly like on a semantical level, but it works good enough You had ESI that's another problem I talked about this goal of mine that I wanted to make you ID Assignments a local artifact instead of a global artifact, but that basically means that if I put my USB stick with my home directory in this laptop I get one new idea signed if I put in another laptop I might get another UAD assigned because the one that I used here was already taken there, but I Then need to do something about the home directory because all the files and they're gonna still gonna be owned by my old user I'm from the first machine solution right now as we do recursive job sucks Doesn't suck as much as people might think because actually churning is really really fast on Linux Like was my home directory which has a couple of system E trees kernel trees and so on It's a matter of less than a second actually going through the entire thing and showing it ideally Good point. So the question was regarding if we can do this with user namespaces No, but yes You can do mappings with user namespaces But so if we do use as namespace that basically means that when the user logs in we have to set up a user namespace for him, right? But if we do this Then this basically means that they live in a sandbox of their own, right? And I don't know I wanted to have this so good like that. I want to use it myself, right? I'm writing this for myself ultimately, right? and Locking every user into a sandbox right and where he lives in this world that is actually separate from the host Right where he lacks privileges because user namespaces are mostly about removing privilege, right? Doesn't feel right to me that all said I think eventually we should come to this mode where users are actually properly like you can said at least that users are properly isolated from The rest of the system right so that they don't live in the same namespace Not not the same file system namespace not the same user namespace not the same now pin namespace They probably should live in but so that they're actually truly isolated so we can introduce something Where users are truly something that we can have one day and remove the other day And because we know that the user always lived in the sandbox We can be sure that nothing remains on the system with the user ID it used other thing But yeah, this this gets into the sandboxing then and I didn't want to push people right now Just to use this into requiring sandboxing for all users because that is another step to breaking Unix The way we always have because right now if you log into Unix you get access to everything live in this namespace It's everything else. So yes, absolutely something we should do better use the namespace alone Have too many problems, but I'm looking at like yeah, maybe next year. I'm doing a talk about that. I don't know I think what would be ideal actually for this use case if we would simply you know The fat file system has this option where you can specify you it in git And then all the files in there are owned by this you in git It would be awesome if we have that same concept for the other file systems So that it would just ignore the uad that is stored in the file system We just at the moment of mounting would say okay I don't care about user ID ownership on this file system Just make it all belong by Lennard whose user ID one thousand and five on this system and then when you unload It's all gone again. So that would be perfect. I don't know if we'll get that Anyway, that's a question So yeah, so the question was regarding why not do a file-based encryption So actually this project home D that I'm talking about has a couple of back ends It has a back end the one that I'm trying to push people towards it Which is the Lux one that I mostly talk about here, but it actually supports the FS script as well FS script is the thing like xd4 implements is now that which is file a system level encryption E-cryptivest by the way appears to be dead. So you're going to use them for a while I think they even kicked it out of the distribution again, but I Inherently believe that if we say protect things with encryption we do should do so properly and FS script doesn't deliver that right like because I've asked script Encrypts the contents of files and the file names, but nothing of the metadata and not the directory structure So if you go into an FS script at home directory, you will see everything that's in there Except that you kind not might not be able to figure out what is what but you will still see the sizes Still see the end times you still see the ownership you still see everything else extended attributes It's all not encrypted and that leaks a lot of information Right like that leaks like everything. That's interesting right like for example If I want to know if you have a certain porn movie on your laptop I could just like because that's implicating right I could just look at the files that you have there look at the sizes And then I know yeah Larger files become into the less likely is as if I matches exactly bite by bite that it's something else in this right So metadata is information and that's information that we protect. There's also this other problem That on Linux file systems are generally not considered to be something Like a kernel file system implementation that are safe regarding rogue file system images I like the kernel people who work on these file systems generally say if somebody prepares a file system that claims to be x4 and that is That is like badly laid out The current people refuse to accept that it's their duty to make sure that the kernel doesn't like hang or or Even sack fold or something like this, right? So I mean this would be great if they would actually care about this So but this means that we need to establish a certain level of trust Into the file like into the encrypted stuff Before we unlock it for the user right like because again I want to come to this model where you have USB stick I can put it into this laptop into another laptop But if we would have the file system at the bottom layer unencrypted right and then the encrypted files on top this basically means I still are able to to Exploit the kernel with a corrupted file system as much as I want because there's no authentication step done before the file system is accessed but by putting the Luck stuff below it. I know that yeah the kernel will only start reading the file system after the authentication happen So it's a little bit of a protection for me against this problem. So yeah Everything but again home desupports FS script right like if that's your cup of tea go for it But I have a suspicion that FS script was was created for different purposes like it's a Google thing And they have the thing they use it for basically on the apps level every app like as my understanding every app on an Android uses FS script for its own storage stuff Then it doesn't matter not that much that you see the entire metadata But the way how we do home directory is millions and millions in file. It's too bad to leak that metadata So I think it's a slightly a also Android is really interested as I understand that when there's pressure on the disk on Android devices That they can go through these encrypted Files and directories and delete stuff because that's what you can do with FS script right like without knowing what what The any crypto keys you can actually go there and remove files And you will never notice like if you care about this but even that property alone is something that I think is not okay for our Classic Unix home directories because it should not be possible to make modifications just like that without us noticing that so Yeah, there was this thing that you ideas you might have multiple of them like I mean on Unix you don't write like in Unix The user ID is the kind of the concept like a lot of but even that I'm talking Immersely about something that's called home D right like home D is an ad on component that you can use if you run system D Where you can also choose not to use right like it lives by side by side with classic Unix records Right, I'm not to actually taking away classic Unix records for you If you have a user that was created with classic ad user by all means continues to exist just works fine, right home D Can manage users for you, but then you have to create them through home D And then there's explicit home D users and we make special restrictions Like we make this restriction that a user has a user ID and it's bound to the local system And it has a validity validity to this but yeah, so it's clearly in an on component that offers Optionally a couple of additional users to the system, but does not enforce any restrictions on whatever else you have in that right So the question is regarding Putting different containers for each user I don't know what a container is a container is many different things right like an and a docker container as a Some thing about services so You know containers about delivery of stuff which doesn't apply here. It's about sandboxing We just apply here really easy like we had discussion earlier right like So I don't yeah, I mean, I don't know what a container is I mean in a way you can see this as a container right like because we unify everything that is Known about the user and his his resources in one file that you just dropped into slash home So is that a container? Maybe that's a container Okay, so yeah, so the question was regarding right now in classic Unix if if you're rude You can change every user's file including the passwords and like everything in this world. It's not that way right in this world Unless the user authenticated his data is locked right like the system can't do anything It's basically the moment you type in your password That is the moment where trust is established where you have the user trust the system enough to supply your password And at that moment the system can access it and when you log out I want the strict rule that the passwords all flushed out again This stuff is locked again, and then system loses access right so this is like you know at the moment of log in Yeah, that is really clearly defined in my system where trust is given to the operating system to access my data right like because we live in a world where we can't trust the stuff anymore and If I take my USB stick plug it into another laptop, right? I need to trust the level to a certain degree that it doesn't do bad stuff with my data And also that system needs to trust my my device to not do bad stuff with the The system right so that I clearly define that the moment of login is where this trust is established in both directions But this has interesting implications by the way because cron jobs Sorry because cron jobs generally work without without being locked in like in this model cron jobs Do not exist because cron job basically mean that system Runs stuff on your behalf while you're not logged in while you have not supplied the parts whatever right this model I think yeah, I don't think this trust model is this where we should be going like I want to have my data protected when I'm not Like it locked in I want to really be sure that when somebody steals my laptop There's no stuff running on my data and it cannot change anything and cannot leak anything and that means no cron jobs Okay, good point. So the the question regarding was on multi-user systems like where you have centralized I presume centralized user manager right the questions how this relates to this because people forget their password, right? So Yeah If people forget their password there, sorry, you have a problem. It's the same thing for for For I mean it's always the same problem like if you use full disencryption you forget the password I'm sorry you your problem right like you want to get you can't get this back the instance. We want trust People need to remember their security credentials. It's not as bad as it sounds though because I don't know We need to push people towards you providing a security credentials that they cannot forget like a Windows does the same thing By the way, so what Windows does actually is if you authenticate you and you bridge this password They offer you a recovery key. I think recovery keys is a second password ultimately, but they generate instead of typing it in so if this is kind of what we have to do that we have to to to Divertify and make sure that there's not just bound to one thing But you have the recovery key and maybe have the Yubi key and if you affect forget one thing But yeah, but ultimately, I mean the same thing with your phone if you the phones are not as encrypted if you're guessing pattern you lost Yeah, okay a slide about this, but I don't I only got like to like Couple of more things to go through so let's just go on with the slides a bit because I don't have that much time anymore So home these The big thing that I wanted to go for and it's kind of a laptop focus But actually there's all this work entries two new concepts one concept is the Jason user record stuff Which is the supers of NFS and that's query will buy a violin interface violin is some local IPC And it's convertible force and back and this looks like this I mean, I'm not gonna go through this but I came most of this kind of obvious, but not everything like Yeah, this is actually work like username. That's actually the user name Last change using is what you think that it is It's like the next time stem was last change nice level is for example properties It just sets the nice level when you log in member of is yeah The groups this user shall be a part of and then there's this binding thing This binding thing is actually that binds a specific user record to the local system It's something that is retained only on the local system And that adds a couple of other things like for example in this case We say that the home directory on this specific system is x4 blah blah blah blah blah So it carries a couple of more data and the most interesting minus this one at the end because it says basically on the system was this machine ID this user gets the uid 16 to 3 2 right so I don't want to get lost in explaining everything here So we're gonna go through this but yeah, there's also the Etsy shadow information Which is like in the privilege section and there's a cryptographic signature because I think it's inherently important to be able to sign user records Because you want to control which users can log into which machines and it's particularly important if you do the USB Sticks thing actually because you don't want to allow every random user to plug a stick into your laptop Or maybe some people do but most of them probably don't And use it so you want to actually have restrictions on what that is and that basically means that user records need to Be signed so that systems can decide which user records to to accept on which ones don't And then there's concept B that we added that's actually the home D thing right like so that's something where we do then crop it luck stuff with loop x files And we're basically have one files called home foobud at home The Jason records the concept a is actually embedded in this including in the file system itself And that is the existence of that just synthesize you as a full this part is managed by system you home D So these two concepts are Somewhat independent the second concept home D Relies on the first concept, but not the other way around so if people like if LDAP Installations want to be able to make use of the resource management hookups and all these kind of things like having extensible user records And so on concept a is what they can hook it to it's explicitly designed to be extensible for them So first of all they can provide this user record data and secondly they can consume it and Yeah, it's it's can live side by side the user like so yeah home D is one provider of this metadata but it's not supposed to be the only one and These other subsistence can extend the user records to their taste like I would expect back for example that the summer people just Introduce a sit thing and then that's the thing or the SSSD people or the elder people do whatever they want the Kerberos people do whatever the one and it's explicitly supposed to be extensible home D Bills on this and is one provider of these things with very clear semantics having a couple of back ends, but yeah independent so How's this all implemented there's integration with the West there's PAM system D Which enforces all the settings that you do per? Session from that is encoded in jason records the system you log in D That enforces everything that is for the user the moment you log in like all kinds of resource records And yeah I'm gonna skip over this because I don't have that much time Because I want to do more questions Yeah already mentions briefly the user records are signed For me if like in the home D context, I don't consider signing an option. It's mandatory and done by default, right? For all the other providers, it's an option like they can figure that if they want this or not It's fine. If there's a local service that provides user records like this It doesn't have to sign it because just by having the privilege to make it locally available. That's enough to be able to trust it Yeah, it's mostly about control who can log in where there's also by the way in a concept of automatic update propagation So if you have a central system that controls your users, it's capable of generating these user records You can propagate them on the individual machines and they get instantiated there And then you say you want to update them from the central thing It kind of goes to the question that you guys had there then You can basically a central Host that originally generated these user records can generate updates can sign them again There's a there's a last change thing to make sure that down rates aren't possible Propagate them to the individual systems and then consider updates to the user record now as mentioned before Because there's actual data is encrypted with your password if you actually change the password Essentially, we cannot change the password because we don't know it the way this is handled is then if you log in and the user record One says one thing and the looks data says another thing you have to authenticate with both passwords so first of all we get asked for the User record like the data that's actually in the newer user record and secondly you have to supply the password then again It just will just prompt you a second time say. Oh my god. Yeah. Thank you. You have authenticated against you the Use a record, but now I have to actually set up the Lux device for you That's a different password. Please supply them. That's in the previous one The moment you have done that will actually update the Lux stuff so that for the future ones You don't have to do this so there is a scheme how you can centrally do this But it's it's the rule is still if you forget the Lux password you can't get it anymore, right? But again, this is like in in in in all of this stuff We try to get away from having a single way to authenticate to having many ways to authenticate, right? This can mean multiple passwords. This can be multiple Passwords and multiple recovery keys. It's called be multiple UB keys and multiple whatever else you want to use Yeah, I mentioned briefly PKCS 11 support that's UB key stuff And what's important is that we do it properly, right? Like we actually use a smart card as a smart card and we derive the full encryption to change from it How do you use it? There's this home control tool if you use that you can create a user You can activate the user that basically means mounts his home directory to ask you for password or UB key You can resize it Which does what you guess it does it just takes home directory changes to three gigabytes. Can you change the password? If you can enroll UB keys all these kind of things Yeah, this is the interface to concept B home D But it's also user interface to concept a the providing and definition of the user records that has a different tools called user to be control Yeah, you can query user create group You can create your memberships and couple of other things you can query many way which has provide this But yeah, if you are an elder user and the elder people hook this up with this this tool would all work for you to query It's like like get and pass WD a little bit more more modern because it can do the Jason stuff By the way, I talked to the SSSD people Like to a couple of them actually at this conference and before and they're actually on board with this mostly with the Jason stuff So the hookup to the stuff is relatively simple. So hopefully in a version soon We'll see that SSSD will actually provide this data for us And that basically means that from LDAP you can do resource management And for the first time and log in D and system D will enforce it all for you Which is something we never could right so but the key takeaway is these things are separate user to be home D Home D matters is one thing mostly use case for a laptop and very independent very Nomadic use case, but the user to be stuff is generic and is inherently designed so that other providers can hook into this too In particularly LDAP SSSD whatever else Yeah, this is actually implemented two different services to be home D and user system D user BD Let's skip over this. Let's just do questions Yes, so the question was regarding if I have a user Like a like a user home directory can I declare inside of the metadata and on which users on which systems You can you can log in yes, you can but of course the systems are the ones that enforce this right But there's actually mechanism for this. So basically you can say Like there's a permit per machine section in the user record defined the Permission section is keyed by the machine ID and then you can basically even do stuff like on this machine I can log in And I have five megabytes of memory on this machine I cannot log in on that machine I can say I get this much CPU and things like that So you because I mean resource management is inherently something specific to a machine So we need this permachine stuff, but we go forward through the whole way You can even do stuff like oh at this machine you can always log in but at this time you like on that machine You can't between whatever else but yeah, so regarding what if the encryption is depending on the machine that you're using, you know Either use the record if you have to use the record just adjacent stuff You can instantiate it a couple of times if you like and then this basically means that you take the user record You generate the user directory format, right? You can do it on this laptop you can do it on this laptop and that laptop then you have three different loop back files And it's all fine, right? But if you actually then take the loop back files take it from one laptop to another then yeah Yeah, I mean the security issue we always try to address with signing and things like that because as I mentioned I Emphasized this earlier about establishing the trust thing that that yeah The home directory needs to authenticate to the system and the system needs to authenticate to the user directory to some degree to make this in any way Workable so the question was regarding sharing stuff in your home directory With other users because I mean the UADs are not stable So they are actually stable so the way there's currently implemented because we don't use the username space stuff the And all these kind of stuff is that the moment you log in We do the churning and we actually leave around on that specific System a binding that says that this specific user right has this specific UAD and it's never removed again We can't do this like the remove we cannot remove unix users at this point because the users can create anything in any file and then these files stay owned by the user ID and then if the user ID gets Reused somehow they would gain access to the wrong stuff. So if the you have two users and they want to share data By all means they can do this. They just have to log in once so that they get the user ID assigned But from then on it's totally stable Yeah Again, it's not possible to share files while you're logged in because your stuff is locked down that are all sad one of the things that I actually want to do is like That you know the lingering feature of log in control right like a lingering That is implemented log and deep basically means that the system like the system User like this user services actually can start a boot instead of starting only when you activate and I have this like on my to-do list that we actually So like me right now with the home way home home deworks This isn't supported right like because we cannot start it earlier than your log in because then you wouldn't get access to this But you know we ask for for passwords like for passwords during boot all the time like for example if you use full Description right so what we could do basically that if you turn on lingering for one specific user The behaviors like how it always was that you boot up and then you get this prompt like hmm user foobar Was mark for lingering please enter his password to continue booting then you type this in and then it stays running for the whole time Without you being locked in but of course I mean the rule is still unless you provide the password no access. I don't get it Why do you have so different? And I like the way how like the question was regarding backups how that works like Like you know that depends how people want to implement backup like for example They could just do back out on top of it right like so that it only runs after you authenticate it But they can also do it below of it right like because we unify the user in one file Right like it's most unique thing by the way in the world because everything's a file right like so suddenly the user becomes Comes a file you can just take the whole file and make a copy of it And if the backing file system actually is XFS or butter if acid supports refling You can do awesome stuff because you can just do a CP that it basically free because of the refling And then the moment actually changes only the block that actually change could duplicate it like copy and write stuff, right? Well, I mean so first of all the user record actually is copied to at least three places The user record retains retained on the system. That's part because we need to pin the uad to the user mapping It's inside of the home directory and an identity file. I showed this earlier, but it's also a third time available in the in the Encrypted header of the luck stuff so that we can verify it before we actually Mount the file system because I mentioned these discussions earlier. So we already should keep three Backups of that stuff for you at different places with different semantics and different life cycle stuff If you want to back out a couple of more times, that's totally fine But the user record actually is retained in unencrypted form on the host system after you logged in once Does that answer your question, but maybe I didn't understand your question. Yeah, but you know Okay, so the question is regarding like file based backup algorithms. They will see that the entire user loopback file that is there Changes chain completely and then you would always do full backup So there's this wonderful thing called the rsync algorithm right like everybody here knows our thing right when people don't know so much Is that the rsync algorithm is actually extremely smart what rsync does it actually compares files? Like when it sees that the m time changed so that the files superficially changed right it goes to the files on the Source side and on the destination side like on the backup side Chunks it up in blocks compares block by block if these things change change and only transfer the stuff that actually changed It's inherently very compatible with this method of operation because If you have the home directory as the whole right and then you log in change a couple files you log out It's only the blocks of the file system that actually you touch that will have changed So yeah, our thing is your solution there and I mean most people probably use it anyway So it's actually inherently compatible So if you so if you change your password right like you know, you know how looks works Right, it has a volume key that actually protects your data And if you change your password, it does never affect the volume key, right? So what you will see changing is the luck setter that is at the front of this home directory file What you will see change is the identity record that we have in the luck setter as well That is ours like we extend the luck setter there what you will also see is that the embedded? Identity record that's on top of the file system will also change and you will see these three like you well basically like if you compare The before and after of the block image you'll see basically changes generally in three areas, which are these three areas? I think my time's pretty much over but if we are not being kicked out Well, it's a good it's a very valid question. So it depends on policy ultimately, right? So I'm supposed to repeat the question So let me repeat the question. So the question is regarding like if we lock this thing down so much what happens if you he leaves his laptop at the office and it's Unlocked if you can then SSH into it and what happens if it's if it's screen locked Okay, so then yeah, so the case where you're not locked in where you are locked in but it's locked and where it's active so as you know, yeah, if it's active you can log in if You're never locked in no way Right again somebody has to provide the password right then if you have locked in once Yeah Wait, well again, I mentioned this earlier like with the SSH stuff What we could do if SSH was nicer to us in a friendly way that you log in once via SSH Then it does the SSH authentication and then we got into control and ask you second time So what's the actually though your real password then you supply that then unlocks everything This doesn't work as as nice as works. You can work around this like for example by creating a stub user that is classic Right, you look into that first Then use home control activate to provide the real thing that unlocks and everything's good, right? But I definitely have the intention to make this Sorry Yeah, so I Would really love to fix this problem properly But we have inherently this problem that you know, we use Pam the Pam hooks Yeah, I'm mostly out of time if it's okay. Just finish that So we use this Pam stuff which allows you to hook into the authentication phase that happens there And the Pam thing does not allow us to ask questions after authentication completed Basically, if it did that then we could make it really really nice right like then you would SSH into the machine You never locked into right then as his age would do its thing And then you would just see this the next from which is the real password that unlocks our stuff And then you would never notice it And then then then after you activated once and then stayed locked in if you do this again and again again The second question will never be asked that but then if you log out completely again It will be flushed out again You can be sure of that and then when you log in then again you get asked the two questions again Follow what I mean So but again, we can't technically do this right now because Pam the way it's used by SSH Doesn't allow us to ask questions at that part-time where we actually need it It's a limitation of SSH in the implementation It's not a it's not a not impossible to do right But it would require us to first do a little bit changes in SSH, which I didn't want to do but yeah Yeah, but the problem with keyboard acting the interactive only works for authentication and we need it later Because the authentication already took place like basically SSH doesn't do keyboard and yeah, I don't know Yeah, but yeah, you can turn on the keyboard integration and it works better But I mean who uses and keep on interactive on SSH. It's kind of defeats the point of SSH, right? So anyway, I don't have any time anymore if you further questions Let's do this outside and thank you very much for you