Gentoo Hardened
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Blas Izquierdo Riera, Francisco
This talk will be composed of two parts: * On the first part we will talk again about how the hardening features behind Gentoo Hardened work (this will be very similar to last year) * On the second we will explain the new features we have added in Gentoo Hardened since last year, how do they work and which are our objectives as a project for the incoming year.
 In the U-depth dark, please take that into mind. And we try to provide the best we can find in security to the users in Yentoo. And well, this happens before it's accepted to mainstream Yentoo. Why? Well, mainly because let's get realistic. Managing to users are risers. Managing to users want to have a speed. Managing to users use F1 switch loops. And many Yentoo users don't like the idea of being more secure in exchange of being slightly slower. And since Yentoo is about choosing, they also have the chance to choose to be more secure or to be more fast. So let's start with what's an stack overflow. Please, face up. Stand up, man. Put your hand here. And keep marking the end of the line. Because this is a, yeah. So first, when we want to do a function call, we insert some arguments. Let's say this, for example, could be echo. And this one could be hello world. Then we cut the function. So we have to add our return address, which is, where are we going to continue the execution of our code? And finally, we add some frame pointer and some local variables. The frame pointer basically points to here, approximately, to the start of the stack of the function that call it. Cool, isn't it? So what's the problem? Well, please stop pinging me. What's the problem? The problem is that we have, for example, if we have some local variable here that is a buffer, let's say, a char vector, start writing the stuff here, like the frame pointer, then the return address, then the arguments. For example, if we use skits. Because nobody here uses skits. Do you? You better don't. Well, he does, but he works in a bank. It's normal. So what we do here, instead, is put some random trust in the local variables that we find before our buffer. Put some random trust on the frame pointer, if there is, because we don't care. Put an address pointing somewhere around here. Put a lot of knobs, which is instructions that do no thing. And finally, put our Ebbel code that will remove the system or do all the other Ebbel stuff we want to. That's the classical stack overflow. But we also have to return to libc, which is mostly the same. I mean, we put some trust here. We put the address of the function we want to get called. Then we put a fake return address, because maybe we don't expect our function to be to return if we are using exec. And some arguments that we will pass to the function and will get passed around. This is the classical return to libc attack, which consists of returning somewhere in the middle of the library. So what's needed for the attacks? You need, for the classic attack, to be able to execute code on the stack, which is where you have your variables. You need to have access to which is the stack address. And you need to have access to the return address, so you can modify it and make it go to the stack. And for the other kind of attack, you need the function address you want to call. And return access to the return address you want to modify. And well, to the arguments, of course. If you have access to the first, you probably have access to the second one. So what's SSP? It's simple. We have this stuff here. It's called a canary. So when you modify it, you check before returning, which is the value of the canary. And if it's different, it's exactly the same as it happens on a mine. I mean, you know that the people that went to the coal mines with a canary? Yeah, if the canary dies, there is a tissue, and you better get the hell out of there before it explodes. It's the same. If this value is changed, something bad has happened, and we better kill the program before it does anything bad. So that's SSP. I mean, there is not much magic before the idea. What's the problem? Well, there are some functions, for example, in group, that try to write in the stack because they need to, because they are that strange. And then, of course, you might need to disable this function on some code. Yeah, we also have pi sum peaks. It's not peaks of pictures of cakes. It's basically compiling the binary in a way where you can put the code whatever you want. So instead of saying the code is always going to be here, you say the code will be somewhere around there, and if I need to reference anything in my code, I will do it according to the address where my code is, not to the particular address it will be. And we also have a 45-sauce, which is basically doing some operations to detect some software vulnerabilities in compile and execution time, many, for example, in proper users of vectors and stuff like that. If you, for example, know the size of a vector and you know you are having an overflow because you know you are going to write five bytes to a four-byte vector, you can say it because you know it. And you will make the program, in that case, just die when that condition happens. We also have a SLR and RANDMAP, which is the counter site of pi and p on the kernel side. It's basically, well, let's suppose my friend from MeseanFire here eats the code. So we execute the program from MeseanFire the first time, and he's here. And I'm the kernel, so I move him here. For the next time, we are going to execute him. And since it's on different places, if you don't know where he is, you cannot go and run the code. OK, so RANDCY stack, it's approximately the same. It's picking up, putting the stack on a random address before answaring to a system call. So I'm the kernel again. This guy, as you can see, it's a stack. It's made of food, put on top of it. OK, so the first time we have him here, the next time we have him here. So if the attacker assumes he's going to be here, because he cannot know what he's going to be, the time when he is not here, which is the most likely of the times, he will say, oh, I want to execute code here. Wait, there is nothing. I cannot. Cool. We also have non-executable memory. Well, this is quite simple. I mean, we notice our code. So I pick a pen and say to the processor, nx. You cannot execute this little piece of here, this data, because everybody knows this is what executes the stuff, and this is what the data is held. So basically, you just mark the places where you don't have code as places that cannot be executed. And you can do also vice versa. I mean, you can also mark places where you have code as places that won't be broken. And that's what comes to our next stuff. It's in protect restrictions. We don't allow users to write and execute memory at the same time. I mean, if we notice what does the stuff, we are not going to allow anybody to modify our math here in order to do different stuff than what we want him to do. Yeah, this has a lot of problems. And so somebody of you is going to tell me, what happens with it? We need to write and then execute that. Well, yeah, we know it. And you can disable this stuff on a binary basis. I mean, for example, on Firefox, you can disable n protect if you know you are going to need write and execute permissions at the same time. So we also remove the other access on the smarts and start. If anybody of you has a Linux computer around, you can check in bar proc, bar one, for example, bar start or bar maps, that there is information about where in memory is everything. I mean, basically, I'm a start, and I'm saying that now Provence on fire is here. Now he's here. Now he's here. So, well, now he's here. Now he's here. Perfect. So if the attacker can read that information, then he can try to exploit his process. So we just remove that information. We put zeros instead. So when you read that one, you will find that Provence on fire is here, no matter what happens. Yeah. So we also restrict access to bar proc only to the owner of the process. Why is that? Well, if you are the owner, if you don't have the owner, you don't have any reason to access that information there. I mean, bar proc information is things like how to develop the process, the things you saw on maps, statistics. And if you are not rude, you shouldn't have access to that information if you are not the owner of the process. We also have, I think, it's Khaled Brut for the Terrence. So I have a shield, Khaled Promethean fire. I know we don't look alike. Suppose for a second it's a clone of mine because I have done a fork. And somebody, some bad person over there exploits him. And because of the misuse we have explained, the exploit didn't work. But then he requests me another clone. So I make another clone of me here, another Promethean fire. And since it's going to have exactly the same information, you could try, for example, to detect the values of the canary. I mean, you could keep doing tries until eventually you manage to find the value. Or indeed, you can do, I think, a skeleton incremental access. You keep guessing one byte at a time by sending a buffer that is one byte longer, one byte longer, until eventually you get a proper access. So the problem is that since he's always a clone, he's always the same program with the same information, if something bad happens, we need to prevent that. Or at least make it a little bit difficult. So what we do, it's the kernel, when I want to fork, after he has said, so I fork, you attack. He dies. I say, I want to fork again. The kernel tells me, hey, hey, hey, hey, hey, hey, hey. Wait a little bit, and then you fork. So basically, we convert what could be used, for example, as an attack to get complete control of the program in a denial of service attack. Yes, before I continue with the attack, I want to make this quite clear. We have no magic ballad. I mean, we have no way of making the attack fail always. But we have ways of making the attack at least less handful. I mean, I suppose all of you agree with me that it's better to have a service that is not running, to have a service that is already controlled by the attacker, and executing whichever code you talk him to do. Please answer. It's a question. It's an open question. Don't you think so? Yeah. OK. So we also have a real row. And by now, it's basically that if we know, for example, that this arm of Promethean fire is going to stay on the same place every time we execute Promethean fire. That's a little bit bad. OK. So we are going to mark this arm as written only so it won't move, and it won't be able to be changed. So alter constants that you have in your program, alter references to things that are in libraries, alter is going to be marked, marked as written only with our linker. And we are also going to force loading alter libraries at runtime. So if he, for example, needs something in me, and he has a reference here pointing to me, let's say, Sam, there is two ways of loading libraries. One thing is that he can have the reference saying, not pointing to me, and then they load me on his points. Or you can, as soon as you execute him, load alter library so you can make this point here and mark it as written only. It's quite simple indeed, I mean. Now we have race conditions. Prepare. Come here. So this works as follows. Matthew, please give a few steps and tell to the public, hello. You need to give the few steps from here, on the screen. Go back. Two steps. Wait. No, no, no, no, no. You're going to execute this to every stuff that I have to pass you around. That's basically a race condition. I mean, it means that I got to the place where you are going to listen to me earlier than him. So instead of hello, I told you who everything's. For that we have, I think, the escalate restrictions on linking and five was a really ugly name. It's quite simple. I mean, if you have things on Barty MP, which is usually a world-wide table directory, you won't be able to execute them, call that's TPE. And you won't be able to use three-foss on there unless you own the process. I mean, if the process and the FIFO owner match, then you can use that FIFO. Otherwise, you can't. That way, you prevent an every user to put a FIFO there that shouldn't be there. We do the same with symbolic links in temp. So it's mostly the same idea. Then we have user-spaced referencing. OK, get on that set. No, no, up. As you can see, here's the high one. Here's no got, kernel. And he has this module that says you have to execute code there. So from that module. You see, there is nothing there. The kernel fails. It's an oops. Oops, something went wrong. And nothing is executed. What happens if the user says, let's put some code here. Execute. Oh, I want you to remove the word system, please. You see the idea? It's quite simple. The idea is that since he is referencing to something that the user can control, the user can take over the system and exploit that vulnerability. So for that, we have a thing called Udref that is basically a check before we execute a function pointer to ensure it's pointing somewhere else. I mean, to ensure it's pointing to non-user space, to kernel space. So you basically prevent the kernel from doing stuff he is supposed to. Basically, what we do is actually make sure that this space here, that is the user space, has never anything unless you load it because you need to access it and then you load it again. So we also have the kernel exec gcc plugin. Let's say it's basically some kind of magic stuff because otherwise we could take too long. That modifies the code before compiling to get the code to work better with preventing execution atoms in kernel space. And of course, we have the classical minimum map address. This is already on normal Linux. But we have it since earlier, which is basically telling that the process cannot map anything in that particular point that we know it's going to cause problems unless you explicitly allow the process to do so. There is a permission that allows the process to do these kinds of mappings. OK, information leaks. That's the easiest thing in the world. See? Hey, what's your name? I'm Matthew. No, I can do everything with his name. Let's suppose that I'm not supposed to know his name. Hey, what's your name? My name is Matthew. No, don't delete. Hey, what's your name? Oh, he has no time for it. Cool. Hey, can you show me your ID card? No need to, but you understand the idea. Oh, no, I know your name. That's an information leak. It's once you can access some information you aren't supposed to, just by using a creative way of getting access to it. And we also have data rewriting. It's basically something similar to what happened with the stacks we saw earlier. I mean, let's suppose that our friend Matt here wants to ask me if one user is authenticated. So I'm going to say zero. We are going to do some execution here. And at the same time, Matt is going to accidentally, because of an overflow or something, change that to one, and then ask me. Are you authenticated? It says one. Yes, I am. So the idea is that basically there are times in which you can rewrite data that you are not supposed to rewrite, which can be used for some exploits. So for that, we have things like the reference, counter overflow, protection, another early name. But the idea is more simple than it seems. It means that I'm a chunk of memory. So you point to me, because I'm reserved. I'm reserved again. You point to me again. No, with the other hand. And I'm reserved again, and you don't have no more hands. So you do an overflow, and you point to me with zero hands. Oh, I'm free. I thought I'm reserved, because somebody is going to use me. What we do is that instead, we work as follows. I'm reserved, point to me. I'm reserved, point to me again. I'm reserved. Oh, wait, two. OK, I cannot be freed. I cannot do anything. It's going to stay at two forever. So as you can see, the ideas behind hardening are quite simple. And most of them you probably can actually apply to your programs if you need them. There is not much more magic before testing, except that what could be a data rewriting access or an information leak will instead be convert to a simple memory leak, which is bad, but is not as bad. We also can limit comparisons on user copy, which we also do. It's simple. It's that when you get on the chair. Thank you. Here's the kernel. It wants to access user space. And it says, oh, wait. Since I'm using user ref, I have to use a function that tells user ref with word. User refs that they want to access that user space. So you do so. And you try to access to my information. And I tell you, yes, right here, right here. And that owner of the process you put zero here to, because it's longer. And I'm passing you a longer buffer. That's the idea of how the vulnerability works. And what we do is that always we are going to do right here, right here. And when I say right here, since we are going to check that it's out of bounds, he won't allow me to do so. We try to generate these bounds automatically. But most of them have to be made by hand. And these parts here accounts for, I think it was at least 80% of the code in the hardware net kernel. Wasn't it, Thoric? I think it was at least 80% or something like that. So the Constify GZC plugin. It's simple. This is basically, if we know something is not going to be modified, or we think so, we mark it as constant, so it's going to be read-only. That way it can be rewritten. And memory can be saved on. Well, it's simple. Get up. He is the all-powerful kernel. So I'm a process. I end up existing. I tell him, execute another process. I start existing. Oh, wait. There is interesting information, it's the password from the other process. So what we do, basically, it's erase memory pages when they are free. And there is two reasons for that. The first one is preventing process from reading data of other processes. And the second reason is that, by telling you, in that way, you reduce the minimum, the life of the important data in the memory space. I suppose you have heard of cold-boot attacks, maybe. It's picking the memory of a computer that has been used down and reading the information we need. We also do the same with the kernel stack. It's exactly the same. I mean, before we return from a syscal, we erase everything. So in case you can read information from the kernel stack from other calls, you cannot use it. And we have a plugin that is called the stack leak, which basically sets an upper bound on the usage of the stack so you don't have to clean everything. You only have to clean that little part of the stack. OK, the last another hint of attack is information compilation. It could work as follows. Hey, Matt. Give me your date of birth. One, two, three. Yeah, OK. No, what? Yes, give me the name of your first pet. What are you seeing when I am trying to get? So with that information, I can then try to prepare my attacks. In this case, for example, if I was trying to take over Matt's identity. Well, what we do is in the first site, you cannot use the MESC. The MESC is basically a buffer of messages from the kernel. And messages from the kernel should then be accessed by normal users. So only root can access them on a hardware system. We also hide symbols of the kernel so you cannot know which functions do you have in your kernel. So you cannot know which modules do you have loaded and if it has vulnerabilities or not. We also hide the process in the kernel because if you have a process that is doing encryption, for example, you know that encryption is already there. And if there is a kernel back affecting encryption, you can exploit it. We also add some restrictions on bar proc. So you cannot access kernel information that is there if you are not root. And we also add restrictions to Csfs and Debugfs, which have even more kernel information and more system information. And yeah, we deny, portray, so non-reveal. I hate all that sounds. That'd be easy. Now my friend here is going to be a vulnerable version of Csfs2, which is used to get root privileges. So since I cannot read his code, I'm going to do this. I'm going to execute it with appetrays, which means I'm debugging the process. So I won't be able to exploit this view. But then I'm going to say, I'm doing the debugger. So which is your code here? And which is your code here? And which is your code here? Because I'm doing the debugger. I need to know it. So in a system like in Gen2, where almost each user might use different C flags, different versions of compilers and libraries, which makes in turn that the place of the staff is different always. These kinds of binaries are marketed as non-reveal. So you cannot get that information. And what we do is prevent this kind of exploit that we have commented used by not allowing you to debug processes that are supposed to be run by a different user or a different group. And well, now we have kernel rootkits. Get on the chair. This is our kernel. Let's suppose I'm root now. I have managed to get an attack. And I'm going to insert here a module that will record everything you say and send it to me. If I hide the module, let's suppose I put it here, then it's a rootkit. That's basically the idea. It's a hidden module on a running process that you don't know it's there. So you can get down. We have ways to prevent at least insertion on the first way. We don't allow random access to physical memory. Somebody's going to say for the next one, we also disallow privileged IO. Exor, exor, it works bad. You cannot use it. Well, actually, some versions of exor work when you disable privileged IO, for example, with the Radeon module. But even if that's the case, you can just disable that feature on your kernel, as in disable this kind of system calls. So it will work. And for example, have disabled privileged IO in this kernel, because otherwise I couldn't be able to be given this presentation. Well, unless you like text consoles, that is. And yeah, we have other attacks. It seems that outside of our control, we don't know they are there. Like, for example, there is this VM86 mode that is known, for example, for that famous book in Windows that was running in every version in Windows science 3.12. I'm not sure if it was XP or Vista. Yes. So it's simple. We just won't allow you to use this mode. And that way, we'll prevent this kind of issues, because let's get realistic. Nobody use it. I mean, nobody uses this mode. So why must this be here? We also have a hardnet module auto-loading. So the idea is that an privileged process cannot request the kernel to load a module, because he needs a feature that is supposed to be there. So if, for example, let's say, carnet, it's an invention. I mean, there is no sense that there's anything like that, which is a cool new protocol that can do everything, and that is full of exploits. It's a high level for your kernel, but it's not load. And you say, hey, I need a carnet socket. The kernel is going to tell you, no, the module is not load. You don't have privileges. I know I want to talk for you. And since the module won't be load, then the boogie code won't be there. And we have also CH routes, jail restrictions, hands up if you have ever used BSD. OK, not that money, cool. Hands up if you at least know what is a CH route. Wow, that's good. So yeah, the CH route is basically that we set a different route directory for a particular program. And you set a load in security, because by setting a different route directory, you limit the damage that you can do to whatever is inside that route directory, at least in theory. Actually, it's not like that. You can get out of the CH route and do a lot of everything, but in theory, it works like that. So what we do is, first, that in hardnet systems, you cannot get out of the CH route. We restrict some behavior that could allow you to do so. And the second thing is that we won't allow access to you to anything that is outside of the CH route. Yeah, thank you for giving me the time, because, oh, 10 minutes, cool. We are on time then. So another thing we did is also move through the info outside of the stack. That was not by Pax. It's unsalited by Pax. Sorry, it's the Pax team. It's funny. He uses the nickname Pax team, but it's made of only one person, which is Pax. So. It's in the water. Yeah, exactly. I suppose he was expecting to have more people on his side when he started the project. It makes sense. So the idea is that all the information of who owns a process and stuff like that is not on the stack anymore. So you cannot overwrite it just by accessing the stack. It's somewhere in memory, and all you have is a pointer to that information in the stack. So it's harder to, for example, use the kind of exploit that is known by everybody. Like, yeah, I wrote a user ID. I put zero, and I get root access to the system. So we also have a consistent multi-thread privilege enforcement. If you use the libc, you don't get a root access. But if you use normal libcs, like you see libc, then you need this in order to ensure that when you do a clone call, all the threads will have the same privileges. And yeah, we have the interoverflow GCC plugin. It's a work that tries to get to know when overflows are going to happen or are likely to happen. And when it detects that, well, it tries to prevent the skin of overflows, like the memory leaks we splined earlier by limiting it and marking things and signals. Well, it works quite well, but we have also a disk kernel exploit response. It's simple. I'm a typical user. I'm going to poke the kernel. Poke, poke, poke, poke, poke. He said, stop. No, I'm not allowed to do anything else. Until, of course, we restart the kernel. The kernel will know that I was poking him, and I start again, poke, poke, poke, exactly. We also have the shallow code execution on non-trusted folders, if you want, that is. It's basically that users can only use code that is in root-owner, in root-owner directories. If you want that feature, I mean, you can look to only a particular set of the users. And there is that, of course, if you cannot insert code, you cannot insert exploits. And we have an extended feature of this that is used to prevent race conditions, and that can cause you to feel heavy case. It will just allow you to execute code in directories that can be written by, that are not owned by yourself. Yep? You can just add a little bit more. Speak a little bit louder. Just a little bit more. Yeah, yeah. Yeah. Yeah. Yeah. And somebody please go and handle him the microphone. This may be a dummy question, but what happens if you mount a directory with binding options to make a fake mount, I mean just binding a directory to another. And you mean inside the first chroot or here? Yes, because you are speaking about not executing code and not trust directory. But what if you mount using bind option, a directory to another? So that you can. Well, if you mount a directory, the first thing you should take into account is that usually to move the stuff, you need to be root. And if that's not the case, because you are on a user, on a normal user system, like that one that you can put just plug a USB system, a USB device, then yes, if the executable is owned by root, it will be executable by everybody in this case. If the permissions allow it. Yeah, but the byte is to move the idos from either side. Yeah. No. No. Well, if you do a bind mount, it still retains the idos of all files. So the ownership of the files is still preserved, in which case the directors as well are also preserved in the ownership. So most of the time you don't have an issue, only on a specific mount point, because that is a different one. And for that, indeed, we need root access. Because you cannot bind as a user a bind mount, you cannot do a bind mount as a user. We still have some protection to the TPE. Excuse me? So does the restriction apply to root user as well? It is a restriction applies on kernel space. It's applied by the kernel to every process you are running. Yes, so. I see what's the problem. OK, now I understand you. You were thinking that we are explaining restrictions on CH root systems. Is that it? No, but I may not have understood this point. OK, well. You see that idea? Yeah, I'll see it later. No problem. OK. We can talk about that later on the round table, indeed. Because we are at the resultant time. And yeah, we have P3's deterrents over non-child-run processes. It's basically that if you are not the parent of a process, you cannot debug it. So you cannot modify its execution. I think, for example, Firefox trying to debug the GPG agent in order to get access to your GPG keys. And we also enforced a number of processes on exec, which means that come here. I don't know. Come here, come here. If I make a clone and make him execute two, for example, the clone will still be there, but won't come to me. So if we disallow execs in the case that you have reached your process limit, the clone will still be mine. So it won't be allowed to make new workloads that are owned by a different user. That's it. We also have black-hauling and laser. That's also it. It's basically some that, on the network stack, we modify some Bayhaville. So first thing, if you send us a packet that we don't know what we do with, we just discard it. We don't care about that. And the second thing is that we won't wait for the last AC key when we have sent a fin packet. Like, I want to end the communication with you. And I have to wait for him to say me, yes, I know that you want to end the communication with me. So if we are discarding packets instead, if he says this and there is nobody listening, we don't care about that because we are going to discard the packet anyway. So basically, we prevent this kind of exploit by discarding packets we don't know what to do with. And finally, we have protections after that. I'm going to go fast over this. We can prevent users from opening sockets, particular users. We can audit what the users do on the kernel. We have mandatory access control like Selenium, which is developed by Swift over there in our site of Selenium, I mean, that prevents you from doing stuff even if you are rude. And we also can mark that only partitions are set only forever, during the whole execution of the process, and on top of the mounting of new partitions. And I'm going to go fast over what we did last year. This is the part of the talk that if you went on last year, you might be interested in knowing. First, we have extended attributes for packs marks. It means that when you want to say a process, hey, I want to do this. I need, for example, that you disable and protect. Until now, you had to modify the executable for the kernel to know that. Now you can just put an extended attribute to the executable, telling, well, this process needs and protect. They are user packs marking, so it means that the owner of the process can modify the packs mark. We also have red depth packs. It's a tool that if you mark a library, as for example, everything that links against this library will need and protect or disabled. I mean, we need to be able to write and execute at the same time. It will detect what links with that library and fix the inconsistencies, so every process that links with that library, we will be able to write and execute information. We also have clear kernel profiles. I mean, know when you configure the kernel, you said what if you are using a server or a desktop, if you are virtualizing as hosts, guests, or not virtualizing at all, and if you want performance or security. And we have fast virtualization, finally. We have to thank that guy over there who made most of the tests, actually. It means that, no, you can use hard-end systems with KBM and they will work. Mostly. Yeah, newer systems. And we also have to upstream some libffi patches. Sorry, man, I said to do that. Which means that with newer versions of libffi, you can use hard-end systems. And we have this cool new, I suppose you have heard about BPF, it's used by Widesar to execute the filtering stuff on the kernel. So BPF, basically, can be used to feed values to execute code by jumping somewhere in the middle. And we prevent that by putting the constants on different places every time you use BPF. And what's the future? Well, we want more hardening supported upstream. So it's working on getting the hardening stuff we have in GCC on upstream GCC. We are working to have the last versions of the truth change packages against ORIGDA. You can do that. We have started a project on integrity measurement, which is made by Swift. So you have questions, go to him on the last part of the roundtable. And we are working on updating the profiles to the last version that is sitting.0. And it will be done in six months or something like that if there is no problems. Blueness is working on that. So thanks for everything. Questions? Any fast questions? Cool. So, well, yeah. I have a question. I've been a G2 user for a few years now, but never installed a hardened profile. I seem to remember that using a hardened profile was before. A few years ago was not encouraged much because it might break stuff. But in the last few years, I've seen some things on Planet Gen2 that says that it's coming to a state where it is usable in normal systems. Well, when I started with Yandu Harden, I was a normal user. I mean, yeah, it's true. This is a desktop system, and it's running in two hardened. There are some issues still. Like, for example, there is problems with binary stuff. And you need to use the depth packs if you are using a Radeon kernel like us to put the proper markings on binaries using OpenGL and stuff like that. But mostly, it works out by default. And especially on servers, it usually works out by default. And if you have any problem, please come to our chat channel, and we will try to help you as much as we can. So for a normal default user who wouldn't mind meddling grins and stuff, you would recommend that they install hardened by default. I recommend you to install. Well, if you have used a Gen2 before, which is your case, I recommend you to try hardened it at least. And if you find it's OK for you and it fits your requirements, then use it. I won't recommend you to use hardened it, because if for any reason you have a strange hardware and we have a problem with that particular hardware or a really strange setup, we are Gen2 people. We know what the strange setups are. Everybody has one. So in that case, I cannot say you use hardened, but in general, it works well. OK, thank you. So we are done, I suppose. We have no more time. We are going to do now the round table. The idea is that we sit around, we talk about hardened it for half an hour. So sorry, Com. And yeah, you are welcome to join us and ask whatever questions you have. If you are not a Gen2 user, you are still welcome to come and ask any questions you have on hardening or whatever or how we do stuff. So. What are the quick questions about the performance expectations between hardening and hardening? The impact is usually less than 10%. Yeah, right. And what's inside the performance on the GitHub runtime on KBN, for example? You are worth that. You were the one doing the benchmarks. So the question. Which is the impact on performance for KBN? So the performance impact on KBN is, I'd say, less than 5%. It's very, very, very small. At which level? Is that the level of it? Or at the next level? Are you saying host or the guest level? Because the main node is actually the view of the algorithm. You are at the center of the performance. And at the last, you lost the game. No, I'd say you lose 5%. Can you repeat the question? Is the performance, do you lose 10% from being hardened on top of losing 5% for being in KVM as well? I'd say more of a. No, it's less. It's not all this. It's usually why it's smaller. 10% is what we got on the worst cases. Right. You have very worst case, like if you design code to hit all the slowness. So any other questions? Let's go then by the roundtable. Media team there, I'd top this if you don't record the roundtable so people don't feel like compelled to speak.
 In the U-depth dark, please take that into mind.  And we try to provide the best we can find in security to the  users in Yentoo.  And well, this happens before it's accepted to mainstream  Yentoo.  Why?  Well, mainly because let's get realistic.  Managing to users are risers.  Managing to users want to have a speed.  Managing to users use F1 switch loops.  And many Yentoo users don't like the idea of being more  secure in exchange of being slightly slower.  And since Yentoo is about choosing, they also have the  chance to choose to be more secure or to be more fast.  So let's start with what's an stack overflow.  Please, face up.  Stand up, man.  Put your hand here.  And keep marking the end of the line.  Because this is a, yeah.  So first, when we want to do a function call, we insert some  arguments.  Let's say this, for example, could be echo.  And this one could be hello world.  Then we cut the function.  So we have to add our return address, which is, where are  we going to continue the execution of our code?  And finally, we add some frame pointer and some local  variables.  The frame pointer basically points to here,  approximately, to the start of the stack of the function  that call it.  Cool, isn't it?  So what's the problem?  Well, please stop pinging me.  What's the problem?  The problem is that we have, for example, if we have some  local variable here that is a buffer, let's say, a char  vector, start writing the stuff here, like the frame  pointer, then the return address, then the arguments.  For example, if we use skits.  Because nobody here uses skits.  Do you?  You better don't.  Well, he does, but he works in a bank.  It's normal.  So what we do here, instead, is put some random trust in  the local variables that we find before our buffer.  Put some random trust on the frame pointer, if there is,  because we don't care.  Put an address pointing somewhere around here.  Put a lot of knobs, which is instructions that do no  thing.  And finally, put our Ebbel code that will remove the  system or do all the other Ebbel stuff we want to.  That's the classical stack overflow.  But we also have to return to libc, which is mostly the  same.  I mean, we put some trust here.  We put the address of the function we want to get called.  Then we put a fake return address, because maybe we  don't expect our function to be to return if we are using  exec.  And some arguments that we will pass to the function and  will get passed around.  This is the classical return to libc attack, which consists  of returning somewhere in the middle of the library.  So what's needed for the attacks?  You need, for the classic attack, to be able to execute  code on the stack, which is where you have your variables.  You need to have access to which is the stack address.  And you need to have access to the return address, so you  can modify it and make it go to the stack.  And for the other kind of attack, you need the function  address you want to call.  And return access to the return address you want to  modify.  And well, to the arguments, of course.  If you have access to the first, you probably have access  to the second one.  So what's SSP?  It's simple.  We have this stuff here.  It's called a canary.  So when you modify it, you check before returning, which  is the value of the canary.  And if it's different, it's exactly the same as it  happens on a mine.  I mean, you know that the people that went to the coal  mines with a canary?  Yeah, if the canary dies, there is a tissue, and you  better get the hell out of there before it explodes.  It's the same.  If this value is changed, something bad has happened,  and we better kill the program before it does anything  bad.  So that's SSP.  I mean, there is not much magic before the idea.  What's the problem?  Well, there are some functions, for example, in group, that  try to write in the stack because they need to, because  they are that strange.  And then, of course, you might need to disable this  function on some code.  Yeah, we also have pi sum peaks.  It's not peaks of pictures of cakes.  It's basically compiling the binary in a way where you can  put the code whatever you want.  So instead of saying the code is always going to be here,  you say the code will be somewhere around there, and  if I need to reference anything in my code, I will do it  according to the address where my code is, not to the  particular address it will be.  And we also have a 45-sauce, which is basically doing  some operations to detect some software vulnerabilities in  compile and execution time, many, for example, in proper  users of vectors and stuff like that.  If you, for example, know the size of a vector and you know  you are having an overflow because you know you are  going to write five bytes to a four-byte vector, you can  say it because you know it.  And you will make the program, in that case, just die when  that condition happens.  We also have a SLR and RANDMAP, which is the counter  site of pi and p on the kernel side.  It's basically, well, let's suppose my friend from  MeseanFire here eats the code.  So we execute the program from MeseanFire the first time,  and he's here.  And I'm the kernel, so I move him here.  For the next time, we are going to execute him.  And since it's on different places, if you don't know  where he is, you cannot go and run the code.  OK, so RANDCY stack, it's approximately the same.  It's picking up, putting the stack on a random address  before answaring to a system call.  So I'm the kernel again.  This guy, as you can see, it's a stack.  It's made of food, put on top of it.  OK, so the first time we have him here, the next time we  have him here.  So if the attacker assumes he's going to be here, because he  cannot know what he's going to be, the time when he is not  here, which is the most likely of the times, he will say, oh,  I want to execute code here.  Wait, there is nothing.  I cannot.  Cool.  We also have non-executable memory.  Well, this is quite simple.  I mean, we notice our code.  So I pick a pen and say to the processor, nx.  You cannot execute this little piece of here, this data,  because everybody knows this is what  executes the stuff, and this is what the data is held.  So basically, you just mark the places where you don't have  code as places that cannot be executed.  And you can do also vice versa.  I mean, you can also mark places where you have code as  places that won't be broken.  And that's what comes to our next stuff.  It's in protect restrictions.  We don't allow users to write and execute memory at the  same time.  I mean, if we notice what does the stuff, we are not going to  allow anybody to modify our math here in order to do  different stuff than what we want him to do.  Yeah, this has a lot of problems.  And so somebody of you is going to tell me, what happens  with it?  We need to write and then execute that.  Well, yeah, we know it.  And you can disable this stuff on a binary basis.  I mean, for example, on Firefox, you can disable n  protect if you know you are going to need write and  execute permissions at the same time.  So we also remove the other access on the smarts and  start.  If anybody of you has a Linux computer around, you can  check in bar proc, bar one, for example, bar start or bar  maps, that there is information about where in  memory is everything.  I mean, basically, I'm a start, and I'm saying that now  Provence on fire is here.  Now he's here.  Now he's here.  So, well, now he's here.  Now he's here.  Perfect.  So if the attacker can read that information, then he can  try to exploit his process.  So we just remove that information.  We put zeros instead.  So when you read that one, you will find that Provence on  fire is here, no matter what happens.  Yeah.  So we also restrict access to bar proc only to the owner of  the process.  Why is that?  Well, if you are the owner, if you don't have the owner, you  don't have any reason to access that information there.  I mean, bar proc information is things like how to  develop the process, the things you saw on maps,  statistics.  And if you are not rude, you shouldn't have access to that  information if you are not the owner of the process.  We also have, I think, it's Khaled Brut for the Terrence.  So I have a shield, Khaled Promethean fire.  I know we don't look alike.  Suppose for a second it's a clone of mine because I have  done a fork.  And somebody, some bad person over there exploits him.  And because of the misuse we have explained, the exploit  didn't work.  But then he requests me another clone.  So I make another clone of me here, another Promethean fire.  And since it's going to have exactly the same information,  you could try, for example, to detect the values of the  canary.  I mean, you could keep doing tries until eventually you  manage to find the value.  Or indeed, you can do, I think, a  skeleton incremental access.  You keep guessing one byte at a time by sending a buffer that  is one byte longer, one byte longer, until eventually you  get a proper access.  So the problem is that since he's always a clone, he's  always the same program with the same information, if  something bad happens, we need to prevent that.  Or at least make it a little bit difficult.  So what we do, it's the kernel, when I want to fork,  after he has said, so I fork, you attack.  He dies.  I say, I want to fork again.  The kernel tells me, hey, hey, hey, hey, hey, hey, hey.  Wait a little bit, and then you fork.  So basically, we convert what could be used, for example,  as an attack to get complete control of the program in a  denial of service attack.  Yes, before I continue with the attack, I want to make this  quite clear.  We have no magic ballad.  I mean, we have no way of making the attack fail always.  But we have ways of making the attack at least less handful.  I mean, I suppose all of you agree with me that it's  better to have a service that is not running, to have a  service that is already controlled by the attacker,  and executing whichever code you talk him to do.  Please answer.  It's a question.  It's an open question.  Don't you think so?  Yeah.  OK.  So we also have a real row.  And by now, it's basically that if we know, for example,  that this arm of Promethean fire is going to stay on the  same place every time we execute Promethean fire.  That's a little bit bad.  OK.  So we are going to mark this arm as written only so it  won't move, and it won't be able to be changed.  So alter constants that you have in your program, alter  references to things that are in libraries, alter is going to  be marked, marked as written only with our linker.  And we are also going to force loading alter libraries at  runtime.  So if he, for example, needs something in me, and he has a  reference here pointing to me, let's say, Sam, there is two  ways of loading libraries.  One thing is that he can have the reference saying, not  pointing to me, and then they load me on his points.  Or you can, as soon as you execute him, load alter  library so you can make this point here and  mark it as written only.  It's quite simple indeed, I mean.  Now we have race conditions.  Prepare.  Come here.  So this works as follows.  Matthew, please give a few steps and tell to the public,  hello.  You need to give the few steps from here, on the screen.  Go back.  Two steps.  Wait.  No, no, no, no, no.  You're going to execute this to every stuff that I have to  pass you around.  That's basically a race condition.  I mean, it means that I got to the place where you are going  to listen to me earlier than him.  So instead of hello, I told you who everything's.  For that we have, I think, the escalate restrictions on  linking and five was a really ugly name.  It's quite simple.  I mean, if you have things on Barty MP, which is usually a  world-wide table directory, you won't be able to execute  them, call that's TPE.  And you won't be able to use three-foss on there unless  you own the process.  I mean, if the process and the FIFO owner match, then you  can use that FIFO.  Otherwise, you can't.  That way, you prevent an every user to put a FIFO there  that shouldn't be there.  We do the same with symbolic links in temp.  So it's mostly the same idea.  Then we have user-spaced referencing.  OK, get on that set.  No, no, up.  As you can see, here's the high one.  Here's no got, kernel.  And he has this module that says you have to execute code  there.  So from that module.  You see, there is nothing there.  The kernel fails.  It's an oops.  Oops, something went wrong.  And nothing is executed.  What happens if the user says, let's put some code here.  Execute.  Oh, I want you to remove the word system, please.  You see the idea?  It's quite simple.  The idea is that since he is referencing to something that  the user can control, the user can take over the system and  exploit that vulnerability.  So for that, we have a thing called Udref that is basically  a check before we execute a function pointer to ensure  it's pointing somewhere else.  I mean, to ensure it's pointing to non-user space, to  kernel space.  So you basically prevent the kernel from doing stuff he  is supposed to.  Basically, what we do is actually make sure that this  space here, that is the user space, has never anything  unless you load it because you need to access it and then  you load it again.  So we also have the kernel exec gcc plugin.  Let's say it's basically some kind of magic stuff because  otherwise we could take too long.  That modifies the code before compiling to get the code to  work better with preventing execution atoms in kernel  space.  And of course, we have the classical minimum map address.  This is already on normal Linux.  But we have it since earlier, which is basically telling  that the process cannot map anything in that particular  point that we know it's going to cause problems unless you  explicitly allow the process to do so.  There is a permission that allows the process to do  these kinds of mappings.  OK, information leaks.  That's the easiest thing in the world.  See?  Hey, what's your name?  I'm Matthew.  No, I can do everything with his name.  Let's suppose that I'm not supposed to know his name.  Hey, what's your name?  My name is Matthew.  No, don't delete.  Hey, what's your name?  Oh, he has no time for it.  Cool.  Hey, can you show me your ID card?  No need to, but you understand the idea.  Oh, no, I know your name.  That's an information leak.  It's once you can access some information you aren't  supposed to, just by using a creative way of getting  access to it.  And we also have data rewriting.  It's basically something similar to what happened with  the stacks we saw earlier.  I mean, let's suppose that our friend Matt here wants to ask  me if one user is authenticated.  So I'm going to say zero.  We are going to do some execution here.  And at the same time, Matt is going to accidentally, because  of an overflow or something, change that to one, and then  ask me.  Are you authenticated?  It says one.  Yes, I am.  So the idea is that basically there are times in which you  can rewrite data that you are not supposed to rewrite, which  can be used for some exploits.  So for that, we have things like the reference,  counter overflow, protection, another early name.  But the idea is more simple than it seems.  It means that I'm a chunk of memory.  So you point to me, because I'm reserved.  I'm reserved again.  You point to me again.  No, with the other hand.  And I'm reserved again, and you don't have no more hands.  So you do an overflow, and you point to me with zero hands.  Oh, I'm free.  I thought I'm reserved, because somebody is going to use me.  What we do is that instead, we work as follows.  I'm reserved, point to me.  I'm reserved, point to me again.  I'm reserved.  Oh, wait, two.  OK, I cannot be freed.  I cannot do anything.  It's going to stay at two forever.  So as you can see, the ideas behind hardening are quite simple.  And most of them you probably can actually apply to your programs  if you need them.  There is not much more magic before testing,  except that what could be a data rewriting access or an information  leak will instead be convert to a simple memory leak, which  is bad, but is not as bad.  We also can limit comparisons on user copy, which we also do.  It's simple.  It's that when you get on the chair.  Thank you.  Here's the kernel.  It wants to access user space.  And it says, oh, wait.  Since I'm using user ref, I have to use a function that  tells user ref with word.  User refs that they want to access that user space.  So you do so.  And you try to access to my information.  And I tell you, yes, right here, right here.  And that owner of the process you put zero here to,  because it's longer.  And I'm passing you a longer buffer.  That's the idea of how the vulnerability works.  And what we do is that always we are going to do right here,  right here.  And when I say right here, since we are going to check that  it's out of bounds, he won't allow me to do so.  We try to generate these bounds automatically.  But most of them have to be made by hand.  And these parts here accounts for, I think it was at least  80% of the code in the hardware net kernel.  Wasn't it, Thoric?  I think it was at least 80% or something like that.  So the Constify GZC plugin.  It's simple.  This is basically, if we know something is not going to be  modified, or we think so, we mark it  as constant, so it's going to be read-only.  That way it can be rewritten.  And memory can be saved on.  Well, it's simple.  Get up.  He is the all-powerful kernel.  So I'm a process.  I end up existing.  I tell him, execute another process.  I start existing.  Oh, wait.  There is interesting information, it's the password from  the other process.  So what we do, basically, it's erase memory pages when they  are free.  And there is two reasons for that.  The first one is preventing process from reading data  of other processes.  And the second reason is that, by telling you, in that way,  you reduce the minimum, the life of the important data in  the memory space.  I suppose you have heard of cold-boot attacks, maybe.  It's picking the memory of a computer that has been used  down and reading the information we need.  We also do the same with the kernel stack.  It's exactly the same.  I mean, before we return from a syscal, we erase everything.  So in case you can read information from the kernel  stack from other calls, you cannot use it.  And we have a plugin that is called the stack leak, which  basically sets an upper bound on the usage of the  stack so you don't have to clean everything.  You only have to clean that little part of the stack.  OK, the last another hint of attack is information  compilation.  It could work as follows.  Hey, Matt.  Give me your date of birth.  One, two, three.  Yeah, OK.  No, what?  Yes, give me the name of your first pet.  What are you seeing when I am trying to get?  So with that information, I can then try to prepare my attacks.  In this case, for example, if I was trying to take over Matt's  identity.  Well, what we do is in the first site, you cannot use the  MESC.  The MESC is basically a buffer of messages from the kernel.  And messages from the kernel should then be accessed by  normal users.  So only root can access them on a hardware system.  We also hide symbols of the kernel so you cannot know  which functions do you have in your kernel.  So you cannot know which modules do you have loaded and if  it has vulnerabilities or not.  We also hide the process in the kernel because if you have a  process that is doing encryption, for example, you  know that encryption is already there.  And if there is a kernel back affecting encryption, you can  exploit it.  We also add some restrictions on bar proc.  So you cannot access kernel information that is there if  you are not root.  And we also add restrictions to Csfs and Debugfs, which have  even more kernel information and more system  information.  And yeah, we deny, portray, so non-reveal.  I hate all that sounds.  That'd be easy.  Now my friend here is going to be a vulnerable version of  Csfs2, which is used to get root privileges.  So since I cannot read his code, I'm going to do this.  I'm going to execute it with appetrays, which means I'm  debugging the process.  So I won't be able to exploit this view.  But then I'm going to say, I'm doing the debugger.  So which is your code here?  And which is your code here?  And which is your code here?  Because I'm doing the debugger.  I need to know it.  So in a system like in Gen2, where almost each user might  use different C flags, different versions of  compilers and libraries, which makes in turn that the place  of the staff is different always.  These kinds of binaries are marketed as non-reveal.  So you cannot get that information.  And what we do is prevent this kind of exploit that we have  commented used by not allowing you to debug processes that  are supposed to be run by a different user or a different  group.  And well, now we have kernel rootkits.  Get on the chair.  This is our kernel.  Let's suppose I'm root now.  I have managed to get an attack.  And I'm going to insert here a module that will record  everything you say and send it to me.  If I hide the module, let's suppose I put it here, then  it's a rootkit.  That's basically the idea.  It's a hidden module on a running process that you don't  know it's there.  So you can get down.  We have ways to prevent at least insertion on the first  way.  We don't allow random access to physical memory.  Somebody's going to say for the next one, we also  disallow privileged IO.  Exor, exor, it works bad.  You cannot use it.  Well, actually, some versions of exor work when you disable  privileged IO, for example, with the Radeon module.  But even if that's the case, you can just disable that  feature on your kernel, as in disable this  kind of system calls.  So it will work.  And for example, have disabled privileged IO in this  kernel, because otherwise I couldn't be able to be given  this presentation.  Well, unless you like text consoles, that is.  And yeah, we have other attacks.  It seems that outside of our control, we don't  know they are there.  Like, for example, there is this VM86 mode that is known,  for example, for that famous book in Windows that was  running in every version in Windows science 3.12.  I'm not sure if it was XP or Vista.  Yes.  So it's simple.  We just won't allow you to use this mode.  And that way, we'll prevent this kind of issues, because  let's get realistic.  Nobody use it.  I mean, nobody uses this mode.  So why must this be here?  We also have a hardnet module auto-loading.  So the idea is that an privileged process cannot  request the kernel to load a module, because he needs a  feature that is supposed to be there.  So if, for example, let's say, carnet, it's an invention.  I mean, there is no sense that there's anything like that,  which is a cool new protocol that can do everything, and  that is full of exploits.  It's a high level for your kernel, but it's not load.  And you say, hey, I need a carnet socket.  The kernel is going to tell you, no, the module is not  load.  You don't have privileges.  I know I want to talk for you.  And since the module won't be load, then the boogie code  won't be there.  And we have also CH routes, jail restrictions, hands up  if you have ever used BSD.  OK, not that money, cool.  Hands up if you at least know what is a CH route.  Wow, that's good.  So yeah, the CH route is basically that we set a  different route directory for a particular program.  And you set a load in security, because by setting a  different route directory, you limit the damage that you can  do to whatever is inside that route directory, at least in  theory.  Actually, it's not like that.  You can get out of the CH route and do a lot of  everything, but in theory, it works like that.  So what we do is, first, that in hardnet systems, you cannot  get out of the CH route.  We restrict some behavior that could  allow you to do so.  And the second thing is that we won't allow access to you to  anything that is outside of the CH route.  Yeah, thank you for giving me the time, because, oh, 10  minutes, cool.  We are on time then.  So another thing we did is also move through the info  outside of the stack.  That was not by Pax.  It's unsalited by Pax.  Sorry, it's the Pax team.  It's funny.  He uses the nickname Pax team, but it's made of only one  person, which is Pax.  So.  It's in the water.  Yeah, exactly.  I suppose he was expecting to have more people on his side  when he started the project.  It makes sense.  So the idea is that all the information of who owns a  process and stuff like that is not on the stack anymore.  So you cannot overwrite it just by accessing the stack.  It's somewhere in memory, and all you have is a pointer to  that information in the stack.  So it's harder to, for example, use the kind of exploit  that is known by everybody.  Like, yeah, I wrote a user ID.  I put zero, and I get root access to the system.  So we also have a consistent multi-thread  privilege enforcement.  If you use the libc, you don't get a root access.  But if you use normal libcs, like you see libc, then you  need this in order to ensure that when you do a clone call,  all the threads will have the same privileges.  And yeah, we have the interoverflow GCC plugin.  It's a work that tries to get to know when overflows are  going to happen or are likely to happen.  And when it detects that, well, it tries to prevent the  skin of overflows, like the memory leaks we splined  earlier by limiting it and marking things and signals.  Well, it works quite well, but we have also a  disk kernel exploit response.  It's simple.  I'm a typical user.  I'm going to poke the kernel.  Poke, poke, poke, poke, poke.  He said, stop.  No, I'm not allowed to do anything else.  Until, of course, we restart the kernel.  The kernel will know that I was poking him, and I start  again, poke, poke, poke, exactly.  We also have the shallow code execution on non-trusted  folders, if you want, that is.  It's basically that users can only use code that is in  root-owner, in root-owner directories.  If you want that feature, I mean, you can look to only a  particular set of the users.  And there is that, of course, if you cannot insert code, you  cannot insert exploits.  And we have an extended feature of this that is used to  prevent race conditions, and that can cause you to feel  heavy case.  It will just allow you to execute code in directories  that can be written by, that are not owned by yourself.  Yep?  You can just add a little bit more.  Speak a little bit louder.  Just a little bit more.  Yeah, yeah.  Yeah.  Yeah.  Yeah.  And somebody please go and handle him the microphone.  This may be a dummy question, but what  happens if you mount a directory with binding options  to make a fake mount, I mean just binding a directory  to another.  And you mean inside the first chroot or here?  Yes, because you are speaking about not executing code  and not trust directory.  But what if you mount using bind option, a directory  to another?  So that you can.  Well, if you mount a directory, the first thing  you should take into account is that usually to move the  stuff, you need to be root.  And if that's not the case, because you are on a user,  on a normal user system, like that one that you can put  just plug a USB system, a USB device, then yes,  if the executable is owned by root,  it will be executable by everybody in this case.  If the permissions allow it.  Yeah, but the byte is to move the idos from either side.  Yeah.  No.  No.  Well, if you do a bind mount, it still retains the  idos of all files.  So the ownership of the files is still preserved, in which  case the directors as well are also preserved in the  ownership.  So most of the time you don't have an issue, only on a  specific mount point, because that is a different one.  And for that, indeed, we need root access.  Because you cannot bind as a user a bind mount, you cannot  do a bind mount as a user.  We still have some protection to the TPE.  Excuse me?  So does the restriction apply to root user as well?  It is a restriction applies on kernel space.  It's applied by the kernel to every process you are running.  Yes, so.  I see what's the problem.  OK, now I understand you.  You were thinking that we are explaining restrictions on  CH root systems.  Is that it?  No, but I may not have understood this point.  OK, well.  You see that idea?  Yeah, I'll see it later.  No problem.  OK.  We can talk about that later on the  round table, indeed.  Because we are at the resultant time.  And yeah, we have P3's deterrents over non-child-run  processes.  It's basically that if you are not the parent of a  process, you cannot debug it.  So you cannot modify its execution.  I think, for example, Firefox trying to debug the  GPG agent in order to get access to your GPG keys.  And we also enforced a number of processes on exec, which  means that come here.  I don't know.  Come here, come here.  If I make a clone and make him execute two, for example, the  clone will still be there, but won't come to me.  So if we disallow execs in the case that you have reached  your process limit, the clone will still be mine.  So it won't be allowed to make new workloads that are owned  by a different user.  That's it.  We also have black-hauling and laser.  That's also it.  It's basically some that, on the network stack, we  modify some Bayhaville.  So first thing, if you send us a packet that we don't know  what we do with, we just discard it.  We don't care about that.  And the second thing is that we won't wait for the last AC  key when we have sent a fin packet.  Like, I want to end the communication with you.  And I have to wait for him to say me, yes, I know that you  want to end the communication with me.  So if we are discarding packets instead, if he says  this and there is nobody listening, we don't care about  that because we are going to discard the packet anyway.  So basically, we prevent this kind of exploit by discarding  packets we don't know what to do with.  And finally, we have protections after that.  I'm going to go fast over this.  We can prevent users from opening sockets, particular  users.  We can audit what the users do on the kernel.  We have mandatory access control like Selenium, which is  developed by Swift over there in our site of Selenium, I  mean, that prevents you from doing stuff even if you are  rude.  And we also can mark that only partitions are set only  forever, during the whole execution of the process, and  on top of the mounting of new partitions.  And I'm going to go fast over what we did last year.  This is the part of the talk that if you went on last year,  you might be interested in knowing.  First, we have extended attributes for  packs marks.  It means that when you want to say a process, hey, I want to  do this.  I need, for example, that you disable and protect.  Until now, you had to modify the executable for the kernel  to know that.  Now you can just put an extended attribute to the  executable, telling, well, this process needs and protect.  They are user packs marking, so it means that the owner of  the process can modify the packs mark.  We also have red depth packs.  It's a tool that if you mark a library, as for example,  everything that links against this library will need and  protect or disabled.  I mean, we need to be able to write and execute at the same  time.  It will detect what links with that library and fix the  inconsistencies, so every process that links with that  library, we will be able to write and execute information.  We also have clear kernel profiles.  I mean, know when you configure the kernel, you  said what if you are using a server or a desktop, if you  are virtualizing as hosts, guests, or not  virtualizing at all, and if you want performance or  security.  And we have fast virtualization, finally.  We have to thank that guy over there who made most of the  tests, actually.  It means that, no, you can use hard-end systems with KBM  and they will work.  Mostly.  Yeah, newer systems.  And we also have to upstream some libffi patches.  Sorry, man, I said to do that.  Which means that with newer versions of libffi, you can  use hard-end systems.  And we have this cool new, I suppose you have heard about  BPF, it's used by Widesar to execute the filtering  stuff on the kernel.  So BPF, basically, can be used to feed values to  execute code by jumping somewhere in the middle.  And we prevent that by putting the constants on  different places every time you use BPF.  And what's the future?  Well, we want more hardening supported upstream.  So it's working on getting the hardening stuff we have in  GCC on upstream GCC.  We are working to have the last versions of the truth  change packages against ORIGDA.  You can do that.  We have started a project on integrity measurement, which  is made by Swift.  So you have questions, go to him on the last part of the  roundtable.  And we are working on updating the profiles to the last  version that is sitting.0.  And it will be done in six months or something like that  if there is no problems.  Blueness is working on that.  So thanks for everything.  Questions?  Any fast questions?  Cool.  So, well, yeah.  I have a question.  I've been a G2 user for a few years now, but never installed  a hardened profile.  I seem to remember that using a hardened profile was before.  A few years ago was not encouraged much because it  might break stuff.  But in the last few years, I've seen some things on Planet  Gen2 that says that it's coming to a state where it is  usable in normal systems.  Well, when I started with Yandu Harden, I was a normal  user.  I mean, yeah, it's true.  This is a desktop system, and it's  running in two hardened.  There are some issues still.  Like, for example, there is problems with binary stuff.  And you need to use the depth packs if you are using  a Radeon kernel like us to put the proper markings on  binaries using OpenGL and stuff like that.  But mostly, it works out by default.  And especially on servers, it usually works out by default.  And if you have any problem, please come to our chat  channel, and we will try to help you as much as we can.  So for a normal default user who wouldn't mind meddling  grins and stuff, you would recommend that they install  hardened by default.  I recommend you to install.  Well, if you have used a Gen2 before, which is your case, I  recommend you to try hardened it at least.  And if you find it's OK for you and it fits your  requirements, then use it.  I won't recommend you to use hardened it, because if for  any reason you have a strange hardware and we have a  problem with that particular hardware or a really strange  setup, we are Gen2 people.  We know what the strange setups are.  Everybody has one.  So in that case, I cannot say you use hardened, but in  general, it works well.  OK, thank you.  So we are done, I suppose.  We have no more time.  We are going to do now the round table.  The idea is that we sit around, we talk about hardened it  for half an hour.  So sorry, Com.  And yeah, you are welcome to join us and ask whatever  questions you have.  If you are not a Gen2 user, you are still welcome to come and  ask any questions you have on hardening or whatever or how  we do stuff.  So.  What are the quick questions about the performance  expectations between hardening and hardening?  The impact is usually less than 10%.  Yeah, right.  And what's inside the performance on the  GitHub runtime on KBN, for example?  You are worth that.  You were the one doing the benchmarks.  So the question.  Which is the impact on performance for KBN?  So the performance impact on KBN is, I'd say, less than  5%.  It's very, very, very small.  At which level?  Is that the level of it?  Or at the next level?  Are you saying host or the guest level?  Because the main node is actually the view of the  algorithm.  You are at the center of the performance.  And at the last, you lost the game.  No, I'd say you lose 5%.  Can you repeat the question?  Is the performance, do you lose 10% from being  hardened on top of losing 5% for being in KVM as well?  I'd say more of a.  No, it's less.  It's not all this.  It's usually why it's smaller.  10% is what we got on the worst cases.  Right.  You have very worst case, like if you design code to hit all  the slowness.  So any other questions?  Let's go then by the roundtable.  Media team there, I'd top this if you don't record the  roundtable so people don't feel like compelled to speak.
Gentoo_Hardened_YOK4NJmGwq4_2_0_371.png Gentoo_Hardened_YOK4NJmGwq4_2_372_1151.png Gentoo_Hardened_YOK4NJmGwq4_2_1152_2387.png Gentoo_Hardened_YOK4NJmGwq4_2_2388_4283.png Gentoo_Hardened_YOK4NJmGwq4_2_4284_4823.png Gentoo_Hardened_YOK4NJmGwq4_2_4824_5015.png Gentoo_Hardened_YOK4NJmGwq4_2_5016_5099.png Gentoo_Hardened_YOK4NJmGwq4_2_5100_9947.png Gentoo_Hardened_YOK4NJmGwq4_2_9948_10283.png Gentoo_Hardened_YOK4NJmGwq4_2_10284_10955.png Gentoo_Hardened_YOK4NJmGwq4_2_10956_11003.png Gentoo_Hardened_YOK4NJmGwq4_2_11004_12143.png Gentoo_Hardened_YOK4NJmGwq4_2_12144_22763.png Gentoo_Hardened_YOK4NJmGwq4_2_22764_23855.png Gentoo_Hardened_YOK4NJmGwq4_2_23856_25103.png Gentoo_Hardened_YOK4NJmGwq4_2_25104_34679.png Gentoo_Hardened_YOK4NJmGwq4_2_34680_35627.png Gentoo_Hardened_YOK4NJmGwq4_2_35628_38579.png Gentoo_Hardened_YOK4NJmGwq4_2_38580_38627.png Gentoo_Hardened_YOK4NJmGwq4_2_38628_39707.png Gentoo_Hardened_YOK4NJmGwq4_2_39708_40871.png Gentoo_Hardened_YOK4NJmGwq4_2_40872_41111.png Gentoo_Hardened_YOK4NJmGwq4_2_41112_48443.png Gentoo_Hardened_YOK4NJmGwq4_2_48444_50303.png Gentoo_Hardened_YOK4NJmGwq4_2_50304_50543.png Gentoo_Hardened_YOK4NJmGwq4_2_50544_52439.png Gentoo_Hardened_YOK4NJmGwq4_2_52440_54119.png Gentoo_Hardened_YOK4NJmGwq4_2_54120_54647.png Gentoo_Hardened_YOK4NJmGwq4_2_54648_55967.png Gentoo_Hardened_YOK4NJmGwq4_2_55968_62063.png Gentoo_Hardened_YOK4NJmGwq4_2_62064_63143.png Gentoo_Hardened_YOK4NJmGwq4_2_63144_63191.png Gentoo_Hardened_YOK4NJmGwq4_2_63192_63395.png Gentoo_Hardened_YOK4NJmGwq4_2_63396_63803.png Gentoo_Hardened_YOK4NJmGwq4_2_63804_64919.png Gentoo_Hardened_YOK4NJmGwq4_2_64920_65159.png Gentoo_Hardened_YOK4NJmGwq4_2_65160_65219.png Gentoo_Hardened_YOK4NJmGwq4_2_65220_65339.png Gentoo_Hardened_YOK4NJmGwq4_2_65340_65411.png Gentoo_Hardened_YOK4NJmGwq4_2_65412_66551.png Gentoo_Hardened_YOK4NJmGwq4_2_66552_66647.png Gentoo_Hardened_YOK4NJmGwq4_2_66648_66767.png Gentoo_Hardened_YOK4NJmGwq4_2_66768_66887.png Gentoo_Hardened_YOK4NJmGwq4_2_66888_67127.png Gentoo_Hardened_YOK4NJmGwq4_2_67128_67223.png Gentoo_Hardened_YOK4NJmGwq4_2_67224_67271.png Gentoo_Hardened_YOK4NJmGwq4_2_67272_67547.png Gentoo_Hardened_YOK4NJmGwq4_2_67548_67595.png Gentoo_Hardened_YOK4NJmGwq4_2_67596_68507.png Gentoo_Hardened_YOK4NJmGwq4_2_68508_68602.png