 Felly yn ymddi David Howells. Felly mae'n gweithio'r byd? Felly yn ymddi David Howells. Mae'n ymddi'r Gweithgared Hat yn y 18 o'r ffordd sydd, yr ymddi'r ffordd sydd, yn cwp ymddi'r archi-tekty, ymddi'r cyffredinol ar gyfer amser. one of the things I've done is created a key management system inside the kernel. It was initially for managing tokens for the FFASFAL system I was writing. To make sure the code isn't too wasted, I tried to spread it around to all sorts of different things. Otherwise, it's just a big hunk of core memory that's not doing anything. Mynd i gael chiwyddiad i'r gael chi ddelchau o'r pryddedig gyda'r gael. Dwi'n cael ei ddau ar gyfer ar gyfer arbennodd, ac mae'n ddod o'r eu cynnigodd. Mae'r gael ar y brif, gallwch chi'n ei bod'r cyfrif, a'r cyfrif meddwl agor reall, I'll get that to you more than that later. So they used to manage the access control, so they manage access to this data inside of it, because they have ownership group and permissions masks that beyond the usual thing you expect of Unix, like user group and other, they also have a possessor permissions. So each process has a keyring, it has keyrings attached. If the key is in that keyring, you're allowed to use it using the possessor permissions instead of user and other stuff, which means you can have keys that only your process can see. Nobody outside that can see. It also manages the lifetime, so when the last reference goes, the key is automatically deleted and also keys expire after a while, and when they expire, they're automatically removed from the system, and the storage they occupy is reset before it's returned to the system to make sure there's no leakage. And also, there are user space interfaces that allow you to manipulate these things in various ways. For instance, changing the permissions, changing the ownership, moving them between keyrings, granting other people access. And there's also an upcall service, so you say, give me a key for... One of the things you can use for is you can DNS. You can give me a DNS token for... grandotcentral.org, and it will upcall to the kernel. So it will upcall to user space. User space will actually do the DNS lookup because I really don't want to put a DNS thing in the kernel. Let's do it. And then that will instantiate the key, and then when you get the key back, you can just read out the contents, assuming you have permission to do so. So the types of payloads you can put in these keys, you have authentication tokens for network file systems, cryptographic tokens, asymmetric keys, file system encryption, a variety of other things. You put passwords in, so there's a key type called logon key. You can put a password in... create a key, stick a password in there, in user space. User space cannot then get the password back out. You can use the key as a token to pass to, like, the sys mount, or whatever. So the key ID to use space then stands for the password, and it's just not extractable without cracking the kernel. So you can be used for DNS results. Now, you also use it for ID mapping in NFS and SIFs. So you use the up call to say to your space, I have this name or this ID. Please go and map it for this file system. And there's also a user defined key type, which you can store arbitrary data in, and Kerberus makes use of this. Unfortunately, I can't see how I can get my shell. I was going to show you some of this stuff, but I can't make it come up. Can you read that? Does it need to be bigger? So I can do things like add a key. So what this would do is add a user type, user defined payload key, which basically just takes a blob. The key is called foo, and the bob will be bar, and if you add it to my session key ring, that's what the attest stands for. So it gives me a key serial number back. So if I view my session key ring, in there you can see I've got a thing called invocation ID, which is from System D user manager, I believe, and the key I added. So there's a special type called the key ring type that is just a container for the keys, and it is just a key. So you can put key rings inside key rings, you can move key rings about using the same interface as any other thing. So I can then show you what's in the key, but I can just get it out. And then I can... So doing that, I've taken away all permissions on the key, so now I can't do that. And all permissions includes changing the... Actually, that should be fear, fear, fear, fear. Includes changing the mask, so I can't actually put the permissions back on again. So one thing you can do, you can set the permissions to, that person can read, and nobody can change things, so that person can read it, but I can still theoretically get rid of it because unlink doesn't require permissions on the thing you're unlinking, only the key ring it's in. So you should see that it's gone. And there are other things we can do. Once it's actually done, so what this should have done is gone and done an upcall. So it created a key, asked to upcall to the DNS resolver code, which then went and looked up an AFSDB record for grandupcentral.org. The upcall then put that back in the key and returned. And now the key got in a standard with that, and I can just print that out from the key. So those are the IP addresses that belong to grandupcentral.org. So I said that there are things, concepts called key rings, which are just collections of keys. Every process has access to, or pins, three key rings. The key rings are optional, so they may, if they don't exist, they're not pinned. You've got a per thread key ring, which only belongs to a particular thread, so if you've got a process of multiple threads, each one has its own key ring, and the other processes don't necessarily seem to... The other threads in the process don't necessarily seem to that key ring. There's a process key ring, which all the threads in the process can see. There's a procession key ring, which is inherited... Well, when you create a process, all processes of that forks also inherit that session key ring. And then there's a per user key ring, which processes don't inherit, but PAM sticks when you create a new session. So when you log in and create a new login session, PAM, PAM creates your session key ring and sticks a link in there to your per user key ring. Oh, you used to. But I've a feeling someone has changed PAM, so we didn't do this anymore, because I should see it there and it's not there. I'm not sure why that is. I can add my user key ring to my session key ring like that. There is also a persistent per user key ring, which lasts for a certain amount of time at once you've logged out. As I said, key rings have expiry times on them. And when the keys and key rings have expiry times on them, when they expire, the kernel garbage collector just goes and removes them. This is used by Kerberus to store keys and they persist for, say, up to three days beyond your last logout, which means if you leave a demon running whilst you've logged out, it still has access to your Kerberus keys until Kerberus keys have expired. So there's my persistent key ring. And then I can go on the list. What's in there? One mistake I did make was that if you look in the Proc keys file, all the numbers in hex are on decimal, which means that the interface requires the hex numbers to be prefixed with 0x. And you can see in there there's a key ring column that's called KRB. That's from Kerberus. I think it's empty at the moment. So the user space API is three system calls and a Proc file. So add key adds a key and instantiates it all in one go. Request key creates a key, then up calls to go. First of all, it searches for a matching key. If it doesn't find that, it creates a key and up calls to use a space to instantiate the key. And keycuttle is a range of other functions like unlink, link, change the permissions, change the expiry time, things like that. And Proc keys is all the keys on the system that you can see if I do this. So you can see roots can see a whole lot more keys, including some DNS resolvers, blacklist keys from a loader from the UFI database. And there's an asymmetric key at the bottom, which is the module signing key for this kernel, I think. And you'll get into that later. And there are two user space utilities that I provided. One is key control, which I've just been using. And the other one is a PAM library, which should be in the PAM configuration. So there. So that says to run the PAM key in it thing and to revert that creates a session key when you log in. And so that's inherited by all the children of the session. And the revoke argument says revoke the key ring on the way out, which means anyone that accesses it thereafter gets E key revoked as an error. So I said there's an upcall. The upcall runs the Espin request key program and there's a master config file and a place where you can put other configuration files that tell request key what to actually run. So it's just a program switch. It will look up the key parameters and find something to run. So it looks like that. So the operation create, for example, a type. There's a bunch of debug types, which you can just create things with. And you can see at the end the programs that you can run. Well, the program that gets run if the parameters match. Waiting for the current merger window is a patch to make this more specific. At the moment it just goes to the file first match, runs that program. This isn't actually a good way of doing it. Now it goes through all the lines, finds the best match either on with the, where the stars, the wildcalls match the least number of characters and runs that one. So current usages in the kernel include authentication tokens for the FS file system, doing caching in Slocups, doing NFS user to ID mapping and SIFS user to ID mapping. FS crypts, which is started with AXT4 to do encrypted files. And ecryptifes, which is something you mount over another file system. And it encrypts and decrypts GPGs encrypted files in the lower file system. There's an asymmetric key type, so you can see the number of keys. The second one down the Fedora kernel signing key, that's the one generated by the kernel build process. What it does, it creates a public key, the third RSA public key during the build process, signs all the modules and then deletes the private key, and the public key is compiled into the kernel. And then all the modules are signed with that, and so when the modules are loaded, it can check the signatures on the modules. There are a bunch of other keys loaded from the UF5, which erases some Microsoft ones and things in there. And these end. There are a bunch of special key rings, so you can see built-in trusted keys, secondary key rings. I'm not sure built-in rich DB keys. I think that may be for firmware, resolver, blacklist. The blacklist keys, which when we do a signature check, checks the... We look up the digest in the blacklist key if it matches. We say you're not allowed to load that module. Or firmware, or Kexec. IMA also uses the keys for similar sort of thing, but under the IMA, by the rodent directly. So the key-kill interface also offers a Diffie-Hellman operation, but what you do, you have to put a number of keys in... the parameters into logon keys and give them to the Diffie-Hellman algorithm, which can then go and do hardware. To do this through hardware. The provided... is TPMAX, some TPMAXS, available using the trusted key type. The trusted key type uses the TPM to unwrap, to seal and unwrap symmetric keys and then retains them inside the kernel. You can see the keys and can use the keys, but they're not exposed user space. You have a handle, which is the key serial number, but the actual key, the crypto-material you can't get at. The encrypted key uses a trusted key to unwrap further symmetric key. If I understand that right. There's a... Kerberos makes use of this. If I do... You can see a bunch of keys in that region. There. Added by Kerberos. Kerberos is here using the key ring as a... credential cache rather than using something in slash temp. OpenAir first uses it to do pag emulation. We don't like the mucking around of the group. The group ID lists inside the kernel. They now stick a key in your key ring. It's used to use a defined key with a pag number in it that the kernel can look up. The main thing about this is the kernel can access these keys. User space can use this to provide stuff to the kernel to use. Upcoming changes in this merger window. There are... a number of public key operations being added. Encrypt. Encrypt, decrypt, sign and verify. These will appear as key kettle commands. They will be available through the key kettle program. We've added two new parsers to the asymmetric key type. One is you can give it a pkcs8 blob. It will parse it and stick the key data contained therein. That's actually the asymmetric key, which you can then pass to these operations. You can't get the key data back out again. Once it's in there, it's in there. The other one is TPM wrapped asymmetric key. You create an asymmetric key somewhere, you wrap it so you get the TPM to seal it to wrap it in some encryption. You can then pass it to the asymmetric key using ADD key. It will be passed to the TPM to unwrap. But then the unwrapped stuff is retained inside the kernel. You can't get it back out. But you can use it through the new key kettle interface. Onto the future. Future developments I want to do. One is I want to make the permissions finer grained. I want to move join. One thing you can do is you can join a key ring and make your session key ring. This is generally a bad idea. It's one of the things I shouldn't have added in the first place, but it seemed like a good idea at the time. I want to make it so this is a separate control. You have to grant someone the ability to join a key ring. So that someone can't just go and randomly join a key ring. If they join a key ring, they get access to all the keys in that key ring. So I want to be able to you can say now you're not joining that key ring. Any other one is I want to make it possible to invalidate invalidation of a key without requiring right access to the key. Because at the moment I think you can do it with right access so you can do it with set access. And I want to make it so it's a separate one. So I don't have to give you the ability to modify the key. I don't have to give you the ability to change the permissions mask on the key. You can invalidate the key. What invalidate does is says the garbage collector get rid of that immediately. And then it's gone. Next time someone does a request for it it will then call again if that's the way they do it. I want to add more flexibility to the subjects. So at the moment you can do it you've got a user ID and a group ID. And whether you possess it or not. I want to be able to say that container can access it. Or that program can access it. Possibly I could do this with an explicit ACL. I have patches to do this. But it might be better to actually have a key kettle where you say a database grant grant this access to that entity. And then have the ACL built inside the kernel. Possibly so you can't get the ACL back out again. It just says yes you have this access and no you don't have this access. Notifications. I want to make it so you can find out, you can monitor a key ring or a key or key ring and find out if it changes. I have this mostly working. I've done it since it's a general interface and it can be used for watching super blocks mounts, apology changes, key rings anything. But as I said I've got it able to watch key rings at the moment. I'd like to demo that but I've got to compile the patches into my testing for the kernel on this thing. But another thing I want to be able to do is effectively use a key ring as an event collector. So you say watch that key ring any key that gets added to that key ring initially to that key ring is a watch put on it that comes back to this key ring. So you don't have to monitor every single key you add to that key ring because it could be quite a lot. And if a key is deleted or removed from that key ring the watch goes away on that particular key. Because all these watches take up memory to actually record. All I want to do is make it provide refresh notification. So notification this key is going to expire in 10 seconds or 10 minutes or whatever. So if it's your Kerberos key ring it says by the way your Kerberos key ring is about to expire. Your file system token is about to expire. Go and do something about it. And another thing I want to add is just a key change counter that you can read. One of the problems with the event notification mechanism is that you've got a fixed size buffer. And when the buffer is full something happened. Possibly something happened in this particular class. So put a counter on the key that says how how many times it's changed. So you can just go poll a lot. Namespacing got problems with namespaces in that keys may exist and be used across different namespaces. Does the up calls currently done in the root namespace shouldn't it be done in appropriate namespace for a container. And there are special key rings that are currently global but should be per namespace. For instance those three there should be per network namespace. Containers I want to be able to put a key ring inside a container that the container manager can use to provide authenticated access to the root file system and the component file systems inside a container. Without this thing inside a container having to do the maintenance of these. And also I want to be able to grant access to that container for that key. So you can put authenticated AFS or authenticated NFS root file system inside your container. But the person, the program inside the container doesn't need to do anything about keeping the token live because it can be done from outside. NFS wants you to use request keys to look up credentials. We've got some agreements on doing this. This is for the container thing as well. And you can find some further information. There's files in the kernel documentation new man of key rings and there's a get tree for the key utils. And that's it. So we can take a couple of quick questions. Thank you very much for this presentation. It's very good. I have one question. When we are using the trust platform module to store the keys it's stored in the hardware, yes? When we are using the TPM to store the keys it is stored in the hardware. So if you talk about the trusted keys and also the new upcoming stuff that's coming in this module you give it a key blob which the TPM then unwraps using a key stored in the TPM. So the key you're actually extracting isn't stored in the TPM. You give it a blob that's a wrapped key. The TPM unwraps it and then attaches that to a key which you can then use. Okay, thank you. But the unwrapped key data is stored inside the kernel not our direct access. Okay, thank you. Cai Engad, hello. Are there any intentions for key persistence across reboots? Explicitly no. Okay, thanks. Except for the TPM sort of thing. More questions? Thank you for the talk. I had a question about UFI keys. When you use secure boot public keys from the secure boot variables are automatically added to the key ring? In Fedora and Rail, yes. So it's something which needs to be done manually but by the distribution? We have patches but trying to get them upstream invokes a lot of argument, shall we say. An incriminations of security people hate it. Okay, unfortunately James isn't here. Otherwise you could ask him why. James bottomly. Okay, thank you. And Mimi hates it as well. Right. So we're going to be discussing the UEFI keys in Naina and Tiago. We'll be discussing it later in their talk as to what we're proposing instead of adding them to the secondary key ring at the moment. They're not on the built-in key ring. The built-in key ring is just for those keys that are built in and it's more than Red Hat that's using these keys. Other distros such as SUSE I believe is using these out of stream patches as well. One other thing I wanted to add when I talked about improving access controls one of the things I wanted to add in that is also what are the keys I would say you can use this key for that as well as this person can use this key. So you can say this key can only be useful for module checking. This key can only be useful for my checking. Right. Okay, so one questions. There's one over there. Remember I'll minimise running so I'll take this one. Hi. Any thoughts on integrating this with the crypto API for example have a crypto API set key variant that you give not a key but a reference to something in a key ring? It has been mentioned before. At the moment apart from trusting encrypted keys there is no session key support really in management in the key key ring stuff. And the crypto API is almost all about session keys rather than symmetric keys rather than symmetric keys. So at the moment the more or less orthogonal though I would like to add a general symmetric key handle basically that you could then pass through crypto routines if or whatever. It's just time. Okay, thank you. There was a question over here. And I think that's going to be our last question because I have to move to the next speaker. My question goes into the same direction. Not only passing a reference to the key ring from the key ring to the crypto API but also keeping the key in some hardware device on some stocks and then passing a reference to the crypto engine so that the crypto engine or the crypto API can make use of the hardware engine so that the key never has to leave the hardware. We talked about the internal crypto stuff. That's one of the things I would like to do at some point somewhere on my list. Do you want to make a mark? Okay. Even better. Okay, but let's move. Let's thank First David for a very good talk.