 Good morning. So we're going to be discussing the Linux integrity subsystem. And the question is what is the, what comprises the Linux integrity subsystem. And it's basically, there's two parts, there's IMA and there's EVM. And then it's dependent on a number of other subsystems, some of which were developed specifically for this use. So the other ones are trusted and encrypted keys. And, and Dimitri upstreamed, he wasn't the first one to attempt it, but his, he upstreamed the MPI library used for signature verification, the MPI library. And of course, the TPM. This, the talk will mainly cover the IMA overview section and the recent developments at the very bottom. And just for completeness, I've included the uses of IMA, IMA measurement to be specific, and the namespacing when we eventually get to namespacing and what the direction will be when we get there. So the goals of the integrity subsystem really have not changed. This is straight from the wiki. And I believe Dave helped define what the goals of the subsystem are. And the goals are to detect if files have been accidentally or maliciously altered, both remotely and locally, to appraise a file's measurement against a good value. Store it as an extended attribute, and to enforce local file integrity. And there's a white paper from Dave with the URL at the bottom. So the goal of detecting if files have been accidentally or maliciously altered correlates to the first IMA measurement. And it's pointless to ask the system if the system has been compromised. If it's been compromised, it can lie to you. So we don't, we need a method without asking the system if it's been compromised. The second and third goals, appraising a file's measurement against a good value and enforcing local file integrity correlate to the IMA appraisal. The good values are either a file hash or a file signature are stored as an extended attribute. And we use a specific key ring to say which keys can be used to verify the file's signature. And as a bonus, Peter Moody had defined IMA audit. And IMA audit augments the audit subsystem with the file hashes that are calculated. It's used to assist in the analytics and forensics, but we'll have a bigger picture of how all of this comes together. But the first thing is instead of hard coding or sprinkling policy throughout the kernel, IMA has a single file which is used to store the policy. And that policy on the left-hand side, you'll see the policy on the right-hand side, the correlating pseudocode, which is the crux of IMA. You collect the measurement, which means you calculate the file hash. You store the measurement in the measurement list, and you appraise the good value based on that file hash that you previously calculated. And you then use the file hash to add audit records. So the reason that I used, this is a simple policy, and the reason that I used this policy is because if you're enforcing the file appraisals on your system and there are no keys or there's no signatures, well, then your system might not work exactly right and it might hang. So by using the Kexec kernel hook as the example, you can try and use IMA appraisal and use the measurement and audit to see what is actually happening without not too much affecting your system. Basically, the worst that will happen in this case is that you won't be able to do a Kexec because there was no signature or no key. So these concepts aren't new concepts. We've had the concept of secure and trusted boot for a while. In secure boot, each stage of booting verifies the signature of the next stage before transferring control of it. And what's included in the next stage might be keys. And on signature verification, the boot fails, which we just said previously. In the case of trusted boot, each stage of booting measures the next stage and adds the measurement to the event log. In the case of IMA, it's called the IMA measurement list and extends the TPM before transferring control to the next stage. So in this diagram, we show what is entailed in order to verify signatures. This is the appraisal, this is the secure boot, the equivalent of extending secure boot to the OS. So in order to verify signatures, we need those signatures. There have been two talks in the past. The first one was given by Stefan Berger and Mehmed Caleb in 2016, an LPC talk. And last year, Matthew Garrett gave a talk on signing Linux executables for fun and security, also at LPC. But the main idea is that we need to be able to distribute file code and file signatures together. And in order to do that, we've modified RPM. And that's been in RPM and upstream for a number of years. And we've tried numerous times to do the same for Debian packages. The first time I did it by modifying the SHA-1, at the time SHA-1 file, SHA-1 sum file, with just including the signatures there. The second attempt was by my colleague, Stefan Berger, who modified the version of tar that they had didn't in the package to install the packages, did not include extended attributes. So he modified the tar to include the extended attributes. And more recently is the mTree version by Matthew to store the file signatures in the mTree. As far as I know, none of these have been upstreamed and are not yet available. So assuming that we have that the files are distributed, packages come with file signatures, there will be different use cases as to who does the signing, who accepts what key. Sometimes you'll want it from the distro. Sometimes you'll want to redo it on your own to limit what can actually run on your system. And you would do that based on re-signing the files for more of a key granularity. So as we said, IMA is based on policy. So the first thing that you need to do is define a policy. The appraisal, which itself should be signed and would only be loaded if the signature verified. So these are a couple of the built-in policies. You have appraised TCB and secure boot. But all of these policies are overwritten by a custom policy that you can define and can load on the system. So digging down even deeper, we now have that we protect the file data. IMA appraisal protects the file data. And we showed that it's based on the file hashes that should be distributed with the packages. But we didn't say how that is protected. How the file metadata, the file signatures and hashes are protected. And that's when we come to EVM. So EVM protects the file metadata based on an HMAC or signature stored in the extended attribute. And the HMAC, normally you would use a trusted key that encrypts and decrypts encrypted key. These are two new key types or these are two separate key types that were developed for this. So once you have the file data and the file metadata, you need to bind the file metadata to the file. And the original way that we did this, since we weren't requiring security ex-adders, but we wanted to protect the security ex-adders. So we tied it to the inode information. And by tying it to the inode information, well, then it's tied to a specific inode on a specific file system. And the only way of getting that information onto the file system was by flashing it or signing it locally on the system. So recently, this past year, there's a new method that's called the Immutable and Portable Signatures from Matthew. Thank you, Matthew. That ties it. We've removed the identifiers, the file system specific identifiers from the HMAC calculation and are now dependent on using the security dot IMA. It's now an accepted, it's there, and we assume that it's being used. So it's not that difficult to include the security IMA and require it. So this is the new way of binding information. And at this point, you can now include EVM signatures in RPM packages. So originally, originally, originally, we had, for mutable files, we have mutable files by definition can't be signed because if they are signed, well, they're not going to work if you change them. So you can't verify the signature on files that are changing. So first files that are changing, we hash them, and in EVM, we use the HMAC to protect them. So this is really an offline protection, and we're dependent on the access control, either on discretionary or mandatory access control, to do the gating and to do the enforcement. So whereas with the mutable files, these are files that aren't changing, these are files, these are your executables, these are your libraries, these are things that you can sign, and it's fine. You can sign them with an IMA signature, you can sign them with the EVM signature, and I assume Matthew will be going through more of that. Originally, the keys to verify these signatures were on the IMA and EVM key rings, and those key rings were created by user space and loaded originally by dry cut onto the key rings. And we want these keys loaded as early as possible in order to, well, first of all, we need to be able to verify the signature. Of the policy itself that's going to be written. And so it needs to be done as early as possible. There's some security implications of using user space key rings, but these are okay if you're doing it and locking them in the NITRAM FS. But the preferred method would be to use the trusted key rings. And the trusted key rings are created by the kernel itself, and the keys are once again loaded by dry cut if you're using dry cut. And if you have a policy, we haven't gotten to how you specify a policy, but if you're using SeLinux and you're defining a policy based on SeLinux labels, well, SeLinux is loaded late. And therefore it's deferred till after the SeLinux policy is loaded, and that would, which is done by system D. So if you're not using SeLinux labels, then, or any other labels that are loaded, policies that are loaded later, then you can still use dry cut to load, to load the policy. The other thing about the EVM and IMA key rings, the trusted EVM and IMA key rings, is that keys that are loaded onto this key ring need to be verified. And they're verified, we're extending the secure signature chain of trust. We have the signature chain of trust from pre-boot, and now post-boot, we're going to pivot that chain of trust to the built-in keys that are signed in the kernel, such as the kernel. And then we have the internal module keys and any other keys that are loaded that are part of the system. So this diagram basically shows that you have the local CA key, and it's used to sign other keys, and it can be used to sign third-party keys. And the question is, how can we get this local CA key onto the built-in key ring in order to verify the keys as they're being added to the IMA key ring? And this is the same goes for EVM. So there are two methods currently. The first method is just like the kernel modules. You build them into the system. This is the simplest. If you're building your own kernel for your own use, then you just build them right in. There is a configuration option so that you don't have to figure out where the dur file is, and you just define where that file is on your configuration. Otherwise, you can just add it to the module's file, the module certs file. The second way is by reserving memory for the key. So suppose that you want to run a stock distro, you don't want to build your own kernel, and you want to insert a key. So we have a method for inserting a key into the kernel. It's kind of upstream. The initial patches were upstream, but there are a couple more that make it more usable and fix a couple of problems that were found with it. Those have not been upstreamed. And for us, I work with a development group that separate out the people that build the kernels and those that are using the kernels that are built for them. And this is a simple method for them to be able to use test keys on a kernel that is built that's already been built for them. And then once they're ready, they install the real keys before they release. And so they've already tested the kernel and everything is in place. So there's different use cases for being able to embed these keys post-install. Once you've installed the keys, obviously in order to there, you've modified the file, you've modified the kernel image. So you therefore then need to re-sign the kernel image. The third way of being able to verify keys to be able to put them onto the I'm a key ring is not by adding them onto the built in trusted keys, but by adding it to the secondary key ring. And there are out of stream patches that do this. But once again, if we're trying to have pivot the trust of root and if we bring in all the keys from UEFI, for example, then you're trusting everything that has been run up to this point and you might not necessarily want to do this. So from my point of view, this is not the most optimal way of loading keys onto the I'm a key ring. So we saw that we need the signatures. We need the keys. We need a policy. And this is a lot of setup. Unlike I'm a appraisal, we have I'm a measurement. And I'm a measurement for extending this trust to boot to the OS, we only need an I'm a measurement policy. So if you look down below, we've highlighted TCB and that's one of the built in policies. And so all that you would do is start measuring. And even if you measure files that aren't, there's no signatures that are being enforced. So it just works out of the box. And you can define your own policy, your own custom policy. So what happens after you have this measurement list? We said we don't trust necessarily trust the system on which these measurements are being used. So instead of verifying the measurement list on the local machine, there's a way of if you send them to another machine and one that you do trust, well then you can verify those measurements. And those measurements can be then used as part of your analytics. It can augment your existing analytics with the file hashes. And it can also be used for forensics to know what has been run on your system. So when we talk about the I'm a policy, and the sample that I gave you was one rule for the equivalent measuring appraising and auditing the Kexec kernel image. But once we start talking about a full policy, there's a question as to what you want to measure. If you measure too little, then you don't know the integrity of your system. And if you measure too much, well, you can measure everything on the system. And if you're measuring everything, there might be memory pressure because the measurements are being stored in memory. And performance issues that of going out to the TPM. Now we've done a lot to improve the TPM and performance, but these are, so there needs to be a balance as to what you're measuring and what you're not measuring. Some of the new features that are being proposed might not retain the existing security goals that I'm an EVM provide. And you'll hear from other people who are giving talks about these new features that are being submitted. So when we spoke about sending the files to the remote host for verification, and this is done by the attestation server, I'm not going to go through because other people have referred to it, have spoken about attestation. What I do want to say is that there is an IBM, it might have gotten lost with all the talks that we've had this time here in Europe and in North America, that there is an alternative to the Intel TSS. IBM does have an open source attestation client server and an open source TSS. And this is one of the slides from the version that we have, the research version done by my colleague showing the different types of vulnerabilities that are detected. Not having a key, having a bad key, not having a signature and so forth. In terms of the IMA and where it's being used, and when I'm saying IMA in the general, I'm saying IMA and EVM in the general sense, and not specifically measurement or appraisal. They're being used on the host system and in the virtual machine. And the plan is to have the same features running in the namespace, but we still have some issues with how we're going to do this in a general sense, and not for all of the LSMs to go off and do their own thing, and have different ways of starting and enabling namespacing. So when we do get to solve this problem, the IMA will stage the changes, the support into the kernel. It's a major huge undertaking, and we're going to stage it so that the first thing that will get upstreamed, which has the least amount of other file system changes is IMA audit. And the audit subsystem, there's already patches out there, and assuming they are upstreamed, will already provide the container identifier for the audit subsystem. The measurement, on the other hand, requires a policy, and that policy requires virtualizing security FS, and different subsystems are using security FS. So there needs to be a way of only exposing the IMA material within the container and not leaking other information. And lastly, IMA appraisal, that requires even more changes, and those changes are for keyrings, and David mentioned namespacing keyrings. So we're looking forward to seeing that, which brings us up to the new features. So we've already spoken about portable and immutable EVM signatures, and these were done in this past year by Matthew, and the other piece is support for adding other security extended attributes. All of them, initially, it wasn't limited to security extended attributes, but for the time being, because only root can write security extended attributes, we're limiting it to root and to the security ex-adders. We'll have to look in the future as to whether or not we can, if it's possible, to include other ex-adders or other information as well. Okay, so on the first slides we spoke about the IMA policy. The IMA policy was limited to, it started out as a built-in custom policy, and they were replaced by a custom policy. We've recently extended this so that you can build into the kernel a build time IMA policy that persists after loading a custom policy. And then Naina and Tiago will be discussing an architecture-specific policy later. So I think I need to speed up. So we've closed a number of measurement gaps. One of the, actually in this slide, what we're speaking about is Iversion. So in order to be able to detect if a file changed, it required Iversion support in the file system. But that's really only a performance improvement. So instead of requiring Iversion, now if we don't have Iversion support, we just assume the file has changed because we have no way of detecting that. And unlike on the Fuse file system, the Fuse file system also doesn't have Iversion support, but we don't trust Fuse file systems. So the decision was to say if the Fuse file system was an unprivileged mount, we're only going to measure it once because it's untrusted. And when it's a privileged mount, we assume that you have other methods of deciding what you're allowing to be mounted by root on your file system. And so in that case, since we don't have a method of detecting when the file changed, because it doesn't go through the kernel's file system, this is all in user space, we re-measure it every time the file is opened. And there's now discussions as to whether or not we can support some form of file detection of change. And that's an ongoing discussion on the mailing list. So in 416, Demetri reintroduced an IMA specific lock to resolve the outstanding locking problem. And it was there for quite a while, and it caused a deadlock on XFS. And the other major improvement, as I mentioned previously, was TPM performance. And not only, even after we made the change of using the HR timer, other patches have been upstreamed, and now the performance, there's a major performance improvement with the TPM. So that when you extend the TPM, we can have more measurements and not be sitting around, you know, just twiddling our thumbs to wait to do the next measurement. And as I mentioned previously, we disambiguated the IMA audit records so that when namespacing is upstreamed, that it will just work out as it is the IMA audit. We have a new, the LTP tests were refreshed by, I hope I'm pronouncing right, by Peter. And we are working on a standalone version of the IMA test, which will be part of, which can be called out from LTP and XFS tests. That has not been released yet. So we're continuing to close measurement gaps. There are still a number of them out there that we haven't closed. And a number of these topics will be discussed in subsequent talks today. So how can you help by reviewing patches, by participating in new feature discussions, and because when new features come in, the features are being developed from one perspective. And we really need help with other perspectives. So don't be quiet. Please raise your voice if it will affect your perspective of how you're using the subsystem. And help with documentation, help with closing some of the audit gaps would be much appreciated. So a lot of this work, it's not only my work, and it's, there are other people that have helped over the years, especially my colleagues, my new, my current and my past colleagues. And also to all of you for your help and for your support in new features that are being upstreamed. Thank you, Mimi. So maybe we have time for a couple of very quick questions, a bit over time. And I also want to mention there is an email related both for discussion plan during today's lunch. So if you're interested, I guess you will go see Mimi to know where it's happening. So if there are no questions, let's thank Mimi for the talk.