 Hello everybody Good afternoon. We are going to start with the next talk which is about audit and namespaces by Paul Moore So please help me welcome Paul Hi, everybody. Can you hear me? Okay in the back? Yes, good. All right great It's my name is Paul Moore and I have to I have to say this presentation that I'm giving to you today Wasn't actually created by me. It was created by somebody else on the audit team Richard Briggs who works for Red Hat some of you may know him Unfortunately, he couldn't be here this weekend for dev comp. So They asked me to kind of step in and do the presentation, but it's a good presentation And Richard actually gave it at the Linux security summit this past summer Up in Canada and it was great. We actually recorded the videos for the first time this year So if you want to see Richard actually give the presentation and do all the Q&A You can go to that YouTube video. So can I really get your cell phones out take a picture of the URL? Really, I only see one person. All right. Anyway You can also if you just go on YouTube and search, you know audit namespaces like security summit, you'll you'll find it It's very well done video Actually has some production value in there. So anyway, I would encourage you to check it out It's 45 minutes in length. I think so it's not too long And it's it's much more interesting probably than what I'm going to be able to give you today So anyway, um this slide I actually added I kind of thought about giving Richard's introduction slide to see if anybody would know the difference between me and Richard But I figured that would probably be kind of a joke lost on many of you But anyway, so if you watch the video this slide is different Anyway, this is me. That's my Twitter handle. I don't use Twitter an awful lot But if you do send me a message or whatnot, I will respond to you Those are my email addresses. I tend to use both I use the paulmorend.com one a lot for the upstream things But you also see me use my red hat one quite a bit too. They're the same person For the past several years, I mean I've been doing well, I've been using Linux since maybe the Mid-1990s I've been actively Engaged as a Linux developer since maybe 2004 I think And I'm currently acting as the sce linux audit and labeled networking maintainer for the kernel I also created the libsec comp project Happy to talk about any of those if you want during the conference, but today we're going to be talking about audit and namespaces Um, actually a quick show of hands. How many people are here for containers? Okay, now how many people are here for audit? Wow all right I was thinking in my head last night when I was going over the sides of being completely the opposite I was expecting everybody raised their hand for containers and like two of you to raise your hand for audit And that's primarily because there's my boss and my boss's boss here and I figured they'd be excited about audit Anyway, all right. So good news. We're talking mostly about audit not so much about containers and namespaces Because quite frankly that it's an interesting story So anyway, let's get right into it So first of all, what is audit? Hopefully this is not a new concept to you guys and based on how many of you raised your hands I think you know the basics of audit, but for those that don't Audit was created back in 2004 by rick faith who worked for red hat at the time I'm not even sure if he still does. I don't know but It was a red hat project Auditing on linux actually started before this Susie had an implementation which for whatever reason wasn't able to be merged upstream But audits we know it today started in 2004 Dinosaurs weren't roaming the earth then but we at least remembered when they did at that point in time A lot of people like to talk about audit as syslog on steroids I don't necessarily Like to think of it that way, but if you do that's okay. It's it's not completely wrong The whole point of audit is to have a more secure logging mechanism in the kernel The reason is about the time that audit came into existence We were starting to take linux through a lot of third party security evaluations things like common criteria Which is a very rigorous Security evaluation and I see some common criteria people in the back that smiled when I said that so It's a very difficult very painful process at times because you really have to go into the whole Operating system in very fine detail explaining how everything works and making sure that it works the way that you said it does So it's very interesting thing and one of the things we realized when we were doing that is we didn't actually have A good security guarantee around a lot of our logging that happened We've got syslog and syslog is great But syslog ends up in var log with a lot of other application log files and it turns out for practical reasons It's very hard to secure that log At least secure it to the sense that there was enough integrity around the log That lawyers could feel good standing in a court of law and saying that you know based on these log file entries You know bob did this and sue did that at this point in time on this system So we needed a better mechanism and that's why we created audit It works well with sce linux and it works well with sce linux for two two reasons One it's a great tool for sce linux to report on things, you know, and there's an sce linux denial I'm sure we've all seen a navy sea message, right? Wow, okay. I also do sce linux. I'm really happy when there's not very many hands that go up for that But anyway, so it's a great reporting mechanism for sce linux It's also very good because of the way it's structured You know all of our audit logs go into its own directory So it makes it very easy for us to Tighten down and harden that directory because the only thing it goes in is audit logs So we can lock that directory down using sce linux For other applications which helps guarantee that integrity that we're looking for Audits a bunch of different pieces. There's obviously the kernel component, which I've been talking about But it's also there's a very important user space component to this as well There's obviously configuration tools and there's a lot of neat little tools For parsing the logs and doing cool reporting. In fact, I'm going to do a shameless plug as steve here He'd be very disappointing because I'm actually going to plug his his lightning talk If you go to steve's lightning talk, if you look on the board, you'll see there's a big audit announcement It's kind of cool. I won't steal his thunder since he's not here But if you have a chance today, go go check out steve's lightning talk. I think you'll like it So anyway, so there's there's that part of it But for the things that we're going to be talking about today one of the more important things for Auditing is the audit daemon This is the component that sits on your system That takes all of the log information from the kernel and either writes it to a disk sends it out to the network It's actually it's a pluggable mechanism So if you have your own special Log aggregator or whatnot, you can hook directly into the audit daemon and get those and get those log records out of it We also have the normal, you know configurable kernel filters I mean you can obviously do filtering after the fact on the logs, but Most people who use audit heavily generate gigabytes of log information on a daily basis And you can imagine as your enterprise grows the logs only grow So one of the ways we can kind of combat that is with these kernel filters so that you can specify Only what events you're interested in You know if you wanted you could log every single syscall invocation on the system It's a great way to crash your system But you know you could do that So anyway, and finally the last point on the slide This always seems a little silly to me, but I some people do Think audit does something differently Audit doesn't actually enforce any security policy The one exception I'll tell you in a minute Mostly it just reports on what's happening on the system And you know any violations from the other security policies on the system The one exception to that and I doubt anyone here in this room has this enabled. It's definitely not the default You can set it up so that if something happens to your system Or the audit logging mechanism such that it can no longer Safely record audit records to disk You can panic the system The idea being that there are certain groups of users and certain groups of system administrators That if if they can't have a log of what is happening on the system They don't want anybody to use it. It's kind of like if I can't play with my toys Nobody can play with my toys sort of thing So anyway, that that's the only bit of security policy that audit actually enforces Everything else you see in the audit log. That's that's somebody else's fault not ours. So don't blame us All right, so anyway, so I'm going to talk about namespaces But before I do now that I got the quick audit introduction done I like taking questions while we go through the slides I think it's a lot easier than asking you to remember all your questions until the end after I've thrown all this stuff at you So feel free when I get to the end of the slide or if I'm in the middle of slide Raise your hand and I'll try and answer your question And also remind me to repeat your question because we're being recorded. I'm really bad at remembering that So name spaces In short Richard's personality here is you know kernel enforced user space views and That's a great way of looking at it One of the ways I always kind of thought of it Is that we're all familiar with virtualization, right? You know, there was zen and there's kvm q emu and whatnot and that was That was hardware based virtualization and it gave us different views of the hardware Namespace is the same concept except instead of giving you different views of the hardware We're giving you different views of the system Okay, so We've got let's see what do we have we have seven different namespaces here Um You know if we look at the first one the mount namespace which is kind of interesting in its own, right? Um, basically that just gives you a different view of the file system Okay, so every every application on the system if it was running in its own mount namespace Could have a different view of the file system, you know, you could have different home You could have a different user different var different temp It's it's kind of a neat thing especially when we start talking about some of the other uh namespaces that are on here But the first point Richard's kind of got these segregated You'll notice into peers and hierarchies and this is an important distinction If we see the top four those are all peers and what that means basically is a very flat Structure, you know, we were talking about the mount namespace for example So what that basically means is if we've got, you know, four different applications each running with their own mounts file system They don't necessarily inherit anything from each other, okay They're all see a different view and they all have a different representation. They don't inherit anything, okay There is no hierarchy. All right. That's why we call it kind of a peer And we've got that with the mount namespace. We've got that with the uts namespace Which if it didn't say host name up there, would any of you know what the uts namespace was? Yeah, okay. I'll be asked when I first heard a uts namespace. I was kind of what what is uts That's the host name domain name information and whatnot The ipc namespace. This is all the ipc mechanisms, you know Shared memory all the sys 5 stuff the unix domain sockets, I believe When richard was first putting this presentation together over the summer for the Linux security summit We were going back and forth and he was kind of using me as a dummy to do the presentation He presented that and I I asked him I said, yeah, I know about the ipc namespace But I I can't think of anybody that actually uses this can you and he kind of laughed and he said, you know I went and looked at it too when I was putting this slide up. I can't think of anybody that uses the ipc namespace So it's there and you can see it's been there since 2619 It just doesn't appear to be very common. We're not sure of anyone that's actually using it Then there's the network namespace that's also a peer namespace. It's very cool This I think it's easy to think of how you might use that Especially the way it's implemented every namespace gets a fully independent network stack Which is kind of kind of nice and handy The way it starts off you create a network namespace and all of your network interfaces Live in the initial namespace then you have to go ahead and move them Into the individual network namespaces The only way you can talk between network namespaces is to actually talk out over the network and come back in Now we have some neat little things We have some virtual ethernet device pairs so that you can you know set it up to talk between the two interfaces But you know all your normal things like you know, you can set up a firewall between applications on the same system, which is kind of Interesting if you think about it You know ipsec stats, you know all that stuff It's kind of a nifty little thing But anyway, uh, and let's see and that came in 2624 all those have been around for quite some time Next we have the hierarchical hierarchical namespaces Probably the easiest one to think of at least for me anyways the pid namespace We all know on the system, you know For better or worse, everyone became very aware of of of process trees with when system d came about You know and it runs as pid one and then it just it goes on from there Well, the idea with a pid namespace is you can create your own namespace And the first process in that pid namespace becomes pid one and then it goes on from there It's hierarchical in the sense that You create a pid namespace and let's say you're running bash You know, it's the first process you start up in that namespace so that gets pid one But it's hierarchical if you're in the initial namespace So if you're in the if you're in the host system before you started that namespace, you'll still see bash But you'll see it with a different pid Which is a bit odd if you think about it So this one process can have a different pid Depending on which namespace you're in, you know, if you're in the initial namespace Might be pid 3000, but if you're in That bash instance, which has its own pid namespace if you ask it, you know Hey, you know echo dollar sign was a dollar sign dollar sign. I think I can't remember anyway It'll show up as pid one So it's kind of interesting and it it has some very interesting ramifications for audit Because if you think about how are we going to start logging actions for that bash instance if it does something security relevant We want to tell the user. Okay. It was running with this pid. Which pid do we use? Do we use the pid from the namespace? Its own namespace or do we use the one from the global namespace? So that presented some interesting challenges. We'll talk about a little later Then there's a username space which Depending on your point of view. This is either the greatest thing to come along for unique security in years Or it's a source of tremendous terror and fear I tend to fall in the later camp of Terror and fear, you know, some people have those dreams where you wake up and you you're falling I have these terrible dreams or wake up and I'm in a horribly mismanaged user namespace Judging by the amount of laughs I'm assuming you have those dreams too maybe Anyway, so that's that we'll we'll talk a bit more about that later And then we have c groups and this I believe was the last Namespace that's come along. I'm not aware of any that are in development Maybe you do So the basic idea around c groups right is to to put resource constraints on processes and groups and whatnot The c groups namespace Allows you to have a hierarchical representation of that So basically you can you can sort of hide these limits from the things that you're running in a container Which can be very handy All right, so I talked an awful lot on this slide does anybody have any questions for me move on I'll know everything there is to know about namespaces All right So what are containers so It's probably a lot of you that aren't gonna like what I have to say here But from a kernel point of view containers don't exist They're a fiction. Yes Right, they don't exist It's it's kind of I like to think of containers much like Santa Claus Right people get all excited thinking about Santa Claus people get all excited thinking about containers But if you go around you talk to people really talk to people about Santa Claus You get different answers from each person, right? You know you go talk to a kid in America He'll tell you one thing about Santa Claus you come talk to a kid in the Czech Republic He'll talk he'll tell you something totally different You go talk to a kid in brazil tell you something totally different about Santa Claus. That's kind of containers really That's how I think of it anyway The kernel has no concept of containers and as such it's up to user space to define what a container is And as we all know there's plenty of container engines out there, right? I mean dockers the big one that everybody always talks about but they're definitely not the only one doing containers And depending on who you talk to you're going to get a different answer as to what a container actually is However, it seems to be common across the containers and even different configurations using the same engine Is that it's some mix of namespaces Some form of sandboxing seccomp is kind of the popular one, but se links you can also think of as sandboxing wavedan And c groups right because you know especially for people that provide these as services to people You definitely want to make sure you Restrain them so that one container doesn't go crazy and steal all your cpu or network And so anyway, and richards probably if you listen to his talk, he's a little more polite about this He put the kernel has no concept of containers halfway down the slide. He kind of buried it A little more direct, I guess So anyway, the kernel has no concept of containers, which is interesting as we get a little farther into this presentation talking about the audit impact it's really up to the user space container manager to define what the container is And report on it and track on it because the audit subsystem in the kernel really we have no clue You know people want people People have all these requirements for around container logging and at this point in time, you know, it's like we what's a container? you know so it's definitely a challenge and One of the ways we're looking at solving it this last point on the slide Is creating some form of container id or a set of namespace id's to somehow Uniquely identify actions that happen inside the kernel as being associated with a container And this is still an ongoing discussion. You'll see as we get going All right, so What's the problem and when we talk about audit and namespaces and containers? There's really kind of two issues that we worry about or two issues that we that we run into all the time One is as I talked about earlier, we have the audit daemon. Okay, and that's responsible for Basically doing all the audit stuff that that people really care about that actually generates the audit logs And so, you know Where does that run? Is that running in a container? Does that have to run on the host system? Then there's also the issue of all of the Various trusted applications that run on your system You know for example when you log into your system Pam generates an audit record saying hey, you've logged in Vsftp, you know if you were to log into vsftp It you know generates some audit records and mentioning both those because we'll see later in the talk that those actually cost That's a good deal of problem But basically its first slide in highlander there can be only one right now There can really be only one audit daemon on the system We can talk about this more but in practice that doesn't actually seem to be too bad of a restriction because it's kind of It's fairly rare on most container workloads that you actually want to run auditing inside the container Most applications that run inside the container have some very good logging of their own It's usually only when you start talking about, you know trying to manage your whole system That's usually when audit gets involved. And so just having that run on the Host basically in the initial namespace is usually sufficient for most workloads The mount the uts that's the host name the domain name namespace and the ipc namespaces We have no problem. We've never encountered any issues with that with audit Things were pretty much Wide open everything was working well. It's about three seven rc one time frame Then we kind of started noticing problems Some of these were problems that existed for a while It just happened to be that the way user space was evolving the way the kernel was evolving They they didn't actually become real real issues First one was the network namespace The issue was that the All the communication between the audit daemon and the kernel and between the trusted applications in the kernel You know things like pam and vs ftp happen over a netlink socket Okay, netlink for those of you that don't know Effectively relies on the networking infrastructure to deliver messages between the kernel and user space well if you If you had a separate network namespace You know and you you were trying to log in via pam the issue that you had run into Is it didn't necessarily work again the more than i'm getting ahead of myself, but that caused this problem We fixed that in 314 Which was a long time ago. So you guys should be good now We had another problem with pid namespaces We'll talk about that in a little bit The username space as i told about you know this, you know, you either think it's great or it scares you There are some possible security concerns. We're mitigating those right now explain how but eventually we're going to have to address those An audit d basically right now Uh You have to run audit d in the user Initial namespace and the pid initial namespace Everything else, you know, you can you can run it however you want But it's got to be in the initial namespace for pid and for user All right So now we're namespace. This was started to explain on the past one. So, uh, you've created a new network namespace And you're trying to log in Let's say out of using ssh or you're just trying to log in the console It breaks And you want to know a great way to upset developers users Linus, you know, basically prevent them from logging into their system It's a real great way to get a lot of angry hate mail real quick um So anyway, uh When you break something for such a wide group of people you get a lot of proposals about how to fix it Um Because this was pretty wide ranging that the least complex of the simplest and quickest fix went out And it turns out it's It's not a bad fix. Um Basically the problem was that When pam started up, you know, it tries to open a net link socket up to talk to the kernel to say hey Bob logged into the system On a system where you don't have audit configured and it's not running You would get econ refused and so pam pam is coded out in such a way So if tries to open up this connection if it gets econ refused, this is okay You don't have audit configured. That's fine. Ignore audit. I'm just going to go keep going and log in well when we Quote quote fixed things for the network namespace Basically that all of a sudden allowed That connection to be visible and The problem was there were certain there were certain cases Where instead of now getting that econ refused you would get e-perm And well the way pam was configured because this this code was written long before anyone was thinking about namespaces Um people looked at and said oh hey, okay, whenever we get e-perm back That means that audits configured But something has happened that's denying us to generate an audit record And so therefore this person is doing something bad. We don't want to let them log in So in the process of fixing our problem for network namespaces, we pretty much just locked everyone out So We much as you do in real life when you find yourself in awkward situations Sometimes you tell a little lie, right? It's not good. And so that's basically what we do here We sort of lie a little bit and in these particular cases When you're not in the initial pit or username space um We we basically lie and we say econ refuse so that it you know pam still operates correctly And life goes on so Also in real life, you know when you do give these little lies it comes back to haunt you later This is going to we know this is going to be a problem later that we're going to have to solve It it continues to haunt us um But the facts are we have to solve a lot of other problems first before we can get back to solving this one Pid name space, um So last slide I talked about problems where we broke pam now. I'm going to talk about the slide where we broke vs fdp Uh, basically vs fdp auth is a way of sandboxing Created its own pid name space before it would do the user authentication And for a variety of reasons and as I'm looking at my watch, I'm Going longer than I anticipated. So I'm going to start talking I'm gonna gloss over some details. Um, that was not working So basically we uh were there's capabilities and all this good stuff Um, we fixed that and perhaps more importantly what I wanted to talk about and alluded to earlier was the whole pid name space and The fact that you know, you can have one process with multiple pids if you're in a separate pid name space and so process of doing this we realized that we weren't necessarily In the kernel always recording the right pid what we want to do Is we want to record every all the pid information relative to the initial namespace Because the majority of the time when the administrators come on they set security policy and they you know Have all the logs generated. It's logged with the information from the initial namespace Um, because otherwise, you know, we would see a normal user going off and doing a bunch of things as pid one And that's kind of misleading and you know, you would have a security administrator looking at this going like wait a minute What why is Apache running as pid one? How you know, how does that happen? Um, so we had to clean up a lot of the code in the kernel To make sure that we were always translating pids and logging things correctly User namespace This is As we talked about this is this is one area where things are still ongoing There was a lot of patches posted in 2013. There was some good discussion You can google the linux audit linux hyphen audit To get to the mailing list and we have archives and you can go back and you can check it out if you're interested Um What's going on time to go into all the details, but um, there's a lot of good discussion There was even some talk about creating a audit specific namespace Ultimately everyone decided that that was probably not a good idea For the simple reason that you you don't want to have audit records Off in their own namespace because you want to be able to have visibility to everything From the host system. You don't want someone to be able to hide in a namespace That at least that's that was what convinced me But anyway, so we're working on that Right now as I said, you have to run audit d in the initial username space. There's there's kind of no way around it Eventually though, we want to work towards a system where we can have multiple instances of audit d One for each user namespace or at least allow you to have one for each user namespace We wouldn't force you to do that And that presents a lot of interesting things Especially when we start talking about in the kernel because everything in the kernel right now is architected around one audit demon And so if we start having multiple audit demons, we need to look at it And you know, we we have a queue of audit records that the kernel builds up and that we push up to user space As you do with any sort of communication channel But if we were to start namespace if we were to start allowing multiple instances audity We need to start looking at okay. We can't have a single queue anymore We're gonna need to split that up because otherwise you could run into a situation where one container Could overflow the queue and start choking out others There's also we talked in the beginning about kernel filtering For some of the audit records Well, we would need to have in addition to your own queue We would need to have your own rule set because what audit d in One container cares about is obviously going to be different from what another container cares about And the host audit d is probably going to have a completely different set That's independent of everything because they're probably going to want to watch individual containers as well as the own system So it's It's actually quite a tricky thing And we also want to make sure that if you try to configure The kernel in one of the namespaces That you're not making a configuration that's going to adversely affect other audit audit configurations that are set up in other user namespaces As well as the host system. So for example, I told you about the panic We don't want somebody in user namespace to be able to configure The entire host system to panic if something goes wrong With audit because otherwise, I mean imagine that you could have a you could have a container Somebody sets the system up to panic when something goes wrong with audit And then that person just floods the system with audit records and wedges it and then the whole system goes down for everybody The great way to get your container provider upset with you So anyway, and those are just the problems we know about now, you know as everyone understands software development will tell you You know There's the problems. You know when you start And then we get halfway through there's another set of problems that you had no idea even existed Um as referenced by the fact we locked everyone out of pan if he has fdp So I'm sure we'll undercover more as we start going down the prototype path, but That's at least what we're aware of at the moment And so the namespace id Way in the beginning of the presentation I don't know 40 minutes ago Talked about how one of the ways we need to reconcile the fact that there's no such thing as a container Is we need to somehow Come up with something a namespace a set of namespace ids or a container id Something that we can assign to each audit record So that system administrators when they look back in the logs can say okay This event happened in this container and this event happened in this container And there's been multiple attempts over the years I think the first one started back in 2013 Where we were using some proc i nodes to do that and the namespace folks were a little upset with that idea The checkpoint restore people were very upset with that idea because what happens if you were to freeze a namespace Or sorry freeze a container Move it to a different host and restore it Yeah, the i nodes aren't going to match up And that that pretty much that reason right there is what knocked out the first three things on the list Richard came up with an idea of a serial number a monotonically increasing number starts at one and each time you created a new namespace It would increase But the same sort of problem once you started moving things across hosts You know well what what does somebody has the same number? You know, how do you resolve that you can't easily change that number without the user space running inside of that container Having some issues Then there was some some talk about similar to what they were doing with the proc i node They wanted to do it with the namespace file system But they included a dev number with the i node so that it helped a little bit But you still have the problem when you start crossing hosts in a in a whole enterprise So that was kind of difficult one of the things let's skip ahead just a minute. Yeah, okay um So that's pretty much it The namespace id we haven't completely ruled it out, but I think we're definitely trending towards and I want to say my mind is almost convinced that we're going to have to start going over to a container id Container id is basically It's going to be a token a number of something that the kernel is going to have absolutely no clue what this is Your container engine will set it your container will basically tell the kernel it's like all right this This process has this container id And we want all the children processes from that to go ahead and inherit that container id Unless of course you start up another container engine inside that you know and you pivot it off. That's fine And we actually we have some precedents for doing this in the kernel today With session id's for those of you may not be familiar with audit Session id when you log into your system It gives you a new session id and everything you do from that point on on the system You could you could sudo you could su you could change se linux roles You could do all sorts of things, but that session id remains the same So it's an easy way for your system administrator to track everything you do on the system I didn't mean to make you paranoid that sounds really bad now that I said that Dan Like how the way I said token Oh, sorry. Remember I said I was really bad at repeating the question So dan asked and stopped me if i'm wrong, but you were asking basically does the id have to be an integer Could it be a uu id or something like that some arbitrary value, right? okay So no, I mean we obviously we haven't created this we haven't coded it up now The one concern I would have with uu id every uu id I've ever seen is really long And a lot of the audit people want really short things because they have gigabytes of data per day And uh, they they don't like spending a lot of bytes for things like that, especially for something It's going to be an every audit record Okay, so Dan was saying that he he doesn't He doesn't care about particular uu id He just wants to usurp this and use it for other Devious things Because that's what dan does devious devious things um He's laughing But anyway, um This is all possible. I mean just second So All up for discussion. We haven't actually designed this or coded it up yet It can't be huge. We're not going to let you abuse this too badly. I mean people Yeah, people are going to abuse this but we're going to try and limit the abuse But this is the point is this will be a token This will be a value that the container engine is responsible for setting And the container engine is responsible for managing basically We'll just we'll just carry it along in the kernel and do the right thing that way but Use space left tell us so I'm sorry. What's your question? Okay, so the question the question is basically I want this Two months ago when when can you get this done? You stupid stupid man Not letting me do anything I want to do Um I mean I I wish I could give it to you today. I wish we had it done There's only so many of us, right? Um If we get a lot of people yeah, yeah, I know The the person sitting next to him happens to be my boss's boss. We really want this too. So Um, all I can tell you is that there's a lot of people that want this solved You're you're not the only one It's a I'm sorry say what? Hey, it's all open. Oh, sorry. The question is how can he how can he help and All right, we'll kind of run out of time. I'm going to skip the conclusion for right now Because I think we sort of talked about this There you go Camera phone take a picture of it get the links. There's the mailing list um We're on github We actually have a github track or tracking this issue number 32 Um, we have a mailing list the the mailing list i'm posting up here is the linux audit mailing list Um, I'd imagine eventually as we get further down the line We're also going to talk to the container folks on their mailing list Um, but since we haven't quite sorted everything out from an audit perspective yet We would just kind of ask limited to the audit mailing list because we want to we don't want to get sucked into a bunch of different rat holes um So we want to make sure we we know all the requirements from an audit point of view first Before we start talking to the container people saying hey, here's what we're thinking of doing What what do you guys think about this? And part of this is also we're in the process of collecting requirements, too Uh, there's I mentioned in the beginning this little thing common criteria Which is very important to red hat and we need to make sure that we are doing the right thing from a common criteria perspective And we were hopefully going to have a discussion about that this past week, but um The person that was supposed to collect the requirements didn't get done time So we didn't have the discussion, but we will be having that shortly Um, so anyway, if you're interested there's a github issue you can subscribe to it you can subscribe to our mailing list and Hey patches are welcome You know so Anyway, um as far as personal contacts. I I already gave you my email address, but that's richards email address rgb Um at red hat. He'd love to hear from you too. Um But I think richard would probably tell you the same thing that i'm going to tell you and that send it to the mailing list Uh, because if it's something you're interested in odds are somebody else in this room is interested in it, too And it's better if we can get everybody talking together as opposed to having a lot of one-on-one conversations So, all right, so I think we've got 10 minutes left Um, I can go back over the conclusion slide if you'd like, but I'd rather answer any questions You guys may have other than why isn't it done yet? I'm sorry, please Okay, so the question and correct me if i'm wrong. You said that we have two Contradicting statements. I was actually kind of happy that was only two um One was that we don't want anyone to be able to escape audit logging And the other one was that you can only have one audit demon per username space You can't have one audit. Okay, so let me try and answer that if I think where you're getting at right now You can only have one audit demon So we know that that's going to be a problem later So right now we can only have one audit demon. So you can't really escape auditing right now Maybe i'm doing a poor job at explaining this but Yeah, yeah, it's a good thing. I mean eventually we would like to be able to support running One audit demon per username space But right now we don't support that and Why? All sorts of things break Um Basically one one of the issues is how do you start resolving? The uids and the gids and the fs Gid and the fs uid and there's about seven or eight different user identifiers What's that? Yes, but which one do we record? Yeah, yeah, see oh, i'm sorry repeat the question. Um Now I have to remember all the questions So I think basically the question was why can't you have multiple? Um audit demons right now running in different username spaces was that Okay, so So just a minute. I'll repeat it in just a minute. I'm just trying to make sure I understand it So you're basically wondering in the future when we can have multiple audit demons running How would we handle that is that? Okay, so you're you're never going to be able to escape lotting all right, so The concern For the recording is being able to escape audit logging right, okay, so And especially with username spaces because an unprivileged user can create a new username space um You're never going to be able to escape audit logging because the audit demon running in the initial namespace Will always be running and it will always have visibility of everything that happens on the system because there is no audit namespace This is one of the reasons we don't want an audit namespace So that even if you create a second username space and you do run an audit d in that second username space The kernel still has visibility into that second username space and you can still configure the kernel To report on events that happen in that username space to the audit d running in the initial username space keeping and So to repeat the question you're concerned about the the actual uid values and whatnot from there Okay, so you're you're concerned. I'm gonna answer this one question and somebody else had one more So I'm more than happy to talk to you after I just want to make sure we gather things answered So the question was how do we handle the different filtering? So the filtering in the username space adverse the filtering in the initial So And as we talked about we're going to have different rule sets You know, you can't have different rule sets for each username space. So The audit d running in the initial username space can be configured to watch everything if you want it or you can turn that off and User running an audit daemon in Their own created username space can have their own rule set So basically you can adjust auditing that for the username space that you create But you cannot escape the filtering and the logging that happens in the initial namespace So but i'm more than happy to talk about it later if you want last one Okay, so the last question the obvious question for security people is the audit daemon running in the username space will that have visibility to Audit events that happen outside of its own username space. No, we don't want to do that for the obvious reason The way we deal with it today right Merwin I said these are the problems we know about today We're going to have so his his question was about the other namespaces and my response is simply put We know there's some hurdles We have to overcome right now and I fully expect like I said as we get halfway down There's going to be other concerns as well This is this was a talk about presenting some of the problems and some of the solutions. This isn't a talk about saying Hey, here's our design. It's perfect Um, we don't have that yet, which is half the reason why we can't give it to you yet today So if we had all the answers we'd have us we'd have it working So anyway, if you're interested if you want to help answer those questions There's the audit tracker. There's the mailing list So all right. Thanks everybody. I appreciate it Hey, no good. Thanks Well, it's essentially a really stupid question that at the end of the talk But essentially I have a customer. I'm a consultant for that customer They want to audit everything that happens in every container on the system and essentially that sounds like no Well, no, we can we can actually the funny the funny the funny part is um, the fact that we don't The fact that we oh, thank you Good thing I didn't start swearing