 Hi everybody That's it. Hey everyone hear me. Okay. Thank you So first a bit of an introduction. So it won't be a really technical presentation. It's more about giving some feedback about How are you and our contributions? In Linux security where I work from so who am I and I said in a said I'm evil except Paris. I'm French. Sorry for the accent. I'm working at INS si which is in French agents national security the system information And I'm a team leader in a in a lab which is working on hardware and software architecture, so mostly it's interaction between Software and hardware and especially operating system security like Linux. Obviously some right micro kernels We do a mobile an omitted device security. We develop Clip OS, which is a Linux distribution And I'm also a DBN developer working on the security team and the kernel team and some other stuff I'm mostly interested in low-level security and hardening including obviously the kernel About INS si so The INS si is a French cyber security agency Contra a bit of precision. We are not an intelligence agency So contrary to some other models. We only do Our task is to protect the French government networks and systems We have in the French government as other agencies which do intelligent stuff And we are only tasked to protect our internal networks Inside the agency, so it's basically like maybe 500 people inside the agency We have a specific part which is called the labor laboratories, which is basically some research part and we have a we are the pool of expertise for other other people in the agency And we advise them about cryptography networking operating system everything related to security We do some research in development Some academic publications and some free software contributions French government is a large user of free software We are not the only ones but like I know about this one. So we do a lot of we use a lot of Linux distributions Here and there We also use a lot of free software applications Again on servers and workstations We are the French government is also a free software contributor and free software producer. So we There are some quite large Free software project which are actually actually develop it inside the French government There was for example, I'm not sure how much it's currently developed that the SPIP content management system is done in from a French team initially We have some other agency which maintains a repository repository list of values free software contribution by French administrations and recently so in 2016 A law was passed which actually made The data produced by the French government Available As opened by default and it includes a source code. So basically By default a code produced by someone in the French administration should be public Some to the current situation with Linux specifically. So we are the French government has a large Linux usage Obviously, we are we run a lot of servers on Linux and from various distributions community or commercial We have us and we also use a Linux based appliances like for firewalls ideas VPN, etc And here and there are some Linux workstations And an SSI is tasked to secure. Well, he is responsible for to protect various French networks But we can't do everything we are five hundreds so we try to delegate a lot so we try to basically produce documentation recommendations for various IT systems and We try to actually secure stuff the more upstream possible. So it ends up being used for values administration, whether it's a Ministry of Defense or the Education or culture or whatever So we try to secure to provide some Recommendation and contribute where we can where we can and we try to organize a contribution when where it's possible so let's talk a bit about past and current Contributions so we produce actually a lot of documentation. So we we try to To provide insights to various users administrators and developers So I'm sorry the documentation is for now mostly in French But we do some Linux distribution hardening guides. So recommendation and Hope on how to secure secure dissolution in one since it's installed and it's oriented towards system At least administrators as well as the produce developers for example for appliances We are currently working on a Linux channel hardening guide in French with it, which is basically Which tries to takes values recommender existing recommendations like the KSPP recommendations stuff like that and turn it into something usable by a French system administrators We also have some specific documentation like Stuff for produce the developers and for example, I'm I really come to back to that just a bit later Some security architectures for ClipOS form and some documentation which this time is in English about the security architecture of a ClipOS 5. Every link is in the slides. So you will be able to A bit of what about ClipOS. So it's a it's a Linux distribution Which is developed internally inside the agency since about 2005 It's based on Gen2 ordnance and it's It was intended as an internal Distribution for the French government. So it has some specific Usage restrictions, it's a well It's supposed to be under under under like For office work, it's not developed developer bugs or something And so it includes a specific canal hardening and it should be it's supposed to be used as a multi-level operating systems and we recently Released it what really the specific bits as a as free software. So as a beginning of a set of step to September so we have some some feedbacks about using a hardened System inside inside the agency and elsewhere. So as I already said, it's So it's running inside the administration for 10 years and it's used by non-technical users. So basically it's for office work and Actually, we didn't have that much user complaints The first one usually being usually that it's not Windows And so there is no Microsoft Office or outlook or stuff like that Obviously, it's it's a problem if you use to that But we didn't have that much feedback at least not negative feedback on hardening and security measure Even though it's actually quite It's not really permissible for example, there is a strict Right or execute policies. So for those not familiar There is no place on the system when you can add at the same time. I have right permissions and executable permissions So whether on the file system or in memory if you are able to write somewhere you can't execute stuff there Basically, it's to restrict an attacker. So an attacker Which would be able to execute code by exploiting a vulnerability wouldn't be able to then import it around tools That's something that technical users are missing obviously for example the Dual security level is interesting for our administrator. So they have one one environment it's a full-over environment which is Connected to the for the standard network and an isolated environment which is connected to the administration network That's something Administrators really like to script stuff and it's not really possible on on clip. So there are missing that but besides that We don't have a lot of negative feedback for developers it was a bit harder because Clip-wise is actually a complete complex beast. It started in 2005 and it wasn't really intended to be shared So the development was mostly internal we tried to share it with some some people but It's it was on an isolated network which has some issues when you try to Synchronize with upstream do the standard distribution maintenance And the two-channel SDK was a bit complex So we had some issues and we have we got some some feedback for that for the following what happens next and What happens next is that we recently started building a new version which is the version 5 Which has basically the same basic and same specifications as a Clip-wise 4. So it's Internet for a managed managed networks. So it's not something which will be useful for And And user trying to just secure themselves. It's it's internet to work inside a managed networks It will be hardened. It is hardened linear distributions internet for non-technical users And we'll try to make it work for administrators and still have the multi-level and security if I've talked about But we have some different choices So for example, we try to do open development from the start So the current development is already public and and we'll try to upstream relevant code directly because we have When you don't have stream code, usually you end up being late and the porting the phone Porting is hard to do especially for the Linux kernel which moves really fast and we like to share a bit more with the community and We have a modular design and tooling in order to facilitate forks and areas in derivative So we intend to do some stuff ourselves, but we know that some people might want to Do some derivatives and we'd like to we'd like it to be easy so people can contribute back easily and if they fork some some stuff say Is that the synchronization with us and with us team is Will be easier we will try and Basically, it's it's intended to be a state-of-the-art implementation of INSSI recommendations. So I mentioned the documentation Earlier, there are some things we are as a French defense authority for for computer Systems we have the possibility to impose stuff to force administrations to respect some recommendations and This should be something which is compliant with this recommendation a bit of word about the clip us five kernel. So It it has some some objectives and security objectives and when the first one being to provide Isolation primitives to user space. So I mentioned it's a multi-level Multilevel system where you have Complete environment which are isolated the clip us five kernel should provide that it should maintain some trust in hardware resources because it's mostly intended for a workstation, even though it will be useful for servers to and a workstation needs to have hardware access for stuff like network card for Graphic card, but also usb token usb keys and stuff like that So you have to maintain some trust and be able to select which which environment gets the hardware token and Obviously guarantee some canal self-protection because if it provides some useful primitives to user user space it has to protect itself so we mostly doing some Mainline hardening We rely on Stuff provided by mainline for example the case PP recommendations which are also to minimize the attack surface by just basically stripping Everything which is not useful And we try to err on the security side rather than performances. So we have some possibility since we are not generic distribution to make Saints secure choice by default even though it might have some Usability or performance Drawbacks We do rely on some out of three canal patches. We try to limit them But we still rely a bit on some of them Which are somehow well known for example we rely on Linux on which is somehow an instant station of Last public just security and packs patches, but with a lot of evolution We try to include some bits we rely on lock down but a patch series which is intended to Separate canal access from super user access. So it's not because you have UID zero that you should be able to do whatever you want with the canal So more strict isolation between user user space and kind of space and you also include the static leak theory and the idea is also is to Improve canal hardening security inside creeper side But also to provide some kind of test bed for the other new features which are considered for upstream and for example Try to provide a real life feedback and maybe help inclusion into mainline We also try to in the long term minimise differences with mainline to facilitate synchronization Some current contribute past and current contribution which are initiated by the agency to There is long lock for example. So it's a patch by Miquel Sana, which is working in my team And it's it has a way it has been presented in Linux security semi North America The submission process is ongoing and what landlock tries to achieve is Basically unprivileged unboxing. So it's enabling application developers to provide a secure security policy Which it's a bit like second BPF, but it's not restricted to Cisco rather. It tries to provide a meaningful access control for every every canal object And it's implemented as a as a lesson in a security module And I'm going the process is ongoing and we hope it will be really need to lead at some point That's all for now on the current contribution, but we have some more important plan One interesting thing which comes from Clipo s4 and will be entertaining Clipo s5 is a New flag for open system call, which is all my exact It's basically a way to enforce and extend the wx or x policy for scripts So right now if you try to see if you have a non executable Moon points You can still execute script from from there because an interpreter will just read the scripts And so actually it's possible to extend some To support no exact from For scripts, but it requires some interpreter patching. So we propose some some new flag to open which would be set by interpreters and The canal could then decide to restrict the system call So we already have all my exact in Clipo s4 so the patch are already available and When we started to publish Clipo s4 and we'll try to upstream that bit It's definitely not It can't be integrated right now because it's really a static and we need to do some rearchitecturing We have we are looking into some options like for example, we try to replace the art code policy But with just a system one runtime configuration. So for example assist detail maybe and provide a way to For the Linux security modules like as a Linux to provide more fine-grained policies. So maybe supports a Local policy local policy depending on from where the script lie I realize it So in terms of timeline we hope to have a first We have currently internal drafts and we hope to provide a first RFC by the end of the year and will integrate into Clipo s5. I mean while so we have a Real real life feedback of the rear New architecture Some thing else we are interested in is the server so for those who don't know about about it It's a patch available since quite a long time for containers So before there was a elixies and occurrences like that and even before namespaces and c-groups This is there was some the viscera patch which has Which basically provide from in the canal a unified container infrastructures Like for example per container identifiers and capabilities and flags network capabilities and flags It's a large external patch and I don't think there are any Linux sub streaming plans It provides a lot of different features, but actually not all of them might be useful, especially right now that we have Already containers based on namespaces and and c-groups But some bits might be useful and we are doing with the idea to do that for example as an LSM and What is what is interesting is using the container ID so it's exciting in viscera Which can then be used to provide control access control decisions So basically right now is a kernel doesn't know about containers. It knows about namespaces and c-groups, but there is no such thing as Containers and while it might be useful in some cases to not tie Containers are something Known for a user user user space, but having the concept in kernel might be interesting We don't have a specific Timeline and plans so we'll see how it happens and will I guess use the clip as far as again as it has been so as a conclusion as I said French government is a large user and contributor of free software But for the kernel part we started to contribute and contribute more only recently So I'm definitely interested by some feedback on is our work useful. Is it enough? and a bit of Question on what what can we do next? as there are some specific items Which would be interesting and More generally when which direction as a French government on the security side could help So if you have any question So your v-server notion flies directly in the face of the container communities Kind of flagship claim, which is that it's not containers on a kernel construct How do you see dealing with that? Honestly, we we don't know. I mean we are aware that it's it's been proposed here and there and usually rejected but Again, we don't know exactly how we'll present things. It's something with we are doing with We know it's useful in our use case and having maybe having it as a Integrated with some LSM concepts might be actually Actually useful so we don't have We don't have code obviously, but we don't know we don't have a complete architecture specification either. It's something we are considering but We will try to draft something and then propose it to the community community, okay and the only other thing is this kind of interesting notion here is that What the one way you could do v-server is Would be if you use smack and s e-linux at the same time With smack providing what you're looking for from v-server and then s e-linux running the way it currently is So that I kind of appreciate the fact that you've actually presented a plausible use case for that So, thank you Don't I didn't have to talk So I'm gonna apologize up front to you. This isn't so much directed at you, but more as to Casey so Other than trying to promote your stacking initiative. What was the point of that last question like I don't understand how that would even work Maybe we will take this discussion to lunch. So Thank you so much for Bring up. Oh may exec that sounds like exactly where I would like to see things going and I Assume that you're not gonna limit only to Python But to be have the enforcement in user space in other Script interpreters Where have you posted any patches on For Python yet So we know right now we we didn't submit any patches to upstream whether in to linux or the interpreters, but in the in the source code we published for clippo s4 There is the current patch for for the linux kernel. So the link is in the references I don't think as a link for interpreters is present. So it might be a bit Hidden in the source code because we published a lot of things in various projects But as far as I remember we we have patched patches for pearl Python bash well not bash because it's a we don't have this batch Busy bucks, but the busy box shell And maybe some others, but it's there is no single place to look at for now I can try to dig to dig them But it's the patch is for interpreter right now It are really simple because it's just about passing the omate exact flag at the right place For example for Python. It's when you open the You open the script directly or you open modules and stuff like that That's it. So is it enforcing when you open a file? that that file can only be executed as opposed to Later on other words the interpreter knows whether or not it's opening data for data And it's knowing whether or not it's opening data for being executed is then are your patches? enforcing that distinction with the may exec well, we we actually The interpreters patches We rely on interpreters. So we have to trust that is that they are doing the right thing and the patches are Tuned you the values open system calls So as I use omate exact when they are Actually execute opening a file for execution. So we know because the interpreter knows when What it can do with with a file because it's it's a it's a script or because it's a module or something and we don't do that for example because when Python opens something else. So it's really something which needs to be tightly integrated in the interpreter You might want to consider enabling this and and in terms of policy I'd be interested in using this for I'm it to be able to Validate the signatures and once getting opened. Yep Actually, I did not mention that but we have also in in clip was for some patches to actually tagged executables and a lot of stuff which has been done differently in the canal, but we We never submitted it at that time. So it's duplicate work Anyway How do you handle the problem of mixing code and data like for example, if there is an Libre office file with macros It's a bit difficult from a conceptual point of view, right? Yes We don't I mean We know we won't have a perfect coverage because basically anything can be done can be turned to into Some code executions, but we have some longing fruits. So obviously scripts standard scripts We we have some way to in in clip OS 5 and for to restrict for example Extensions in Firefox and some numbers and stuff like that. So we we considered those The programs we can be done. We can which can use some data and execute things from from there But we know we we wouldn't be able to do everything for example We know PDF can be used to execute code Java JavaScript obviously We can't really prevent exception. So what we are really interested actually is a way to to prevent To to enforce W or X policy for things which can do system calls Basically, if you can't do system calls we it's a it's a bit It's a bit easier. Thank you. I Think we have to thank the speaker now