 Hi, I'm Witmoj Žiš. I work as a Selenix user space maintainer at Red Hat and I'm here to talk to you about one of our team's latest projects, decentralized Selenix policy, or custom Selenix policy modules done right. The agent does pretty simple, so I'm not even gonna bother you reading it aloud. Let's get to it. What is DSP? It's a project to decompose monolithic Selenix policy and align it with projects and products code base. Wow, that's a mouthful, so let's pick it apart. Hopefully, most of you know that Selenix is an implementation of Linux security modules. And it's aimed at confining processes in their own space, so that even if they get exploited, they can only access the data they need for their normal operation. So basically, a Selenix is protecting other processes and the host system from consequences of exploits. Now to do so, it's using security policies. These policies are basically files describing all the access the process may need to work properly. Usually, they're all delivered together inside a Selenix policy package. And this project is aimed at actually taking them from the policy package and shipping them directly with the software they're corresponding with their designed to confine. Why would we want to do that? For that, let's have a look at how a new feature gets developed and released in a project confined by a Selenix. So after it gets developed, hopefully the new feature gets tested with a Selenix and any policy issues get reported to a Selenix policy component. And eventually there is a fix for the issue which gets retested and maybe this issue was hiding another one so this cycle can actually repeat. And when that's done, the feature can be safely released. But it can happen that the updated policy gets to the user after updated version of the product itself. This can be due to the fact that the user has updated policy or maybe the product was released in with a different schedule and therefore it got out sooner. But in either case, the user can end up with issues with the software. So this project is trying to get the policy closer to the developers and integrate it into the development process of new features. Right, let's have a look at all the benefits. Firstly, as I said, the security policy is always up to date. So this actually means more stable functionality because none of the features should be blocked by the security policy. This can also mean that the new functionality doesn't have to wait for a Selenix policy package, the updated Selenix policy package to be released. This is especially important in projects which have different release cycles than a Selenix policy and therefore there might be longer wait. Secondly, the threat surface is decreased. This is due to the fact that the policy, when it's maintained by people who actually understand the software and all its needs, can tighten the policy to be as strict as possible while still allowing all the features of the software. So this ends up benefiting the user because it can mitigate or even completely block some exploits. Another benefit is that well-defined policy can actually help you find issues with the software because a Selenix is reporting any access it blocks and it can therefore report any misbehavior of your application. So it can help you find issues in your code. This is actually happening even without this project but to a lesser degree obviously because the policy is not so well-tuned and also the policy fixes can be better and can be delivered faster. They can be better because as the product maintainer you understand the recent changes that took place in the software and can tailor the policy changes to them. Since you have all the information you can deliver the fix way faster and also since the policy is delivered together with the product it's always up to date. Okay let's move to features. What is actually part of this project? First off we have a packaging guide that's a step-by-step guide to package your custom policy. I'll talk a bit more in-depth about it at the end of the presentation so let's keep it for now. Second we have a guideline for a Selenix policy API. This is a document that can give you an idea of what policy changes you can expect in given time frame. So for example when new classes types or interfaces can be introduced and when the policy should be stable. The document is targeted at well but can give you an idea about Fedora as well. Third feature is our AC troubleshoot bug reporting. AC troubleshoot is our bug reporting tool and also troubleshooting tool for Selenix denials and this new feature allows it to help users file bugs against the component that actually shipped the policy and not against a Selenix policy. So this way you get the bugs directly and faster than you would before. And the last our latest feature is test suite. It can help you identify policy rules that are too benevolent. Maybe find policy writing practices that are not ideal and can end up causing issues in the future and also some packaging issues. Let's get to concerns you might have before taking a part in this project. So this project is completely opt in. We're not forcing anyone to take part and it's not actually right for everybody. So you need to keep that in mind. Here is a few of the projects that already adopted their Selenix policies and are working with us to improve them. We are aware that it might be hard to start maintaining an Selenix policy as something that you might not be familiar with but it's not like we are shutting the door and leaving you on your own. A Selenix team will still be in consulting role and we will review NPRs, pull requests you might have help you troubleshoot and just we're willing to help so shoot us an email if you need anything. Okay if you decide that this project is interesting what do you do to take part? First have a look at the packaging guide. As I said it's step by step guide and should give you everything you need to package your custom policy. I'll try to sum up the steps now. One of the really important steps at the beginning is to let us know that you're interested and what exactly you want to do with the policy. This way we can start a conversation and determine if this project is actually right for you. Second you need to prepare policy sources. So it's usually possible to adopt a module from a Selenix policy targeted package but if not if there's no module for you for your product then you might need to create a new policy. We have some tools that can help you start with the policy writing. For example Selenix policy generate will generate basic policy given a binary and some more details about the project. And as I said you can direct any questions or reviews at a Selenix team. After that's done you can verify the compatibility of your policy with any target platform. So I'm mostly talking about older Fedora versions or maybe real releases that might have slightly different base policy than the latest Fedora. After that done you just choose appropriate repository for the policy sources and then you can package them. The packaging guide should help you here. It contains even example make files, spec files and all the steps you would need to package the policy properly. The policy can be shipped in a sub-package of your component or it can be completely standalone and then linked to your package by conditionally requires. The conditional requires is here in order not to pollute for example containers and other minimal systems that do not have a Selenix enabled. After that you just create a PR in Fedora dist kit and ask us for review. Okay let's say that this project is actually not for you and but you're still maybe maintaining some project that deals with Selenix or maybe you deal with Selenix in another way. Here are two really important things for us that you can do even without this project. Please run your tests with Selenix in permissive mode and collect any ABC messages. This way we get enough time to fix any issues and your project will end up working properly. Also when you're reporting a box please give us some context. So for example if you're reporting a policy bug that's causing some of the functionality of your project not to work you can give us details about what changed recently in the software. Maybe you started using different library or you need some more access for another reasons but these information are really valuable for us and will significantly speed up the the fixing of the issue. If you're maybe just trying to use some software and you encounter a policy issue try to give us more details about your configuration and what you were trying to do when the issue occurred. Obviously a big thanks to everyone who's already doing these things because it's really helping guys. Okay that's it from me and if you have any questions shoot.