 I guess my microphone is working and I think this might be the first time I've spoken at a security summit instead of being the emcee. And so this will just be a brief high level overview of Linux kernel security. It may be a little high level for some of the more experienced folk here, but we want to bring more people into the community and this is kind of I guess a bit of a level set and there will be more detailed drill downs into the various aspects of the kernel security framework in subsequent talks. So just quickly as mentioned I maintain the security subsystem tree which collects quite a lot of the security functionality to push to Linux, but security is spread out through the tree so the borders of that are fairly nebulous. It's really a community effort spread across many, many people, dozens of people. I'm employed as a kernel engineer at Microsoft. I work on, well they pay me to do the upstream maintenance and I also work on Linux security architecture at Microsoft. And previously I had been involved in Netfilter. I was the original author of the crypto API so I'm the one to blame for that API. I was involved in the original LSM development and I worked on SC Linux at Red Hat and prior to this role I was actually a kernel manager at Oracle. So I've gone back to more technical type of work. So I will just do a bit of a background into Linux kernel security which will help explain some of how it's become, the way it's become and why. And I'll go through at a high level some of the major components of Linux kernel security and then I'll include some resources for people who want to get involved or who want to learn more or contribute at the end. And these slides are actually up on the website if you go to the event page in Slides and have a look there. So the Linux kernel security model is based on Unix so it's well known that Linux was a clone of Unix and as such it inherited the security model from Unix which is fairly rudimentary. It's called DAC, discretionary access control and this essentially says that if you create an object and you own that object then you can set the security permissions of who can access that and the permissions are fairly coarse and it keeps it fairly simple. And it does a reasonably good job for when it was designed. It was actually designed in the late 1960s and implemented in the 70s. And it was actually a completely different culture then. You didn't have APTs, you didn't have the internet as we know it and there was also a different cultural factor at the time where people were trying to share, there wasn't really much of a concept and still today if you find an old Unix system even from more recent decades sometimes there'll be no passwords set on route so the systems would just be brought up and used by people. So one of the originators of Unix, Dennis Ritchie wrote a paper in 1979 called on the security of Unix where he did a very good security analysis. It's actually a good paper to look up and read because it also shows you how to go about doing security analysis. He was a very smart guy and this is where the quote comes from so this is how I found this paper. I was trying to dig up this sometimes repeated quote and he said that Unix was not developed with security in any realistic sense in mind and he said this fact alone guarantees a vast number of holes. So in 1979 this was the guarantee that Dennis made in that paper and I think that if you have been tracking Unix and Unix family and Linux security in recent decades you would agree that that lack of design. So one of the issues there is that in Linux and other operating systems that were designed in similar eras had to retrofit security with breaking the existing applications and that's been very difficult and in particular Linux is very stringent about not breaking user space so there are all kinds of amazing security models and security ideas out there and that have been proposed over many decades but for us in the Linux world in reality we have to ensure that we don't break existing user space. So one of the core issues to give a bit of a background as to why there are so many extensions and enhancements to Linux security is that discretionary access control is insufficient for modern security threats and this was outlined really well in a paper that was produced along with the original SC Linux project by the US National Security Agency where they were making the case for mandatory access control. I think it's called the inevitability of failure is the paper but essentially discretionary access control in particular doesn't protect against flawed or malicious code so if you own an object or if you own objects and you run a piece of code and that code is malicious then the DAC provides no protection against that. It also doesn't cover all security critical functions so original Unix security was based on the file system and inode permissions so for example with network facing demons there's very limited security functionality in the traditional Unix model and for example if you have a web server listening on port 80 and that becomes compromised then it can be quite easily turned into a mail server to send spam around and discretionary access control really has no impact on that and also in particular if it's running with privilege then it will have access to all kinds of things that it doesn't need usually under DAC and the other aspect of DAC is that the super user or the root user can essentially do anything and this actually violates the security model that you've implemented and so in that same paper Dennis Richie pointed this out and again I would say this very smart guy saying that if you have the notion of a super user then it's a theoretical and usually practical blemish on any protection scheme so that historically the amount of problems we've had with privilege and super user escalation is significant so that that forms the I guess the background is to then how we've had been involved in retrofitting security extensions to Linux to meet the requirement for the modern era and the 21st century even the parts of the 20th century so some of these components include closets apples access controllers so this essentially takes what's known as abbreviated apples in the Unix DAC model and makes them fine-grained so then instead of just having user group and other permissions you can actually specify which particular users which particular groups and it's much more fine-grained and that is still discretionary access control so it's more flexible and more fine-grained more complicated but still has some of those fundamental issues and POSIX is that I think this was based on an early POSIX standard when there were standards in Unix draft standard so Casey Schaeffler here the smack author was involved in this this work we also have Linux capabilities or POSIX capabilities another draft spec and so for people coming from other operating systems this is this is actually called privileges in in some other operating systems and it's not the capabilities that you may hear of in other other areas of computer security so it's unfortunately a bit of a namespace collision here so the capabilities POSIX capabilities essentially attempts to deal with the super user issue by decomposing the super user or decomposing route into a set of high level abstractions such as network admin sys admin being able to bind to sorry open and access raw networking sockets to craft packets for things like ping this is process based and initially the initial version of capabilities you had to assign it to assign these capabilities to the process as it was running and being launched later on it became much more useful when file system labels were attached to capabilities so typically with capabilities you'll have a privileged app such as a mail server will start up do all the privilege things that needs to do and then drop the capabilities and that sounds great but that is actually more has actually led to some security issues itself quite famously we're also not quite sure exactly what some of these capabilities mean they've just been sprinkled throughout the kernel without a kind of a centralized design so people make a best effort so I remember when I was working as a networking developer you would just use cap net admin if you did anything privileged or thought it might be privileged so this has been implemented by kernel developers and they've actually done a reasonable job or we've done a reasonable job but it's a little hard to reason about what sort of security may really have and it's it can lead to privilege escalation you don't know where the boundaries of your privilege are if you have a series of executables that you launch the different capabilities you don't necessarily know exactly what you're going to end up with and it's difficult to analyze and it's still a form of discretionary access control so there's an audit subsystem in the kernel and this is implemented to help meet government security requirements and one of the surprising things about this is actually quite useful so you can actually run audit to audit commands such as audit control to watch files for them being updated and so on so that's that's really well implemented and I say that because I know that in other operating systems trusted operating systems and so on you'd have this C2 requirement and I've heard that it was never enabled in the field audit it was just a checkbox so what it's quite useful it's integrated with the other security mechanisms set comp is a major advancement in really useful security in the kernel it's a kind of a generalized system call filter so for a process you can actually specify essentially a whiteness of system calls that an application has and it was initially started with I think three system calls the initial version of it and this was to do allow people to rent out computing time on the computers and you had like input read and write and I think like an exit system call so you yeah secret term yeah that's it so for four system calls and so was this Andrea again jelly made this and this was like your city at home type workloads are crypto key cracking things and I guess now you'd be looking at Bitcoin mining for that kind of thing and then it was extended to be a more generalized filter and it's implemented as BPF BPF filters it's really useful for reducing the attack surface of the kernel and by which I mean by what essentially whiteness in your system calls if there is a bug in a system call that you don't need and someone can get in and trick the kernel into executing say there's a T system call that had a bug in it it really blocks a lot of kernel exploits and I think the Android security folk have demonstrated this there if you look at the previous security summit in North America there's a interesting presentation on that and it's not inherently a sandbox on its own but it's certainly a useful component of sandboxing if you want to use sec comp don't try and use it directly that's like writing assembly code Libsec comp by Paul Moore here is a is a very good tool for that I think if you use Docker you'll find like a JSON file with with some policies some sec comp policies and so on so you can see how that works namespaces this is another significant increase in security although it's not inherently a security feature it just happens to be very useful so namespaces were derived from concepts from the plan 9 operating system which was the successor to Unix and what it does it allows a process to have private views of global resources and then a really simple example would be to give a process of private version of temp that nobody else can write to and then that will eliminate our entire class of temp race directories it's integrated into Pam pluggable authentication modules and containers built on namespaces with C groups so if you start combining say namespaces and sec comp and C groups you're starting to be able to do some interesting isolation and attack surface reduction there's also in the networking is the network net filter framework which has now been around for nearly 20 years or certainly about 19 years in development and there are some EPVF based work which looks to replace that in the near future but net filter is a set of hooks in the layer 3 the network layer in the kernel wherever the packets flow through it's abstracted out to input output forwarding and so on and then you can plug applications internet filter such as IP tables the cryptography API certainly has changed a lot since I was initially involved in it there are many different types of algorithms supported the synchronous and asynchronous APIs I was intended initially as a zero copy interface and that's why there's some perceived complexity there the support for crypto hardware and there's a user space API and it's extensively used by disk encryption network encryption such as IP sec key management and the integrity subsystem there's a key management framework and we'll be getting a hopefully a good update on that from David Howells soon this is about how the kernel manages keys key rings and tokens and each key has a set of attributes permissions owner and so on and there are different types of keys so you have per process keys for a user or a session and you have trusted keys which are the kernel managers which are sealed inside the TPM and that's a very good way of protecting the keys from being exposed through kernel vulnerabilities there's also encrypted keys which are similar but don't use the TPM and there's a user space API for interacting the LSM framework or Linux security modules is a pluggable framework that allows different access control models to be implemented and this was initially implemented in as a reaction to Linux's reaction to AC Linux being proposed and he didn't want to have a single security model being implemented he wasn't sure if that would suit everybody so the consensus came around to implement a framework where you could plug in AC Linux and other other security frameworks such as app armor so this is a hook API and you can think of it a bit like net filter in that you we have abstracted out where you have instead of packets you have just general processing of through the kernel and these hooks are race free so they're done in a in a place which is safe in terms of locking and they have all of the security relevant information available at that point and so this then allows us to implement security models which can be done safely and with with a wide variety of different types of policies so there are several types or several major LSMs these would be AC Linux app armor and smack and currently they can't be stacked with each other because they're too complex Casey is will be giving a talk about that and there are minor stackable LSMs which are stacked with one of the major ones so for example it would be typical that you would have AC Linux or app armor or smack with capabilities and and Yama which has just got a few few security features implemented in terms of the major security models security enhanced Linux is what's called a label-based mandatory access control and compared to discretionary access control this is has a centrally administered security policy so if you have an object you don't necessarily be able to you're not necessarily able to set the policy on who can access that and this addresses issues with malware and a number of types of security issues it has fine-grained general permissions so originally mandatory access control was associated with military type security models whereas AC Linux changed this to be more general purpose and it's implemented in fedora-based OSes and also Android smack is a simplified label-based mandatory access control system has a smaller code footprint and much smaller policy footprint and this is typically seen in the embedded space and in the Tizen project. App armor is a different approach instead of attaching security labels directly to objects the security is path name-based and this was designed for ease of use so that people would have unix like configuration files and this is implemented in SUSE and Ubuntu so we also have and that that's probably about the fastest explanation of all of those security models and LSM that you'll ever hear. Platform security is also an area where the kernel has been actively developed and this I would include anything that is a security feature provided either by the hardware or the firmware so we have things like TVM we have trusted execution environments extensions such as SGX the AMD memory encryption we also have certain ISA enhancements such as NX and SMEP so this is all supported in the kernel. There's an integrity management subsystem and within this we have the integrity measurement architecture and this allows us to essentially extend secure boot or verified boot to the OS so we can continue measuring user space components and they can be executables they can be config files and these measurements can be extended into the TPM and you can then perform remote attestation with that and you're also able to have digitally signed files and upon access the signatures are checked so that that's quite useful in terms of being able to verify that a system that you bring up does not have any malware persisted that it's in a known state. The EVM extent of verification module protects the security attributes so security attributes are extensions of the inode on files in Linux and they contain security information such as SC Linux labels, IMA labels, SMAC labels and so on including also POSIX ACLs and maybe a few other things sorry yeah so all of these are covered against offline attack and we also have some block level integrity checking we have DM Verity and DM integrity and this was implemented I think for Chrome OS initially and this actually checks a disk when you mount it and you start accessing it and the entire disk is essentially verified and then you you can use the load pin module to ensure that if you're loading kernel modules that they all come off this trusted partition. Another important aspect which has become more prominent in the past few years is kernel self- protection and this is hardening the kernel itself against attack several years ago I would say this was probably an area which was deficient in Linux and so I've had significant efforts by case and others with the kernel self- protection project and significant improvements have been made there and I believe case will be updating us on that and so some of this or much of this work is back porting or porting the geosecurity impacts work to mainline and that's been very politically and technically challenging on many fronts and the emphasis on this is the focus is on killing bug classes versus individual bugs so that instead of playing whack-a-mole with every bug that comes up it's like well let's get rid of this class of attack an example there of attacking getting rid of a class of attacks is like the temp race type vulnerabilities that you can get rid of by using namespaces. Okay in terms of resources the LSM mailing list has evolved into a place where many if not most of the kernel security developers hang out and discuss things there are some other mailing lists the Linux integrity mailing list also includes TPM discussion there's the Linux key rings and also out these are on the same kernel.org server there's also the OSS security mailing list which is a very good general security resource and that's an open wall and that's run by someone who is very influential in buffer overruns back in the day. There's a wiki currency.org where we try and keep information and resources please feel free to create an account and update that you know it's like with wikis they get out of date and people forget about them and they die a sad death and there's also a very good resource the LWN security link there if you subscribe to LWN you will have access to really probably the best best coverage of Linux security so I'm not sure if we have any more time but we're any okay I don't know if this works now so if I forgot to mention so if you have questions we can take one for Mike so please wave and I'll run. There's more of a comment the key rings mailing list isn't the Linux-key rings it's just key rings. Okay. Thanks. Any more questions? Thanks for talking. Another aspect about mailing lists so OSS security is the mailing list with about vulnerabilities and open source project in general yeah and kernel hardening is the mailing list for the kernel hardening efforts. Yes I forgot kernel hardening. They are listed at kernsec.org. Thanks. And similarly I didn't think it was mentioned on the slide but the Linux hardened IRC channel okay sit in for the KSPP stuff. Okay yeah I haven't been active on there so I think kernsec.org has stuff there. So what aren't we working on that we need to be working on? I think we still have some some progress to make in the kernel hardening yeah there's well case can talk about that but yeah I think what would be good would be to see more original research being implemented in the upstream kernel as well once once once the basics are covered there and that would be interesting to see what kind of new approaches would be good. I think really it's you know it's it's up to people to figure out what they need and what they want to see so you know I don't have a magic crystal ball of what people need usability can always security usability so that's not so much a kernel thing that's really integration thing. Being developer friendly not maybe the security community but like Linux kernel community is still not so it looks security friendly but I don't know how to work. Any more questions? Because this is still an overview so I guess more detailed questions will come when we get into each subsystem. So let's thank James.