 La prochaine présentation c'est... DJSS et SNMP attaques donc il faut dire ça Nous pouvons le faire avec ma présentation mais la secrétaire, le Kernel Level C'est pour expliquer à vous que le Kernel a quelque chose à faire en sécurité que quand vous voulez faire la secrétaire le Kernel a un rôle à jouer dans la politique de sécurité donc je ne vois pas mes screens donc je vais devoir regarder les screens donc j'ai dividé ma présentation en trois parts la première est de pourquoi faire la secrétaire dans le Kernel Certaines personnes pensent que le Kernel n'est seulement fait pour la machine et la secrétaire doit être faible avec d'autres applications mais je vais essayer d'expliquer et de communiquer que les choses peuvent et doivent être faibles à le level Kernel Ensuite il y a une partie de comment acheter la secrétaire et la troisième partie il y a des applications qui existent et donc la première partie on va commencer avec des contextes et ensuite je vais introduire une nouvelle modèle de secrétaire en fait c'est un autre moyen de voir la secrétaire donc comme vous le savez il y a des choses que nous aimerions être protégées donc tous ces trucs nazistes pour cela nous devons assurer 3 mots que vous le savez bien qui sont la confidentialité, la intégrité et la disponibilité et ce que nous faisons à assurer c'est que nous défendons un set de règles qui décrivent la façon dont nous protégons et distribuons l'information et c'est ce que nous appelons la policier de sécurité et pour renforcer la policier de sécurité nous utilisons la software de sécurité nous utilisons d'autres choses mais c'est partie des choses que nous utilisons et il y a des choses pour faire des checks d'intégrité il y a des choses pour faire une confidentialité et des choses pour faire l'authentication mais la vraie question est est-ce que peut-on croire ces softwares ? pour expliquer à vous ces choses il y a une petite analogie donc let's imagine que nous avons une maison avec des cookies dans cette maison et nous avons des mailles que nous allons essayer de manger les cookies et ce qu'on veut c'est de protéger les cookies donc je vous propose deux solutions la première est de essayer de protéger les mailles pour aller dans la maison pour ressentir tous les portes pour ouvrir les portes et les portes et la deuxième solution est de mettre les cookies dans une boîte métallique donc ce que je vais vous demander c'est de penser deux minutes sur quelle solution sera la sécurité qui ne sera pas si vous essayez de penser à ça on va vite trouver que vous ne pouvez pas répondre la question facilement et la sèche c'est très difficile et vous ne pourriez pas être sûr que la sèche est bien sèche mais la solution avec une boîte métallique est très facile en fait avec la solution 1 vous ne pouvez pas être sûrs que vous avez rempli tous les portes si vous n'avez pas des mailles dans la maison vous ne pouvez pas être sûrs mais vous ne pouvez pas croire cette solution et avec la solution de la boîte métallique vous avez quelque chose que vous pouvez ajouter parce que c'est très petit vous pouvez le rassembler entièrement et c'est une meilleure solution donc si vous devez choisir je pense que vous choisirez la solution de mettre les cookies dans la boîte métallique pour les modèles c'est la même chose pour exemple avec la machine avec une grande périmètre qui est en fait la sécurité physique de la machine ce qu'on a dans Black & Yellow c'est la dernière défense qu'on met souvent dans les machines et pour exemple si quelqu'un peut break in en utilisant par exemple le son il peut attaquer une pièce de software et il a went into our last security perimeter now if we use this model we have a smaller perimeter to defend we have of course we try to prevent something to get into the machine but once someone has succeeded into getting into the machine we try to defend the canal too and our last defense will be the separation between user space and canal space so to use this model we must patch the canal first to protect the canal itself so that we reach a state where the canal space is trustworthy and then from the canal space we try to enforce a security policy we try to protect everything that is involved in the security policy or in redata that is related to the security policy now how can we do that in fact the fact we decide that the canal space is a good space a good place to do that in that in every computer nowadays computers we have a memory management unit that will do a hardware separation between user space and canal space and we will rely on this fact to in fact being able to ensure that everything from user space can't go into canal space we will see in the first part that we can enumerate everything going from user space to canal space and everything that can be done on the machine can be filtered because it is going through canal space then we will see in two parts on how to defend canal space and on we could do to filter in canal space so this is the machine this is the computer and we have humans that will try to target some things like storage from FPGAs of the canal or another application that is running on the computer to reach a target it must go through some physical security layers one which is a real physical access to the machine if you can go if you can do that I mean with a screwdriver or anything it has one and you don't have to I mean the physical security is the first point but it's not the point of this presentation the second point is that you can go through an action layer for example the keyboard or the network in the first card to go through the canal and give commands to an application that is running in user space so you can reach an application like that from this application you can reach for example a storage media or prom or FPGAs but as you see we can still go through the canal then we can try to target another application you see there are two arrows the arrow number the 10 can't exist on architecture with a real memory management you need because it's not permitted in protected mode you can try to target the canal because the canal is a target too and you have to protect it so we have seen that there are a lot of paths to to reach a target et en fait le fact that we have a small perimeter to defend make that we we have not so many paths to to protect first we will rely on an hypothesis is that we have an interface without bugs that does not exist but it's an hypothesis and we must do that to carry on et pour exemple as an hypothesis we say that each key you type and a keyboard will go through the canal before giving an order to an application and we will as an hypothesis that typing on the canal can't make you take the control of the canal then we have some defense to achieve attaques to the canal can go through devmem or devkmem or insert loading modules into canal space there are other ways to do so we will see later and then if we want to if you want to filter access to to storage media as you can see everything go through the canal is a good place to filter that so a little parenthesis about the bugless interface is something that's a little my opinion because the mechanism you use to do canal programming make it harder to do classical programming faults bugs are still possible other classes of bugs but in fact we did not have seen a lot of vulnerabilities on kernels so the hypothesis is not true but valid for us then how to protect the kernel space when there is someone when there is an intruder in user space we have to block to protect every entrepent from user space to canal space there are few of them and they are all granted by the kernel so that's easy to block them for example this is some source code from the Linux kernel you just have to return minus ePerm to block slashdev slash mem slashdev slash kmem or slashdev slash port so it's very easy to hack into the code and block this kind of entrepent the same for the module and session you just have to return minus ePerm and this entrepent is blocked so that's very easy to do or to control and then if you if you want to filter things we must protect we have to to know what we want to protect we have a few classes of things we want to protect it's what's on memory what's on disks and every programmable hardware like recent CPUs BIOS all this kind of stuff can be must must be granted by the kernel to be completed so to protect that we have to as every queries are done through the kernel through system calls or device calls or cctl we have to to modify their behavior in a consistent manual to enforce security policy so a good way to use modular architecture to control kernel calls because there are a lot of access control policies and our aim is to try to enforce control policies that is that is I mean you have a security policy and the security policy will say you which access control policy you have to implement as there are a lot we try to be modular and to for example in a system call we try to put an infrastructure code so it's a component that will go into the system call and the infrastructure component will ask the decider component if access must can be granted or not and it's the decider component that implements the access control policy and you can change it as you want so it's a way to do so and it's a way almost every software do this kind of stuff works so how to add the enforcer code in a system call for example because you have to do so in device calls too you have two ways of doing so for example we have the anatomy of system call you have an application that ask for a specific system call the instruction pointer will go through a dispatching code that will decide which system call have been called then give on to the system call that will do his job and then go back to the dispatching code that will give the on back to the application with a result so we have two ways to to modify things either we patch the dispatching code and we go we catch every calls to a system call in one patch or we patch every system call for example open or kill or things like that so an example of system call interception it's about it's the code comes from mid user ds9 so they put some small piece of code in the dispatching code that call their on access control method that will try to decide which if the system call that have been asked for can be executed or not so there are some advantages it's very general system and it's low cost patched as you see with only these ten lines of assembly you have intercept every system call in the code is that you have some kind of duplication of every system call because each time you an application ask for assist call the code of mid user will be executed and then it's another drawback is that the mid user function has to know which system call it was try to decode parameters try to check if there are no no error in the parameters to interpret it correctly and another problem is that it's architecture dependent at least on minix I think in BSD it's not so architecture dependent but it's drawback on minix another example is about a system call modification for example from LIDS you have a function and then you just patch it to to do the check to call the decider component what we can see is that the decider component can take arguments from parameters that have been checked and decoded so that you don't have to do twice these checks and decoding and you can put the code everywhere you want so that it's very more powerful so you have great tuning power up because you can alter the code to do almost everything you want to modify the event you can even modify the behavior of the system call for example transforming it to something that's not so compliant it's more secure and drawbacks is that you have about 2,000 system calls and a lot of them have to be patched and they have to be patched in a consistent manner to reach a consistent security policy so something that will be thrown in kernel is the linux security modules so in fact linux security module is a patched linux kernel and it's only the enforcer component for example it's a yellow line it has been put in a specific part of the system call and it's just a call to a decider component and the decider component can be everything it can be lits, it can be security linux it can be everything that is conformant to the way the way communication has been decided to be between the decider and the enforcer component the name linux security modules by modules you have to understand modular because that means that you can have a lot of decider components then we will see some implementations that exist so there are a lot of projects that do a security at the kernel level OpenWall is I think one of the orders maybe there are also but I don't know GR Security LIS, mid user DS9 PC LOMAC, security linux there are lots too they all work on linux kernels there are others that works on BSD like Cstrass so OpenWall is not really what I've presented that is it's not something to do access control in the kernel it's only a collection of security related features for example there are some the famous non executables user stack array and other things related to security GR Security it's has begun with the patch from OpenWall to 2.4 kernels and then they added an ACL system which was called Oblivion then they switched to a process based system that looks like LIDS system ACM system they also implement packs which is another patch for linux kernel to protect user space from buffer of the flows and other kind of bugs that could occur in user space like they do stack address randomization etc then there is LIDS I don't go into details cause there will be a presentation tomorrow so it does search protection of the kernel and LIDS itself process protection, file protection some special features to do online administration other special features to be able to rely only on kernel stuff for example a dedicated mailer in the kernel I mean if someone break your send mail you can't rely on it anymore to send a lot so there is a kind of mailer that works online in the kernel and that works for it so this is the way it works I go fast then there is Medusa DS9 which has an interesting concept that is there are a lot of layers of abstraction and the decider component is in fact a user space daemon which will decide in fact the enforcer component will ask through a device driver to user space daemon if something must be guarded or not so user space daemon make implementations of access control policies very easy to do it's just user space programming you can do it in shell if you want but there is something in user space and Medusa rely on the system call interception RSBIC is something that's based on the GFAC which is a generalized framework for access control which is a kind of access control it's the same that it's equivalent of LSM and then there are a lot of access control policies that have been implemented and that are given in the form of available kernel modules and there are a lot of a lot of them like control policy functional control one which I like a lot is that they have been able to implement malware scanner as a a decider component that plug into the framework for access control it's something that will scan every program you execute to check for virus or anything so in fact the decider component can be very it can do a lot of things another interesting thing is low mark it's something based on low watermark integrity it's something I find very cute it's for you have initialization some specified directory are in high level and other directories and sockets are low level in fact you have two conceptual levels high and low and there are rules that will decide on what will be high which processes will be high which will be low which process which processes can do what so processes are created from a high directory will be high processes created from a low directory will be low high process can read a file in high directory but low process can't read what is in high directory and if high process read a low file it will become low so that's that's that's cute I find but there are some exception because something like that can't work there must be exception for example processes must write to syslog your logs must be high so the syslog daemon must be high but it must read something which is low because every process must write into the log and so that syslog have to read a syslog that is low and there must be some exception to make the model work then security non slainx is something that that is I find that Lomac is the legal brother of security non slainx and it's based on very old not old but something that is 10 years old the flask architecture is 10 years old they have worked a lot on it and there is also an enforcer and decider component no security non slainx can work on top of the linux security modules and not like the other project they have worked on to the revocation that is if you change the write of the process that has already been launched the write will be propagated to already running process and they will be propagated write at last the linux security modules so they will be included very soon and maybe they are included now I have not checked and they are in 2.5 and it's only a framework access control policies as you want and you don't have to compile them as module as the name suggests you can compile them in a kernel so that's all so if you have any questions I think you don't have a lot of time but no I think I was very clear so thank you