 Okay. Hello everyone. My name is Mikkelsen. I work for Microsoft and I'm the main owner of the Lannock LSM and this talk is about an ongoing work to improve Lannock and to be able to log stuff, to log denials, to ease sandboxing. So Lannock was merged two years ago. So it's kind of new but it's still enabled on most new distros and yeah they're still ongoing work. With new kind of versions we get new features. We can restrict more and more and with an ongoing one we'll get support for audit, the audit framework. So just a bit of context. So what I call sandboxing is mostly a secure approach to isolate software component from the rest of system. So it should be innocuous and well even if this innocuous interest processes well they can become many issues during the lifetime. So two main sandbox properties that we are looking for, well to close the list privilege principle, we don't want to give more privileges to processes, to users, to just enable them to sandbox and to drop religious. And what this should not harm the system nor other processes even from the same user. What is Lannock? So as I said it's a Minux security module that can force mandatory access control but that is available to every user on the system. So it's quite similar to SecComp but instead of filtering syscalls you can well enforce an access control on files and later you'll be able to do the same for network and other stuff. What is an interesting with that is that if you can as an application developer you can emit a security policy, so sandbox definition into your application. So you don't need to ask a sysadmin or the user to install to do some system-wide security policy configuration and so on. From the user point of view it is and it should be transparent but if the user can have what can run your application on not too old channel it will get more protections even if your application is compromised. Okay so first I will start with what are not what is not the goal of adding support for auditing to be able to log stuff for a sandbox. First, Lannock is designed to create sandboxes so it is not its goal to track every access you can think of and as a matter of fact that is not possible with the LSM framework because of the way it is designed, designed mostly to deny actions so LSM may not be able to see every activity on your system. Once it's denied by something even regular permission the LSM will not see the access request and that's good for performance. But if you want to trace stuff well these are BPF, the F trace and so on. What is the goal of adding support for audit to Lannock? Well there's several use cases, several users that might find this interesting. Well app developers want to well speed up that development and to know what is going on and well it will make the life easier to see why stuff are blocked and when and by which process which is fed and so on. Some users I guess some from you will like to understand what is going on and why their application cannot access some stuff. So that might be something interesting and more transparent. System inspector or even people that can well that are in charge of fleet may want to take a look at what are the access denied that are logged and if they are common if they are common to multiple users or not to be able to extract some pattern and then well fix that. And when you're well using this kind of sandboxing, this kind of security feature you may want to know if it is indeed enforced and for how many processes and if it fits your configuration, if it fits what you expect. And last but not least for well let's say security experts well having logs and especially denials well can be useful to detect attack items and yeah it can be some can bring some clues to follow the track of an attacker. One of the main challenge with Sloanlock is that it's designed to be used by infrared users so there is no way to well there's some limitations from the kind of limitation and well we need to take that to account and that is also that can impact the way you log stuff. So some things to keep in mind that security policies are entourage. You can have and in fact you should have system, multiple and standalone security policies so one per application. They can be nested. You can have a security policy for shell or for web browser or for any application that can also launch other applications. And everything is dynamic so at one time application can decide to restrict itself and when the application is gone well the security policy for this application is also free. So what we like to have in our log and why in fact do we want logs? Well we like to be able to identify what is relevant. When something blocked an access well most of the time we are interested by knowing which was the latest applied policy that blocked this access because again landline security policies can be nested and so most of the time what you want to know is the latest one so the one which is applied by the application that the shell for instance. So what was the issue with this policy and what you want to know which accesses might be missing. Well are missing if this access is legitimate. You may also want to identify on the security policy hierarchy where you are and which parts which node as if sandbox hierarchy block the access. And well if you're passing Aussie's log and so on well you might know when it's not given to keep tracking office specific sandbox anymore if it's gone. Another thing to keep in mind is that logs and especially logs coming from the canal are and should not be available to invalid users because they contain they may contain sensitive information. And yeah so this is implemented thanks to the Linux audit mechanism. So I just sent a battery this morning. It looks like it's not yet in the log canal mainly Sakai but it should be soon. Okay let's see a demo that would be a bit more explicit. So at the top of the screen is mostly your tail of the canal logs and at the bottom so I'm log what in this case as root user but I could be at any user. And I would like to launch a shell in a sandbox. So for this I'm using a tool called sandboxer here it's part of the Linux kernel samples. So in samples and lock the sandboxer that you can compile it and use it. So it's really a simple sandboxer. Yeah many other an example. So in this case I'll create a new sandbox and there's many two configurations. First one is the set of path that we like to be accessible in a read-only way. And second path configuration is a set of paths that I would like to be accessible in a read and write way. So that is quite common. You want to access TMP to write some files but also you also need to have access to slash user slash bin to execute binaries and load libraries and so on. So let's launch this and what you can see that is a few audit entries actually. You can see which application launches this well create is this entry. What was the operation in this case it was a set creation because sandbox application created a rule set and you can see the description of this rule set which is mainly that this will set can handle and by default block a set of access actions which are here. So you can block execution, write, links, migration and so on. Then with the second entry we can see that the application this process is thread as to restrict itself to sandbox itself. So it is creating a new domain in this case domain 2 and what you can see here in the first part is that we created a rule set just named one with ID 1 and then we are creating a domain with ID 2. We are creating this domain from the first rule set because we need to first define a rule set as a policy and then to enforce it which then creates a domain, not a domain sandbox and you can see what is no brands for this sandbox. Then while you can see this will set release because they will set and the underlying file descriptor is closed so the reset is released and then you can see your first scenario with the open action. So in this case it might be the open syscall but it might be the open artist call so it doesn't matter so it's really the action to open a file. This open action got return value 13 so in fact it's a e-access or the access was denied and you can see why it was denied. There is two missing file system as this is right file and we file. You can see that this missing permission which is empty which is that later and you can see where well why and on which kind of object on which file this action was denied. So it was denied so the shell tried to use to open DevTTY for some shell stuff and was denied because it wasn't part of the policy. So we can continue, you can try to instance list the content of slash which is not allowed because it's not part of the policy. You can only read the content of some directories but not a real detective and in this case well you can see there's a new process LS which is a sandbox by domain number two and the open action well was denied. You can see the same error code and you can see well it was denied because this sandbox is not allowed to read the slash the root directory. So yeah well the stuff can go on for instance you're not allowed to amound stuff so in this case there's no strictly speaking well policy defined access rights. These are by default this is by default denied because it will be able to it will allow to bypass it every see. So it is denied by default and you can see why. There's a what I call a missing permission which is specific to LANNOC and it is 5.7 layout. So you are not allowed to change 5.7 layout otherwise well the policy you first define will not make sense anymore. And last example you should also be able to trace some processes inside the sandbox but not processes outside sandbox. So if an instance should try to trace process let's say PD1 should not be allowed and that is in fact not allowed. So you can see the P trace operation from the scanning point of view requested by the S trace program was denied by domain two because there's a missing permission which is what I just say you're not allowed to trace processes not in a sandbox or not in a nested sandbox. Okay that's it. So what's next? There's some missing features so it suffers AC batteries but it's still in testing and one of these missing features for instance is well it's not only for the feature it's for other stuff to read it to LANNOC but it is the ability to be in shell freeze and restore processes then thanks to the QU framework. And for this there are some changes too. We need to be able to reproduce the constate of sandbox. So for this well a use page process, a pre-lege process should be able to read some well more LANNOC domain properties to be able to create a root set that will mimic this one and then we'll then be able to restore a full system with this mechanism. But for that we also need to be able to reproduce IDs, domain IDs, reset IDs to match them fit with the logs and whatever information you can you could have from the previous instance of the system. So yeah what you could do and what is done for the mechanism, mechanism is to be able to what to expose these IDs and to be able to set them to date them if they're not set. But you need to be careful there. This needs to be a pre-lege operation and only in this case in the case of process restoration. And yeah that should not be used to bypass anything or to get information about anything which is not really known but to process performance this operation. You could also compare this kind of feature with what can already be done with SecComp. Even if SecComp is really special because SecComp can only filter syscalls and their argument. So you don't get the kernel semantics, you cannot get bypass, you can get process IDs or stuff like that. But SecComp is also one syscall and can be configured by the user, the application developer to log or not some actions and that can also be well allowed or denied by the system and etc. So we might also want to have this kind of stuff or maybe better way to filter audit entries. Other stuff I like to have one day is the ability to expose more internals, more information about the sandbox, how a sandbox is built, what it really constrains and how much for instance a specific pool from the whole set did actually block an access request. And that will be useful to know well if there's something special happening if an application is trying again and again to access something but it is denied so maybe what we should treat this application to not request so often. But again there's some challenges here mostly about the ideas because the interface will be accessible to interest users. Well we cannot for instance use sequential IDs because that will kind of leak some information about all the sandboxes and yeah we don't want that. Yeah it might not go through all the points here but I think you get the idea. It will be to expose a new system that will mostly be useful for developers and that could also be able to allow it to trace at runtime what is going on which would be kind of complementary to the logs. So if you have any thought about that I'd be happy to hear about them. What you would like to see in your logs if you're submitting applications and what you would like to not see in your logs because you don't want to clutter your logs with useless information. Yeah so I sent packages this morning. It should be available soon well in the lower candle archive main list and yeah feel free to test it and to send it back on the main list. A quick overview of the roadmap, the ongoing and next steps for a log. So there is ongoing work to support our results. So this is a work done by Gunther Noack and there's ongoing work to support TCP restrictions which is the work of Constantin. So all these are ready in good way moving forward and I expect to merge them in maybe one or two release. Well it is now a new part series for the support and of course it's well some ideas to improve performance of this sandbox mechanism but yeah we need to have time so if you want to contribute feel free. Thank you for your attention if your indication you can ask me now or later I'll be there all the day and if you are still there after the lunch I'll give another talk well a workshop about how to sandbox an application and I will be explain with a vulnerability exploitation of image magic. I now do one but still interesting. Thank you. Any questions? Okay so I hope to see you this afternoon and if you want to come and to do the workshop please follow the instructions since it is on the schedule and yeah you need to install vagrants and start that. Thank you.