 Welcome back. I think it's our last session of the day, right? So we've got an LSM maintainers panel on the far I guess would be to your left to my right. We've got Mikhail maintainer of Landlock we've got Mimi maintainer of Ima EVM the integrity LSM. I don't know What's it actually called integrity subsystem? There we go the integrity subsystem We've got John who maintains app armor, and we've got Casey who maintains smack So and I'm Paul. I'm gonna be moderating I maintain Essie Linux and kind of the LSM layer as a whole So anyway, we're kind of planning. We've got a couple questions kind of to start off And then we're gonna open up to you guys. Hopefully you guys will have some questions If not, I've got a whole stack of cards here So we should be able to fill 45 minutes if you're feeling shy today. So anyway We're gonna start off and I guess Mikhail I'll start off with you and we'll kind of work our way down Then we can snake back. So first question What do you view is the biggest challenge facing LSM's today? And this could either be your specific LSM or just LSM's in general and I guess it's a bonus follow-on question What planes if any do you have to address that? So I think the biggest well my point of view the biggest challenges for LSM to be accessible to be usable and Well to do something useful So usability I would get I would say That's very think probably that applies for most of us What do you have any plans to to address that? Well, I mean my best with Slunlock And Then that well, I think Well, what can use a space tools tooling and the condition is what we should do. So Yeah, nothing magic, but yeah All right. Thank you Mimi you want to repeat the question. Sorry. Okay So what do you view is the biggest challenge facing LSM's and this could be you know feel-free to answer specific to integrity subsystem or just LSM's in general and As a bonus if you've got a good answer for this, you know, do you have any specific plans to address that? okay, so we're gonna stay on the integrity subsystem and So the biggest challenge is making sure that no new integrity Gaps are introduced and How we do that I Think that'll leave that for later That's fair. That's fair Okay, thank you. John do what I can repeat Actually, my answer kind of follows on Mimi's there because I think one of our biggest challenges is we keep having new capabilities introduced in the kernel that we don't have mediation for and we keep having kernel devs avoid the LSM and I really don't know how to get them to You know check with us and get hooks and or at least work with us work with us. Yeah Yeah, no, I I understand I think we've kind of all felt that pain at some point And I guess to be clear when you say capabilities you're talking about just functionality in general functionalities not posix capabilities Well, I'm that yeah, that's a whole issue in them itself the you know them throwing Everything at Cap Mac admin or Yeah, okay Do you have any plans on or do you have any thoughts rather and how to improve that? I Do have some thoughts on how to maybe improve it, but getting people to go along with it would be difficult So I I would like to see you know actually capabilities broken out in the kernel and it become LSM calls instead and then re put back together So we have more context when it's coming in as to everything being Cap Mac admin and then if Nobody had access to directly to capability or P trace like that and they would be forced to say security something and then Potentially we might get a little bit more interaction It's a good point Yeah, especially when you consider most of the places in the kernel that We would want an LSM hook you generally have a capability call of some sort in that section of code So yeah, that could be a good idea Thank you Casey. I know you've got some ideas. Yeah Yeah, I can repeat the question. No, that's quite all right I think the biggest single issue that we've got with the LSM is That our security paradigms are 30 years old We're starting to see things like landlock come in where it's a different mindset a different way of looking at things as opposed to what we mostly got now which is Based on the main frame sitting in the corner being shared by people who don't trust each other By encouraging more new things to come in New paradigms new ideas new ways to look at security that are more appropriate for the systems. We have today Then the systems we had 30 years ago, I think that we can actually greatly improve the systems and the Usability and the usefulness and and avoid a lot of the things that we see as modern problems Got any plans to fix that? Well, I'm glad you asked I think one of the biggest One of the obstacles we've got is it's very difficult to Implement a new idea LSM if you're looking out at the current distros and you're saying this would be great But I can't get it into there's no way I can get this into the distros so if we can get Module stacking to the point where you can use Use useful things in addition to s e-linux not to say s e-linux isn't the useful thing necessarily but That will actually should help grease the skids as it were and make it easier for people to do things Think that's fair All right, why don't we do one more question, then we'll we'll open it up So I guess we'll we'll snake so this is I'll start with you again case right so you don't get any time off on this okay Shifting gears a little bit so Not necessarily talking about problems, although it could be a problem, but it's nice if we've got positive up here But so what do you view is the most important change? That's currently under development once get this game to be something that you're working on or something at least that you're that you're aware of Well, I can't help but say that the LSM stacking is the most important thing That's fair. I was expecting that It doesn't shouldn't come as a surprise and the first iteration of stacking that we got in That enabled Yama to be something other than a wart and there were a couple of other other lesser elements that were coming along there We're gonna be warts to Warts are bad. Generally, generality is usually a good thing Sometimes you have to have to pay a price for it and we are we're paying a bit of a price for this But I Think that that actually it opens up things in a way that they're they're really not now They're it's too too much Overhead to get in as an LSM these days and if we can make that easier that'd be really a positive thing I think that's right. I think that's probably what we all expected you to reply with so well that he didn't Really? All right. Anyway So all right, so John hopefully hopefully a different answer surprise us surprise you So I do think Casey's right that LSM stacking is the next immediate thing the thing we need to follow on with that Yeah, after that though is is somehow to come up with some name spacing Around the LSM and it's a question that we very much haven't solved yet and it it Stacking in itself is not sufficient for several of the use cases And so that is the next thing we have to be working on and figure out around the LSM's and whether you know whether some there's something we can do that's Unifying to them or you know just enough that each one can do its thing. I don't know Yeah, I think it's fair and I think I know at least in informal discussions whenever this comes up I think it's still very much an open question for just all of us. It's the best way to handle that Well, I don't even think most of LSM's know how they want to handle it themselves. Yeah. Yeah, there's some There's some big challenges there for a lot of yeah right So I'm actually the biggest gap right now. We had a talk on it by Nika and that is the interpreters and Way that files can be read and executed by the interpreters if we can close that in Integrity gap that would be amazing. So I'm waiting and looking forward to having that and Any help I can offer Yeah, so Well First thing is without SM stacking at least the first step, which is upstream yet our luck will not be There are at least not useful. So I think SM stacking is very very important but yeah as It was already said Stacking is what one thing and being able to compose different LSM policies or different security policies but in this case different SM policy Would be quite a challenge. So That would be interesting Definitely, but very difficult to So we still got plenty of time left so why don't we open it up if you guys aren't asleep yet? Any questions that you guys might have for anybody up here or for everyone feel free What do you feel are some of the most significant emerging threats to Linux systems these days? Always a fun question, right? Does anybody want to jump in otherwise I can start picking at people I Would say at this point. It's the divergence between phones and embedded systems They have fundamentally different security threat models and we're using the exact same software in both cases That's going to lead to a case where things will drift in one direction for a while at the expense of another of the other Other side and then these people are gonna say oh, we've got to fix those problems And it'll start drifting back and then they'll cause sister problems over here. So Coming in some way and Whatever this is to identify The threat models more clearly So that they can be differentiated so you can say I'm fixing this for this threat model And I'm not fixing it for this one because this one doesn't really care about it and so people could have an understanding of Why is this security feature going in is completely worthless? You know, who could possibly be using it? Well the light bulb people want it Well light bulb people have different Requirements and so so long as you understand that there's a reason for it. Even if it's not your reason We can get I think a more synergistic Flow of understanding and tolerance of other people's development I think that's interesting sometimes because in cases where the different requirements can be made compatible I think that works, but I think we've all seen cases where sometimes requirements are at odds I think that's where the real fun begins But you know we have ways to dealing with that and you just have to pick sometimes which It's not great, but it does work Same body else wanna sure One of the big threats we're seeing is everything is Everybody wants things to be secure, but they're pulling their source code from everywhere It's like we're just pulling straight from GitHub, you know We have our script. We're running our script and it goes and grabs a script and brings it down and starts running it and Trying to secure that source chain and what's coming in and verify what's there I mean the supply chain attack is the really big problem right now for from our point of view as a company that we work at Trying to figure out how to deal with that and what people's workloads are with everything being so dynamic It's it's ugly We even I mean even extending beyond that to problems that you think we should have solved and we've been talking about this week Yeah, I mean BPF right there's still no sign integrity checking of BPF programs So you're loading code into the kernel then right no No assurance of that hasn't been tampered with or where it came from so yeah, this is still a big problem Right Thank you for answering the integrity aspect of this. Yeah, okay I didn't want to steal your thunder. I mean, do you have anything you want to add to that? No, that's fine. Okay. Okay. Yeah, okay Yeah, all right Yeah, I think the well one thing to to keep in mind and to Repeat and repeat and repeat is that there's no one Linux. There's a lot of different Linux different Canal first and different use cases and different systems. So a lot of different set models and Lot of different priorities It's difficult to To answer well, what is the most impotence? Well, what is the most important kind of attack? Well, it depends of Your system you're predicting what you do with that But I think what is becoming more and more important was the last decade maybe Is that the Well attackers well, it's becoming more and more. Well, it is like really real job and the attacker skills are more and more Well professional and So yeah, this thread is kind of higher than it was maybe 20 years ago I think it's basically for well attacking critical stuff like the colon So we need to protect user space with an SM on any acceptable system But we also need to care a lot about the canal and to find new ways to protect it Well to help it protect itself or to rely on something else Hopefully we answered your question a little bit. All right. Thank you. Do anybody else have a question? I Wanted to push a little bit on ebpf, which you just mentioned in that last question Besides Signing ebpf ebpf so that we have something much like sign modules. Do you see any other place? Where lsm has a role to play with respect to ebpf? I think historically speaking, you know modules have been considered out of scope for LSM because we're just sort of extending the kernel And you know LSM is really more about you know trying to control what user processes do But ebpf is sort of in this weird middle space it both extends the kernel and is very often arbitrary things that are inserted into the kernel by not necessarily trusted user space programs and That's a little terrifying It is and there's I think there's some Philosophical differences around access control between most of the people in this room and a lot of the ebpf developers which further complicates things sometimes But anyway, let me open it up to you guys Somebody surely got to have thoughts on this ebpf is terrifying So From a distro point of view One of the things we've had to deal with is all the CVE is coming in from ebpf and all the attacks It has been used every year in Pondone when we've been a participant Then they just keep adding new things and they keep saying the verifier is you know It's security by a verifier and yet so for example hot BPF not to pick on it, but Yeah, the verifier can do so much But as soon as you open it up to being able to write to the kernel the verifier That's not really doing anything for you as security wise now. You can do anything with it, right? As every time they open up a new capability for ebpf we see new problems and There's no real control of that and I would I mean there there's a little bit of control in ebpf on What subsystems are available, but I would like to see Much better control over that Where we can do something more than just say well, we're just gonna block ebpf and Some granularity there I would love love to see better controls on that Yeah, and I think that's a good point about not wanting to block things. I mean a lot of times I feel like people Especially other subsystems in terms of like why you just wanted to say what we really don't want to disable stuff, right? I mean we don't we We're developers we're users too, right? I mean we want to be able to make use of all these things But we wanted to be safe and we want to make sure that we have all the necessary Stop gaps and controls in there. So yeah, I think that's a good point which is sometimes lost, but And and the first one is of course from an integrity perspective That we only want those things that are signed by known keys That we control and how they get in is really important and not Randomly so It's still the same issue an integrity gap, but that doesn't answer your question. I mean disabling ebpf we Can all sort of pretend like is it abling ebpf is still an option But realistically it's not like that shipper say it right if you look at a modern distribution today Fedora Whatever then you will be Faced with lots of ebpf programs and usually and not necessarily it's it's not wrong like useful Abilities David is looking at me like I just committed heresy I Mean the only way to realistically Address this is if there is some sort of regular exchange like how involved are the LSM and to security modules in In ebpf and like I agree. I mean there's a lot of I wouldn't call it terrifying, but there's a lot of creative and Potentially security sensitive changes coming and they keep innovating which is they're right To do so, but so we in the end need to deal with this like we can't just tell them Go away. I mean you can try but you will fail well, so the one of the things that I I think is very important about the the ebpf is that I Believe now I couldn't be wrong here but my understanding is when it was accepted in there was kind of this notion that you guys are gonna be careful with this and And Well and first off the the people who develop a program right okay. Well the people who develop the programs aside There are things about the way it was implemented that Were eyebrow weight raising to begin with for example that the there's a hook for every LSM hook available Which isn't the model of the LSM infrastructure and And that has led to it to more than one significant problem and If somebody really wanted to do bad things on an s c Linux system all they would have to do is implement an ebpf hook for Security context to sec ID Which could cause all kind yeah, it could cause all sorts of bad things to happen and so There wasn't a lot of you know it was put in it was like oh here's here's the convenient way to do it. Okay now. We're done. Well you'd need to be more careful than that and I think that that's something we've seen in a couple of other subsystems as well recently I owe you ring For example, yeah, where it's just they weren't careful and it being more careful with the Going into the infrastructure that's there already is is something that We could do better on in Linux in general and think that in in the vicinity in the vicinity of security in particular And I think at the risk of Generalizing your question a little bit too much. So apologies if I do that but It's all your points like I said, we're we're not trying to disable stuff like I said, I mean I want to use the cool new features too, right but I think the the issue isn't necessarily specific to eBPF there's this greater issue at large when we mentioned I owe you ring and At LSS last year that I gave a talk on this and some of the challenges we had there and you know next year It's probably going to be something else and there'll be something else the year after that There's what thousands of kernel developers and I don't even know how many different subsystems there are and unfortunately There's not nearly enough LSM developers. I'm not just talking about us just developers and people interested in kernel development or on access controls Where we can go out and keep track of every single development effort that's going on, you know, there's there's We try I've been trying to automate somewhat, you know Watching Linus's tree to detect when things come in with certain things that generally tend to be of interest from access control perspective It's you know, we got to read stuff like LW on a lot, you know, I live reading the LW on things Just try and catch things but even then sometimes it's we're talking about this one of the problems we had with IOU ring is There's the credential sharing issue, which I think we probably don't know about this point But when they reduced it they called it personalities Which is challenging because some of you may not know this there's already a personality concept in the kernel And so if I remember reading the LW on article and I saw personalities and I thought it's kind of odd Why would I you didn't care about personalities and so I just kind of ignored it But then we look at the code and realize no personalities. It's actually credentials So there's all sorts of challenges and I don't think there's a right answer other than we need to find a way to work together, right and We can try like I said we can go out, but I think we also need to Somehow get the other subsystems to be willing to work with us a little bit more You know and when they're when they're developing significant new features just Send out a post to the LSM list even if you don't want to post the full patch set just say hey We're working on this. Here's a pointer to the mailing list archive. Can you can you take a look? Tell us what you think tell us there Is there anything we should potentially be concerned about and I think I don't think anyone up here would object to that No, yeah So I just want to add one more thing to that and I was wondering if we have Documentation on all the steps that have to go through when you apply send-in patches Why can't adding a step that says make sure that if there's any Sort of security or integrity issue that there's a call there that there's a security hook Whether or not and then we will at least have a heads up that something is going on and that would be more of Maybe for the documentation people Well, I think also just kind of socializing that with other Colonel developers and and maybe the maintainers of the larger subsystems and I know one of the suggestions that Case made when we were We were talking about you ring last year and I apologize I haven't had the time to follow up on this yet, but you can put I think you said you put some Regular expressions in the maintainers file so that when people use You know get maintainers, you know if we can flag certain certain keywords certain functions That will get sent to the LSM list, but I also kind of wonder how many How many experienced Colonel developers actually still use get maintainers, right? I think get maintainers is one of those things that you when you first starting out you use it But I think all of us one was the last time use get maintainer Recently what about two weeks ago? Oh when I write something in another Okay, yeah Okay If you use before for sending patches, it will automatically run it Constantine would be very happy that you mentioned that he's right here today, but yeah before is great If you're watching on the video see there we go All right, I think that before we move on to anybody else want to Know all right Well, thank you. That was a good question. Did anybody else I am contractually obligated to ask Has anyone given me thought to using rust in LSM layer Yes, but I need to piss people off All kidding aside A language transition is probably the most dangerous thing you can do is Probably a better idea to rewrite from scratch than it is to try to change your system from one language to another The thought paradigms are very different when you're writing in One language from another I once did an implementation of make in Pascal It was very small and it worked. It worked just fine, but You there were things that just fall out naturally when you're writing in C That if you're writing in a different language You don't do it that way you do it a different way and so I think that The whole notion of oh, well will incrementally switch Linux from C to rust is Is going to Be very frustrating and I think it's probably not the right approach But that's I'm an old guy So I've thought about rust as well my biggest issue with rust there is is time, right? We're already Way under, you know, we need help, right? And we don't have enough time to do everything we need to do and then trying to take the time to rewrite something And rust is just is that one extra thing and you're never getting to anything else? I do have concerns that you know, how do I rewrite just a part, you know, just one part So I can do it incrementally and and not break everything You know, it's it's it's a problem I also think that a bitter approach is probably to look at Some of these ancient services and demons that we've got that haven't changed in 16 years Those might be better candidates They don't have any bugs, right? I think it's a It's quite for the colonel, but it's quite funny software rewriting from one language synthesized costly time in Well bugs that just that are already fixed and so on So yeah, definitely Developing new stuff in rest is definitely a good idea rewriting stuff much more the annoying phone is mine. Sorry But yeah, I'm nobody ever waits. I'm really grateful that we can write some kind of code in rest. It's very good And I think a shameless plug you've got a lamac library Yeah, yeah, yeah for you space. It's uh, yeah, yeah and Further shameless promotion if if other people were interested in rewriting really small LSM's that exist already in the kernel in rust. I Would be happy to review that Not that I have time to do it myself. Do you have any suggestions load pin? What's that? I think the load pin LSM would be really straightforward because yeah, I'm a little bit of checking simpler I mean, I'm just one page of code Yama's awkward because it walks the process tree and trying to do that. I don't think we've got good API's for that right now Oh load pen is Really simple That's it Well, thank you So just a follow-on question. Would it make sense to have an LSM rust API that like a native Rust API in the kernel so new LSMs could be written in rust Do you mean when you say an LSM API you're talking about the hooks layer? Yep Is that how it would work? I don't know how it would be a requirement. Yes, it would be a what a requirement We need well if you want to write a new LSM well you need to have an LSM API in rust yeah, and I think that would probably be We're intentionally trying to keep that layer as thin as possible. So the logic in the LSM layer itself is Pretty slight. I think even with stacking it still remains relatively slight. Yeah Pushing things into the individual LSM code rather than having it in the layer. There are a couple of places where that's rather inconvenient and dubious, but You you do want to have some sort of philosophy about your if you're going to have an infrastructure you want to have a philosophy behind it and I think the other thing with making a rust version of it is that we would very much have to Take a significant look at what we've got and see whether what we've got is actually The right thing to do to pull that you know to enable that whether That infrastructure is really Appropriate for that for that kind of user if we're going to do something like that. Do we want to have something else? The only thing I can add to that Wearing my LSM maintainer hat is I think I'd want to see the Rust capabilities in the kernel develop a little bit more get gained a little more maturity before we started to go down that path Yeah, putting on my distro hat right now rust is a problem For building kernels. So we have to build kernels back on older releases And we have run into already on into problems with kernels with the rust landed and it's broken kernel builds And so we very much would like to see a little bit more maturity on the rest side before we roll it out more Sorry, it's still on the rest side of things My understanding of rust as well is that currently it doesn't actually build on all the architectures that the Linux kernel builds on Which could be a bit of a problem for anything that's considered to be kind of core to the kernel like an LSM So that's why it feels like rust is a great fit for leaf driver modules type thing But not only for something as core as like rewriting one of the main LSMs, for example And so one thing to keep in mind if for any piece of software if you want to rewrite it well developers and Mainers need to understand that so and to Yeah, have this skill So that takes time to One of my personal favorite ways of breaking catch 22s of it's not mature enough yet is to make things require it and suddenly maturity evolves rapidly and Oh, no, I can't build the kernel on this architecture Suddenly we gain architectural support that we needed so I'm not sure it's a reason to avoid those kinds of things I think it creates work, but it's work that is already needed. So I think it's it's it's a way to prove where there are actual needs as opposed to theoretical deficiencies, so I I Think it would be an interesting area to explore because I think the interface is relatively simple as far as the hooking goes compared to you know DMA and graphics engine Submission and all of the crazy things that we do have interfaces for Now so I think it would be an interesting area to explore. So I'm very sympathetic to the let's just do it and see who complaints are a thing I mean, I think probably I've definitely done that in the past on a few things I'll throw it in the next branch and see well force for somebody's hand, but I think there is the other issue that we It's popped up in a few of the questions We're there's a lot of work to be done and we just don't have nearly enough people to help contribute on this You know, well, that's another interesting part about it is suddenly if you have a rustic API other people materialize To do the work or maybe less because sometimes less but yeah doesn't appear to be happening So I'm excited by that piece as well as someone goes. Oh wait. You mean I don't have to write in C Well, yes, I'm yeah, let's do some kernel work I've been burned enough times on the if you build it. They will come sort of argument that that does I Understand that's an argument. I know a lot of people believe strongly in that and rust is extremely popular these days, but I Personally, I'm gonna need a different argument for that, but it will require mentorship That's gonna be true for anything. Yeah, if it's not a rust question. You can actually ask two questions It's not a rest question. Hey, you get to that. Unfortunately. I only have one question. Oh So I'm going back to a slightly earlier topic. I'm one of those BPF developers that makes incorrect assumptions and terrifies you guys Casey you touched on this briefly earlier, but I was curious what all of you guys's thoughts are on BPF LSM the BPF LSM. Yeah I'll use his answer, which is it's terrifying it It's insufficiently well-defined as to what's going to what's going to happen if you have this LSM in place With respect to the other LSM's There was a bug a while back with one in one of the hooks where Nobody got called ahead of BPF and it said yep, I'm returned the wrong value There the other than what was expected This is probably a pretty reasonable assumption for this the BPF developers to make based on the general behavior of the LSM infrastructure, but this was one that did things a little bit differently and so when When you don't have the level of review that we provide for LSM someone somebody Proposes a new LSM in general that gets pretty thoroughly kicked around We all look at it These couple of the other people always look at it because well, we're kind of curious about what it is that they're trying to do that we didn't think of and That's not true with an eBPF program no best we can tell nobody's gonna look at it and Best we can tell the BPF infrastructure that's implemented as an LSM Isn't going to protect it that well either So it doesn't Fit fit very well into the paradigm we've got Well understand why you want it and what the advantages of it are but It would be real nice if it were more like other LSM's in the way it's implemented the way it's actually Fit into the system Yeah Yeah The other one of the other issues I have with eBPF LSM is it is allowing for Security modules that are not Basically going to be reviewed by the community. They're they're coming private companies They're they're making these modules and it's not being open sourced essentially and it's going into the kernel and doing its thing And we don't get to see what's going on. I know of a couple of cases cases of this already And that you know from a open source perspective that really bothers me Yeah, it's very flexible. You can do a lot of stuff, but yes, it's done tight So yeah, if you don't trust the people that write the code to policy Well, there's an issue so So when we talk about signing things signing the eBPF modules and things like that first of all On the maintainer basically told me I'ma is not the solution and He kind of kicked us out The other issue not that we're listening and I believe that Roberto tried to address it and his patches are still waiting there But I think that maybe We had a side discussion earlier and the talk that addressed The last talk was about requiring more information in this In the keys how can keys be used what they should be used for and I think that That going forward maybe we need more granularity and to say how eBPF Can't if they're a sign assuming we get the signatures in Then how can these be signed and which keys can be used so that we don't have this? You know enormous granular, you know, no granularity. It's either all or nothing And I think that that might be a way of constraining it and I think with that we're at time, aren't we? Okay Does it well does anybody have any questions? I mean you still have an extra question if you want it All right, James, this will be our last one. So there was discussion of names security namespaces So people are saying yeah, there are problems with that, but maybe for you know, it's what are the actual challenges and Would it help to have like a container ID in the kernel or something like that? Oh good I was afraid you're gonna ask a really complicated question To tackle this one first. Yeah No, I'm waiting for your answer Container ID is really nice. Yeah, I'm the moderator. I asked the questions. I don't have to answer them. So Yes, I a lot of people have been asking for that over the years and Container IDs would probably help We need some way to to figure out What's being associated together as a container to even try to make a unifying namespace type thing for the LSM because everybody's doing everything different and that's okay, but then You know, I'm doing something different and the namespaces are different and then SE Linux is doing something different And when you try to get these all together you have no idea what's going on And if we had some way of grouping it it would help us a little bit. I don't I don't think it's a huge win From an LSM namespacing point of view, but I do think it would help To be able to have something that groups all those different resources together. So you see what's you know there Yeah, it's just a difficult problem And no and having them I refer to it as having them coming is going and not being able to Group them and know what you're how it's grouped is a major problem The other thing is locking is becomes an issue and And that's one of the main problems that that we're having with the I'm a namespacing is that anybody who's going to start using State information per I know state information is going to have the same problem because Either the namespace is going away or the file is going away and how you have Can free them safely is a major thought so any help with the locking that's going to be involved I think yeah, there's two I think there's two issue with that this like a formal identification of a container and This well basically everything which is related to the fact is them because you need to use extended attributes also that and then Well, you need to have a way to make them permanent For the ephemeral part Maybe see groups might be useful, but that is not enough The other issue is the relationship between the security attributes and the various namespaces For example, we have our network in namespace. Do we have separate net label implementations and configurations for each? No, we don't With user namespaces, did you want to have different security policies in the different namespaces well some people say yes You do other people say No, you don't So If you want to do a system a contain you want to do a container. It's using username spaces using network namespaces We're Significantly complicating the whole motion a container is supposed to be simple right that's That's why people buy them They're simple. They're easy to use and We're coming in and saying well if we're gonna do anything with these and if we're gonna have security namespace separate from that We have to have to figure out how to how to integrate them if we're going to make a part of those other namespaces We have integrated in there in any way you slice it. It's gonna get more complicated Yeah, I think I mean as you've heard it's We're all aware of it and I think the only thing that I think is really clear is that we need I think we're all in agreement that we would like some concepts of some sort of kernel container ID But even you know what that means and the semantics behind that are One of those things has been debated quite a bit and you know I think that's gonna be largely a user space problem, but just being able to track that inside the kernel Would I think be helpful and then there's the other issue of namespacing which we've talked about in a few of the questions So you're gonna challenge the one last question thing, aren't you? I wasn't going to ask a question. I was going to provide a running commentary. Oh, wow, please I'm just I'm just joking. This is a very hard problem. I think and You know, we have tried various approaches over the years with David's being the most aggressive one as usual Defining basically really making containers an in kernel object Which was rejected for for various reasons The problem really is that I see is If you look at services for example a service isolation the the the Doesn't really make sense to define it as a container, but it uses every every thinkable combination of isolation Is used out there and that's what really makes it Difficult, so either we have to opt for I think we either we have to opt for something like we really make a rigid definition Of what a container is and we don't care about the rest But then you leave all of the Kubernetes folks and service isolation and so on people behind It means you can't treat them as a container anymore. That's just some weird type of sandboxing. So sorry ignore that and German word, right? Yes. Yeah, or Or you make it an arbitrary label almost like p-tax where you say this Slap some identifier on there and that's what we we keep tracking as a container And it can be some sort of arbitrary combination between namespaces and c-groups and whatever and that's a hard boundary to draw and it's like Yeah Yeah, and as an alternative would be to use what can what some of them can already already provide Let's say a domain for cd nukes or well a lot of stuff or even a dynamic domain So, yeah, there's a lot of different options But maybe the question is what do we really want this feature for? Is it just to identify a set of processes or is it to enforce some stuff on that? Yeah, and There's likely going to be different answers paralysis. Yeah, so just to add another variable in there Can I just say one use case? Yeah, so one use case would be people running containerized Operating systems. So they have different disperse running in containers I think that's a reasonably common thing for people when they're building things to just be able to do their labeling That kind of thing and different different different versions All right. Well, I think out of respect for the schedule, which we've already shot and had 10 minutes ago This is Friday night, and I'm sure people have planes to catch and buses and trains So I think we'll go ahead and wrap up But I think a few of us are going to be here for a little bit longer So feel free to to catch us in the hallway or in the back of the room So just want to thank all of you for the questions Thank the Linux Foundation all of our sponsors for helping out to run this and you know Putting the bill for a large part of this we couldn't do that without them So thank you and thank you to all of you and thank you to our panelists here and I think that's it I think we're done, right?