 Yeah. Hello everybody and sorry for the delay. The DHCP is crazy today. Okay. So I'm Amitosh. I'm a student at, a student of computer science engineering at College of Engineering and Technology, Bhubaneshwar, India. And I'm going to reflect something about what's the state of a Selenax in Fedora. I try to touch both the things that are happening in our workstation server as well as the container stuff and the new changes that are supposed to be done when the new modularity stuff is going to land. So we'll start. So before that let's just have a little bit of a view about what exactly is our Selenax. So I hope most of you are familiar with this stuff. Like it's been from, it's been for ages. Like when Selenax was actually introduced I was a small total. So it's been from there. So in short it's a like mandatory access control layer that sits above our dictionary user group-based traditional layer so that we can restrict it to even a further level than we could do with just simply restricting the ownership or the users like ACL attributes and we could effectively tell that this particular kind of process is going to read this particular kinds of files or just exclude to access this particular device or something like that. So this thing is very very powerful and also sometimes dangerous because with great powers comes great responsibility. So sorry. So this is a bit confusing for me. So yeah so a Selenax basically works with something called as a security context. So there's a context where you have the a Selenax identity, then a role, then a type and a level. So these four parts of the context work differently in different ways. Now the user and identity is more or less like similar to our traditional Unix users and a role is something that we can employ when we are doing some role-based access controls using a Selenax and using the type. This type is more frequently used in Fedora and most of it should be aware of this like we specify that this particular kind of process is not read this particular kind of files. And for levels, levels is mostly used when we are doing a multi-level security stuff. It's a bit advanced. I will not be covering MLS today. So this is it. So most of the time when we start discussing about a Selenax, some of them say that the best thing to do is go ahead and just disable it. I strongly disagree with this because if you are doing that we are just kicking out the half of the security of the system. So instead of actually not just go ahead and disable it, try to fix it first. What's wrong? Like are you doing something which you shouldn't be doing? So for that we also have tools that will help us. Like we have audit allow, we have AC troublesuit or if it is something that's from your system repository please go ahead, file a bug and our developers will look at it. Now here is what has happened in Fedora since AC Linux started with Fedora Core 2. So it was disabled by default because as per the release notes, some problems with the core user experience breaking. And then in Fedora Core 3 there were like the implementation of targeted policies by starting with unconfined dash t and it was enabled on a very small subset of applications like SSHD. And then FC4 expanded it to 80 policies and including Apache, Nginx and all stuff. Then in FC5 there was a debut about multi-category security and multi-level security. That time it was a bit complex but in today the scenario has improved and MCS and MLS as we will see will be implementing in our containerization systems so that to segregate different containers. So that thing was probably not used much back then but now it is being used. Then FC7 brought us the AC troublesuit utility. So something is wrong, we get that GUI application and the list of things that is going on. And also we had other tools at that time and then FC10 brought a subset of the AC Linux policies that were invented in Fedora. It's known as SC policy minimum. It just had the rules and a single target called unconfined dash t. And the upper subset that we come that is installed by default has all other 80 and 100 policies. So basically this was meant to be a starting point on which we could build our own policies for our custom applications. And now somewhere around 15 and 16 SC Linux policies were decoupled from a large gigantic RPM into smaller packages that were moving closer to code because having the policies closer to code is better for us to debug what's wrong with this policy. It's better for the QA, it's better for the release engineering. So and also we could also gather help from the upstream. So that was done and now SC Linux thing is having in Fedora is how is modularity going to implement the implementation of SC Linux in our ecosystem. So right now the state of SC Linux is we have almost covered all the core stuff like SSHD, like application servers that come with Fedora by out of the box as well as services of system D. They are all covered with SC Linux. Then many of the applications that are available on the repositories have some policies confining, have some policies guarding it against misuse like our database servers, our web servers, they all have dedicated policies in SC Linux packages. And then what we should be doing is like making the SC Linux cover almost we should be able to cover our flat packs, we should be able to cover containers, we should be able to cover user label and user facing applications that we're having. Let's take Firefox for example, we should be able to cover that also. And it should also be easier for a normal software developer like who one of us are writing code and going and publishing it on our own servers so that we could also easily secure it using SC Linux instead of writing a lot of complex tools. That is what I think should be the future of SC Linux in Fedora. Now in containers we already have a system of safeguarding dockers using SC Linux. Now docker by default has a SC Linux policy. This was inspired by Livert SC Linux policy and in this every docker containers gets access to all files that are under slash user and slash etc. As well as any file that are leveled as docker dash t or sandbox file dash t are also accessible. Now if I want to do some separation between my containers like one container or another container should not be able to interact in any other way, I need to implement MCS multi category system. Now this is currently opt-in in the package that's available in Fedora and the package that is available in rel and centOS as well and this is used by the CoreOS team and the RKT runtime they use and they separate the containers together. So this is something that I think we should also work on like we should bring MCS by default and make it opt out rather than having it opt in and then other containers like as I just said CoreOS and RKT they employ a similar security model using MCS and flatbacks they don't currently use SC Linux but it would be good if they used so that we could provide more security against applications breaking out of the sandbox that we create. So that would be something it may or may not be possible in all cases like user-facing applications that need to access files from the home directory but we should look at it like if some application doesn't really need anything to do with the home or any files we could just confine it on a SC Linux domain keep it totally separate. So that's something that we can look at then then comes this modularity that's the new thing that's coming up. Now modularity makes promises of having multiple applications in the repo available now it has its own problems and own stuff that we need to handle. Now traditionally all our packages where all our SC Linux policies were under a single policy we just in DNF install SC Linux policy we get all the policies. Now what if we use a software that's having a radically different SC Linux policy in the next person how are you supposed to manage it? Now from that we have been in this going in this direction and pulling all the policies together as the code like the code as well as the policies as staying at the same place but this hasn't been completely going to eradicate the problem with modularity. Now if there is this possibility of running two software together or running two software at two different times and we do not wish to have access of something that runs on version one as well as version two that's a challenge how do we include some kind of namespacing in SC Linux policies. Now SC Linux is global by default now if I have nginx-t like if it is common for all versions now one thing that we could probably do is have something like nginx-1.8-t and nginx-1.2 nginx-2-t but then this will also lead to duplication of effort and sometimes it can be overwhelming for the administrators to actually manage this. So probably we'll have something like a meta tool that just reads from the rpm spec generates a policy at the runtime then applies it when our rpm is installed that could be one of the solution to this or else we could even write something that completely generates a policy at the runtime like we could have a separate meta language that generates a policy and it could have something like nginx common or nginx-1.2 something like an inheritance based model in which we will be just layering the changes over it so that's one solution that we can have it here then I also have some general suggestions to the developers and the SC Linux team there are there are other efforts in other communities like Gen2 Harden that is one thing that I need to notify they have a lot of proof of concept regarding confining user space applications like one that why was researching was about confining Firefox like it had these challenges it had these issues but it is a great step forward if we move that way like we can we can some way say that users like the Firefox browser is not going to read my SSH private keys so I'm going to exclude it but if a user is actually wanting then we could just bring them and add it to and then we also need some more tools to help application developers confine them so that we could reap the benefits of SC Linux when we are deploying our own custom in-house applications the current workflow for generating SC Linux is complicated need to write three sort of files then compile it so that's not something that everyone of us is willing to do every day so that's one more suggestion from me and there have been this concern in users like everyone just comes me and tells me just disable it so why do we do that like they say that this is complicated which to some part I agree they say that this is this is buggy but which is not so we also need to do some kind of marketing so that SC Linux is actually the benefits is actually gonna reach the people who are developing software ah yeah we know so we need to fix that also that's it like if we if the developers will complain that the policy is buggy like they just instead of telling that the policy is buggy they could just go ahead file a ticket yeah that is also that's also yeah some policies are buggy but that was like 10 years back like policies have changed like I have been using Fedora since Fedora 15 now I have seen policies that are buggy that were totally restricting applications to start but now there is no such issue in that policies are been fixed so that's was like if you are talking about policy drifting when our like distro maintenance writer policy and upstream isn't aware of it so that's what I'm suggesting is bring the policy closer to the court like try to contribute the policy changes back to the upstream so that upstream also knows something has been written in some distro that can cause problems with you yeah something whoa it's way louder even when I'm talking normally something that I've often seen is that a lot of the either sce links or you know this guy's armor policies you know the the problem is the policies get written over and over and over again by different people and at no point does anybody realize that you know maybe it should go to the main project like even right now with the sce links policy in fedora being decomposed into into the mod into the packages for the software nobody has actually considered just putting it in with the package that actually has the software they're being separate packages and still being versioned independently that keeps it makes it very difficult to do that kind of you know work you're suggesting yeah so that is also a major concern among this sce linux community like we are not contributing our changes back to the upstream that is something we should really start so upstream should know that there is some policy somewhere yeah and also this could also foster the collaboration between different distros like fedora we consider that it's a gold standard for sce linux and but if different distros are going to actually implement sce linux in them so they should also know what policies we are doing so if we contribute it to back it's something that we're giving back to a broader community even more people can go ahead and find bugs with the policy harden the policy like the more the people the more effort that we get and the more better result that we'll be going to get at the end of the day so these are the three and plus one four main suggestions that we came out so like yeah oh i'm sorry so i have one more question i don't know what's the status of this right now about a couple of years ago there was a problem with the policy being monolithic and it basically can only be updated monolithically so there was an attempt to basically be able to split it up but it basically required updating the packages that would contain the sub policies at once and then rebuild the policy one time only but that didn't work out and we threw that feature out of our p.m. again so i'm wondering what's the status there is is as a linux fixed so it can actually update the policy in reasonably time step by step or do you still have to put everything in one big package and update it monolithically can you comment on that please so some of the packages have decoupled their policies from our main policy rpm and put it like like like we have this docker s c linux like there are other packages like mysql s c linux maria debi s c linux there are packages like that so this has been done for some of the packages but like mostly many many of the rules are still in a monolithic role like that still has not been completed now with the modularity i think it must be done so there is there is no other way around it like we have to go and decouple the couples the models that you're having s linux so uh any other questions i i have a question about gen 2 hard and do do you know if gen 2 was able to confine fire firefox after all the question is whether gen 2 was about to harden firefox after all so yeah confine okay so uh they did a poc on that so that uh they were able to confine the sys calls that firefox was going to make and the folders that the firefox was able to read now this is something that will work but the user needs to be told about that hey we are not allowing the firefox to go and read a directory from your home or your you're not allowing firefox to just write it at relocations like we have extensions and plugins like the experiment when they did firefox was allowing our xp com plugins and which had basically unrestricted access to everything so in that time it broke a lot of such plugins right now firefox itself is having some kind of confinement so if we attempt to do that confinement right now we will be able to amount of success than what they did so they were able to restrict uh file uploads file downloads uh invoke invocation of arbitrary commands from the plugins that are installed and also they were able to restrict what dlls or what libraries were loaded by the plugins and also by the different extensions of firefox they were able to do this and after that experiment we also have many changes actually nux policies in fedora like we are uh having some confinement rules along the policies like many of the policies like some one most notable one that i will say is confining the flash plugins so that it didn't do much damage so that is something that has been done in fedora also i i i have three comments on that so steve grub wrote a blog on confining firefox writing a couple of years back and he basically concluded that you know it's it's really difficult to confine firefox because modern day browsers are like they are mini operating systems they have media plugins and they have they they have they have so many things like if you look at firefox code or if you look at chrome chrome chromium code it's it's really it really embeds so so many things that's one that's that that that is something which which which makes it very difficult to confine firefox uh the second problem over here is slinux is more about uh you know by default everything is closed so if you have a if you write an slinux policy around a daemon then by default everything is restricted so you need to write a policy which will open up the restriction for each of the individual things like processes or files or whatever that's that that makes it very difficult to confine firefox i i think there is still some work going on over here but it's uh user space applications like firefox and library office and stuff like that it's going to it's going to be really difficult it's certainly going to be difficult but if it is difficult but it's still not impossible right so we need to improve both slinux as well as firefox to reach there uh it went to sleep you should probably like poke it uh so to the point about firefox not being able to be confined actually it's easier now than it was before because plugins are gone uh as of the latest couple of firefox releases at least in the fedora case like if you're in old stable land this is you're still sliding it's kindly screwed but if you're using the latest firefox releases you don't really have plugins anymore they don't work and xpu xp com extensions are gone um and the sandbox is actually fairly simple it's a simple seccom filter and so you can overlay ac links pretty easily on top of it if you really wanted to um the main issue is of course that we can't keep up with firefox's cadence so if we really wanted to do it we need to actually send the mozilla policy we wrote a decade ago to firefox upstream and have it maintained as part of that and actually assist them in plugging in with ci and you know from my own experience with snap d i wrote the ac links policy for snap d very painfully bit by bit over like a year and uh that is actually integrated into the snapcraft ci and every time everything breaks he has to fix it or i have to fix it but yeah but it's upstream and part of the project and it's actually a gate and that's the important factor now that people consider ci and cd part of the story it actually makes it much easier to plug in things like ac linux into that into that model and the thing is the way i've seen the ac linux team currently approaching the ac linux decomposition they're not thinking about it that way and that actually worries me because even the debian guys with app armor are actually not thinking about it that way either and that scares me because nobody is thinking about it that way and that makes the drift all the more painful are there any ac linux developers out here like those are totally associated with fedora core ac linux yeah that's an issue yeah yeah they're neither at flock also so we need to somehow convey this message to them that's is important yeah just maybe as an observation from the cross the pond so with app armor we've been having the same story we start with just like let's write some policy for some important software service firefox a bunch of other stuff and we got some progress and then we wanted to have more and more apps and we essentially had the same approach a single monolithic package shipping all the policies that just didn't work much because it kept drifting um we started raking it up but most projects don't really take the packages like if we actually go and submit the patches they don't understand this they it's not like they don't want to but for them it's well i'm not running on something that actually can use this lsm so i cannot really test this i don't really understand how this works so i'm not willing to take the patch so the problem is not only just upstreaming but actually teaching upstreams about how the lsm actually works how do you actually develop with it and it's not easy why okay so this we didn't i hope it's not so we didn't have big success here on the other hand one thing that did work very well click packages the precursor for snaps were also confined with up armor and the policy was written by a security expert who looked at every specific package and didn't scale obviously we stopped doing that and instead in snaps we don't have that there's one policy for every application and then we have snippets that you know do well to find things so an app developer who wants to write a rss reader doesn't need to understand you know all of lsm's they just need to say i would like to have access to the network and the display system so i have a desktop application and that's much easier language and we found a much better traction because then they actually say okay i'm willing to take this that i want to have network and i want to talk to the display system but i'm not willing to take the whole big complex thing that it really compiles into so just maybe having an intermediate language which is much easier to work with you know could be a like a starting point for upstreaming so to kind of riff off of zygmunt's point here one of the things that actually like i'm not an sce linux team person or whatever but like i watch all that stuff very closely one of the things that actually happened two years ago was that sce linux gained the ability for you to write another language to describe how policy works and so one of the things that could happen is that somebody like the major policies the lsm's both app armor and sce linux could actually decide what a common high level description of what that stuff should be so that upstreams could actually maintain descriptions of what those do and translate into the similar mechanism that you know snaps do with the well-defined snippets and whatnot because the the concepts of what they what they restrict or allow is relatively easy to map conceptually the difficulty is actually making it so that they actually are implemented regarding this point i can think of an example like we also have sce linux in android now the sce linux policies for a particular app is like the restriction of the application in android is both like the jdk security manager as well as whatever rules we supply in the manifest is translated in some form into sce linux rules so that is one example that i can think of regarding to this like if we could have an xml or a some other dsl and now right make the definitely i'm not in for a xml i'm not in for a xml yeah so uh if we have something like that says he just give me access to this this this this this network and that like a very simple subset of what app armor can do what sce linux can do and write a tool that's gonna generate a second point out there like that's gonna generate a sce linux policy or maybe at some point we could also ask is to generate an app armor policy put it there so that the upstreams is we happy we'll be happy everyone will be happy yeah yeah um i think when we put the policy generation into the package environment we may run into the issue that either a package maintainer is like hmm okay i'm usually i would maybe just have this package in place i will just say oh come on give me everything and it's fine because it makes my app work so um what i like about the monolithic approach is that we have another team or another set of people who watch what the application does and says oh this is fine this is not fine and this makes it of course also more secure because you have just have a second point of view for that applications that are um watched by sce linux and and confined so even when our malicious um a package or a malicious package is provided it still isn't able to or the application which contains these malicious uh parts is is still not able to read various parts etc of course for the desktop it's currently well not really existent because we just run everything unconfined but the basic point is that um especially when it comes to security features you want to have a second pair of eyes that is looking at all the policies and just double checks it i absolutely agree with you so uh when we're talking about decoupling the policies from a monolithic package we are not discarding the entire sce linux team like they will be still be there and they will be still reviewing all the individual uh dash sce linux packages so they will still continue to have a look on what the application developer is sending them so we will not change the way we are packaging in fedora like we will still package the sce linux policies separately and it should be getting reviewed by the sce linux team so that how it should continue that's my opinion any other questions comments yeah um the well the idea of a monolithic policy is interesting and one of the reasons why basically every lsm under the sun has done it that way in the beginning the problem is one human does not scale like just period they don't uh and every and the thing is the sce linux team at one point has been as large as like seven people but they all run away and go join different other circuses like dan walsh is now in the container circus you know one of the other ones just quite frankly just left linux forever because you know apparently security is very hard and the other thing is that generally speaking the concepts that are actually that are described by both app armor and sce linux are too raw for anyone to really understand the the consequences yeah the consequences of them they're very raw and to the point that most people are like we're just gonna say screw this and this is actually the reason why we have a a minimal policy and b the targeted policy because we actually started out with c the one that covers everything and breaks everything and we went backwards because it turned out to be a horrible idea today if you actually launch new services on rel seven for example they are unconfined otherwise in fedora we flip the switch now everything breaks if it doesn't have a policy that's a big change and that that actually is a problem like change because there's actually no good easy or useful remedy for that problem because the amount of expertise out there and the documentation for how to actually do these things is so bad like i'm not it's not just sce linux it's all the s lsms it is so bad that it is really really hard to figure out what you're supposed to do and so this is one of the reasons one of the reasons that i'm even involved in snaps at all is because i actually like the way that they do the descriptions for for security and it's a concept i think actually doesn't necessarily need to be in snaps alone it could be something that you could pull into the general world of like how security is managed in linux but the fact that it hasn't happened in almost what 20 years is shocking like it's almost 20 2000 was when sce linux was introduced to the world the first lsm and in 20 years almost 20 years it's 18 years now nobody has ever thought about doing that it took google doing it with android for somebody to think that it was a good idea can i add one thing to that so just just recalled one thing that's i think useful so the high level language that we have in snaps for describing like the shape of the sandbox for applications is not really strictly about up armor up armor is one of like five or six things that actually gets you know done so when you say i want to access network it has implications on system calls through a second filter it has implications on the up armor itself which confines networking but if you look at some other interfaces which is the extensions of the sandbox they do device c groups they do all kinds of things and this is so nice because we found them to be very complementary like some things work very well in one place like we can do this with a device c group other things work very well with s with sce linux sorry with up armor and the other things work very well with second filtering and just one of these alone is not sufficient usually to do what we want as a concept like i want to do this as an application so um i don't think we like anyone ever realized this before and said it out this is a very useful property we can we can plug additional things that help help to convey the you know the semantics of the confinement like access to the network what does it really mean right what doesn't really mean like what kind of limitation was going to put in place maybe there's going to be a network namespace around the process but just the things that are one concept can map the multiple technologies that's very valuable sorry although i mean one of my primary frustrations with snap is that uh that all not all of those plugins are fully formed and the the result is that you get the same kind of um yeah you get the same thing with a you get the same problem as you have with sce linux is that you just turn it off by writing classic snap right and and uh and so so even even still even with the with a more abstracted model right i'm still running into some similar problems with the with the applications or loopholes or issues that are there so zygmint i'm going to just say this on the record with speakers of recording to say this is why i suggested two years ago you should just make snap confine a separate thing instead of just folding it because it could have been generally useful across the board for this kind of stuff and now you can say so i agree what you say like every technology that's just like not super mature and super polished it's going to have rough edges so people use things like classic confine which means really unconfined things as a as a workaround they can also use non-enforcing confinement which is a lot more convenient for them in practice because it means things run um and they see why it used to not run like there's a message saying i'm allowing this but you know otherwise i wouldn't so there's some kind of feedback we can get but the primary point i want to like um for cross initially the the surface of things that are broken is far smaller there's like a hundred or so interfaces and there's thousands of snaps so fixing one interface fixes it for every application out there without these guys knowing without these guys having to care without i mean it's just a central point for the semantics that has to be fixed that's much easier to work with we also have something like a silly nicks in permissive mode that exactly does this of course while debugging the policies that's that's a friend so any other comments questions questions comments so anyone okay then uh yeah so i so this is all from me right now so thank you