 Welcome to the final day of your BC con 2014 our speaker today is Chris ups Johnson's Well, there's been raising hell in the open beastie for years. So take it away So I am pleased ups This talk is actually about security. So what I thought we'd start with is how many people are developers? Like actively develop software. All right, just out of curiosity of the active development and louder of software How many people do software that you would consider security sensitive? Everybody should be raising their hands. That's the moral of the story who has users of their software. That's a better question All right, so security is a problem. Okay, so who went to see Tido's talk yesterday about security as well All right, so we're all thinking about that. Hopefully more now Given the last few months and what's happened and before Anyway, so I Just wanted to start by laying out a few assumptions or you know the situation in general and Which I think applies to all of us right now is number one Is that you develop software and if you don't pretend that you develop software and Number two is that people use your software if people don't use your software You know you're you're in a bubble. So it doesn't really matter security per se But this is usually the case for most of us and if we think about this we can really change this around To say something like this Basically that the software you write probably has mistakes in it and that if people can use that then they're probably going to be financially You know Going for the actual resources that are on your system So another question I could ask now is who has written software that has been exploited in some fashion More of you should be raising your hands. You probably just don't even know it yet So who has administered systems that have software that has been exploited? Okay, so so so already, you know, there's some mistakes other questions. Who has written software that's never had a bug in it All right, who absolutely has bugs in their software right now If you're not raising your hands and that doesn't make any sense because you you know Right so who probably whose software probably has bugs I'm pretty much everybody, right? So the question being if you haven't found the bugs yet Somebody is going to and when you fix it, you're probably going to introduce new bugs that another person is gonna find So basically no matter what's no matter the best intentions of all of us And you know generally generally the intentions that are quite good We are gonna have bugs in our software and that's what this talk is about not so much writing perfect software because it's never gonna happen especially when somebody like me or or you know, other normal people are writing software and we're not super geniuses It's gonna be broken. So the question is what do we do about that? You know, how do we accommodate for the fact the software we write is gonna be broken and people that are using it Are going to use that brokenness to take advantage of it and get to the underlying system resources that's My talk is bugs ex ante ex ante being a Latin term for from before Meaning bugs already exist in your system right now So, you know, how many people are running software that they wrote on the network on the internet? So these are the same people who are raising their hands when they said that their software certainly has bugs in it You know, that's a it's a little scary. Of course, that's exactly what we should all expect And the kind of theme of this talk is how to protect the system resources meaning the machine that your software is running on From the weakest link of the whole system, which is you I mean you're making mistakes They're in your software and if you're not making the mistakes, which you probably are it might be in a third-party library Which you might be using voluntarily or might just be there like in C lip a lip see which is just there You can't do anything about it. So there are mistakes and what do we do about it? So this is to an attacker Which is this lovely dog right here. This is what the system looks like. This is nice little kitty right here It looks like true love, but it's more of an appetite thing Your software is this thin sheet of glass right there, but that's all it is That's just you know, the dog is there. It's looking in on you and you are the glass in this particular image right there Yes, it's a little scary So what can we do about this? You know, this is not really the the aim of this talk, but I thought I'd bring it up anyway We could do things like write defensive code, which doesn't really have much of a meaning to it But we'll get to it later now we could use auditors auditors are greats Qa flush out our bugs, right use up-to-date audited libraries And you can see this is getting a little ridiculous a language with formal underpinnings Who's ever done that who has ever written a program that actually has a formal underpinning that you can do proofs That's two people now in the entire room. It's a nightmare. It takes so long. It's ridiculous You can run on system supporting your defensive strategy Fortunately, that's why we're here and while we're dreaming we can ride our unicorns to work every day because none of these Things really happen Once we adjust for expense we take out the team of auditors. Those are expensive. We take out the QA. That's expensive We don't audit our libraries. That's also expensive. So we're writing code now We're using libraries We might be using a language with formal underpinnings and we're running on systems that are good for defense And now when we take time out of it because of course time is pretty much the most important thing We lose everything else. So really all we're doing is writing code as quickly as we possibly can Making as many mistakes as we possibly can using libraries which have been written by the same kind of people And the best part of all this is running on systems that that are concerned for us that are there to help us and That Usually have resources to help us not make mistakes Yeah, we did They may write a unicorn to work. No, I didn't think so So this is a restatement again of the problem is that Usually there's there's not much separating us from the bad people, you know from the system resources, you know to the bad people So here we have some nice kitty cats down here in the distance and we have a very concerned individual up here It was just looking forward to meeting them and a separated by about two stories. So that's that's all we really are There's really not much separating us and this should scare you a little bit And I know personally when you write a piece of software that's facing the internet You put it on the network and all of a sudden you start seeing hits come in from bots from random places And you start to think like it just takes one and it's over It's a little scary So to restate it before we really get started Things we absolutely cannot change our economics if people out there Can benefit from invading our systems. They're gonna do it because they can make money doing that That's absolutely gonna be the case no matter where you are There's always a place where people who are less advantage than us in terms of finances and And who don't have as much to lose so they're gonna do it no matter what no matter where you are The internet is a global thing. It's gonna come from wherever it comes The second invariant which was demonstrated earlier is that your software is buggy. You just don't know it, but it's buggy Somewhere out there The thing that we can change though is The actual resources that our software can see on the system because that's what people are after right You know, they're not after our software. They don't care about our software or software is enabling them to get to the actual system itself So if we think about you know users aka the people who want to take advantage of us our Software and the resources themselves, you know, we can't fix our software We can't change the fact that users are gonna take advantage of it but what we can do is to take those resources and find a way to To to set them aside to make them unreachable and that's what this talk is about Before I talk about what we can do now I think it's useful to start with what people used to do and as you'll see or hopefully you will start to see Nothing has really changed in 40 years. That's a little scary, but it's absolutely true So I'm gonna start with a brief history of Restraining our software from the system that it runs on and it goes back to 1961 It actually probably goes back before these are just highlights And if anybody can think of something really awesome that systems did in terms of capabilities or permissions or segment separation Back in these times. Just feel free to shout it out because it's very interesting So let's start with the ctss. We'll talk about it very briefly I don't want to spend too much time, but it's fabulously interesting to see people doing the same things making the same mistakes 40 years ago Acknowledging that they made the same mistakes we do right now and doing nothing about it And then we do the same thing 20 years later, and then the same thing again 20 years later Arguably, we're doing the same things now in terms of making mistakes that we did 30 years ago And there's actually some nice text retrospectives on these systems that were written in 1975 that say things like It's just too complicated to write a profile for security like cistrace profiles It's just too much and anybody who's tried to write a cistrace profile knows it is just too complicated to write a cistrace profile It's it's the exact same criticism Anyway, so so we're gonna talk about ctss briefly and Unix because they're related we'll talk about multics Which is the you know, it's the grand security research in terms of money at least We're not gonna talk about RC 4,000, but that was one of the original micro kernels which Multics again used in terms of its security kernel Lampson was the guy who really defined the the the theory of what it means to have an access control list, which is kind of interesting Then we have things like discretionary access control the bell la pedula model Which is basically military security and we'll actually talk about this briefly because a lot of the way we think about security in Terms of resource constraint and capabilities is derived from the military But it's ridiculous because you know as regular users We don't have any need for that you know We don't think in terms of classified or top secret We think in terms of should I be able to open sockets should I be able to read files? And it's interesting that a lot of our security perspectives are driven by a method that we just don't use We'll talk about hydro which is very interesting It's the first capability system and then a little bit more Multics We're gonna leave out everything else including some biggies like system 38 the earlier IBM things as well and Of course nothing after the 70s because then there's this enormous amount of research and we're going to ignore it for now And I've never worked on one of these but I actually have seen one I think at the University of Latvia they have an old 7094 or something equivalent in its Hall of Attic Wherever these things go to sleep So here we have a description from the CPSS programmers guide, which is available to download by the way where it talks about the whole group user and other permission bits on a file system. This was 1965 but the system is from 1961 so 1961 is when people were using File permission bits and interestingly it didn't even start out having an all users bit It was just group which they called the problem number and programmer number which was the user So this goes back to 1961 people have been doing permissions for a long time Who has screwed up permissions on their file system at some point? Yeah, that that is a is a 50-something year old problem that people have been doing and yet still people You know you fat finger it It's incredible I felt badly actually because I've done this many many many many times and But at the same time bit of solidarity like people have been doing this for 50 years I couldn't actually find a picture of the GE was 645 there were some GE 635s But I thought Maltics is really useful to talk about because a lot of the things that we think are so fancy and cool in terms of Security these days were actually Maltics projects, but who actually has worked on Maltics? Please anybody? All right The system was a phenomenal waste of money, but at the same time it you know a lot of things that we use today were invented on it It's very very interesting If anybody gets a chance go to Tom van Tom van Vex website Maltitions org. It's the most interesting website out there It's a fabulous journey through the history of computing mistakes Tom van like very interesting So they took this one step farther and The whole concept of seeing everything as a file really came out of that, but they call them segments of course Where actually memory was mapped in the segments as well as files as well as sockets pretty much everything And then they just enacted the same file permission bits on top of that and boom you have access control lists So that's basically what this says this is from the protection and the control of information sharing on Maltics done in 1974 as We all might know Maltics was certified as under b2 certification the orange book and This took many years from then actually do and that the train of getting from the original Maltics from the early 70s To the 1980 version of Maltics that was actually certified for military security is incredible The things they had to do to get that and they still managed to break it all the time is the hilarious thing So this was supposed to be a military grade Operating system that was fully secure and yet No, I will see in a few slides. We'll see and yet It was broken all of the time all of the time not because the actual security of the system was bad But because people just didn't want to use the resources that were available to them They just ignored it But we'll get to that in a few minutes Hydra is not very well known They ran on a pvp 11 and Hydra was an experiment in what's called capabilities-based operating systems We're not going to talk about the formal language like discretionary access controls or mandatory because they're really confusing I think and They're not really relevant to us. We just want to have security. We don't care about the technical terms behind it really per se but Hydra was really neat because you Essentially would take all the resources that were available to software and you would put them into a sandbox essentially So this was where sandboxes really came out of was in the early 70s And of course it was done for the exact same reason we do it today For to prevent people from shooting themselves in the foot So it was prevent your software which has bugs in it from screwing the rest of the system Or as they say it we therefore cannot allow a single user application to commandeer the system and to the detriment of others. So this problem still exists today. This was 1975 We still have this problem today So this is a nice picture involving two gentlemen Paul Cargher and Roger Shell It was taken in 1984, but it's relevant to the early 70s. These were the guys who Went on a mission to break into the multi system before its certification and they did So these despite all of these multi million at the time multi millions of dollars that were invested into multi security They still managed to break into the system not just once or twice, but left right and center the final report on multi security is Really awful. I mean it's just it was basically wide open And this was again right before the military certification so that was it was in order to get that They were kind of trying to route the system left right in center So question asked is what went wrong? How how is it that so much money was was involved in these systems so much money? I mean millions of dollars in the 70s How is it that so many people wrote so many papers? conference talks Money money money, etc. Money and yet still the systems were just falling apart I mean, how is that even possible? You know here? We are as BSD systems We don't have these multi millions that are flowing into our coffers And they had that and they still had problems. They still had security error So don't feel badly, you know if your software doesn't quite work if you find yourself exploited from time to time Just sit down and think well There were how much was it was like four or five million dollars were invested into multics and they still broke that too so it's not you know, it's nothing really to be that worried about but What people came away from in the 70s and watching all these break-ins was to say that and this is Jerry Seltzer again saying One too complicated the security my the systems that already existed were too complicated and they couldn't really be audited This sounds familiar right? Who's ever inherited a big piece of software looked at it and just went Yeah, it's it's just too complicated. You just can't do it and go don't say yes, I know you're talking about Mandok Yes, yeah, exactly, it's it's just it's just to you know, you look at it your eyes start to you think it's water But they're cheating out it's blood And and it's it's over you just don't want to do it and it's never going to happen number two Of course is economics and this I think we know even better that it's just cheaper to do things in a privilege Or or administrator or super user mode because we don't have to worry about the file permissions We can just do it like this this we're all guilty of of course is just doing it the easy way Of course not me because I'm giving the talk Rush to get it on the air. I mean this is the big one and in earlier nobody battered an eye when I said here's the ideal situation But here's what we do because of our time constraints and yet here we have people in 1974 saying because of our time constraints We're not going to do all these cool things. We're just going to do the absolute fastest The biggest one is lack of understanding and that of course is the problem in why I'm here right now Who knows of all of the bsd security Software Resources that are available to us who can actually label them all from jails cistrace wx aslr There's a man. They're all over the place and some of these like what Tito was talking about We don't need to know about because they run in the systems themselves. We don't need to know about You know randomized stepgap stack gaps or or or these kind of Inside of libc or memory. We don't need to know about that But the things we need to do that we as developers need to write we don't know about and that's that's that's bad oh Yeah, Hydra also same exact thing. It's just too too complicated People just didn't understand what to do. They wanted to take their systems. They wanted to make them secure By using this capability system. They just didn't know how to do it So this is a major problem still today We haven't talked about eunuchs yet. So now we're starting to get modern All right, we're gonna go from the 60s to 70s and 80s eunuchs So this is Dennis Ritchie again First this was a very interesting quotes and I didn't know this before There's this kind of prevailing notion that we all have that eunuchs is basically multi stripped down yet Richie seems to disagree and says it's just ctss Which of course makes sense because ctss is multi stripped down. So this is actually an interesting comment As we know the the most interesting security feature on ctss was file permissions So we're really not talking about advanced security here And in fact he goes on to the same paper to say that There are several security problems now. This is pretty much the understatement of the century because in the 30 or 40 years since writing this paper There have been more than several security problems regarding eunuchs. I think we still had one five days ago And what was the bash problem was five days ago, right? It's several security problems So now I'm gonna really start my talk again for the third time and So now we're taking a slightly different type We're now considering ourselves as the developers and what we can do and this is how often, you know We end up feeling about ourselves after our bugs have been exploited is that we had just had no idea what we were doing whatsoever So as time goes by what has happened since this glorious age of security research in the 70s We're pretty much just this list this is disregarding linux things which actually do manage to add several Equally inscrutable things to this list. So linux does have its own things. I'm just talking about BSD and I'm letting Mac kind of work in there just because it shares a lot with free BSD and Or Darwin or whatever we really want to call that so here's a question We're all aware of chum out and said uid. Yes Vaguely, okay, we all know true roots We almost set our limits. We've all heard of jail. Who's used jail before? Okay, so we're doing okay there. Who's actually use this trace? I'm actually surprised. I thought I would be the only one raised in my hand. Okay Who's used the free BSD and Mac POSIX 1e facilities the ACL and the MAC and the ACL facilities? Who has actually used those? Who's even managed to read the man pages for those? Who started to read the man pages for those? So so okay, how many free BSD users are here? Okay, so none of you have actually used these incredibly powerful tools that are on your own systems And I'll tell you why too. I mean we'll look at the man page and you'll see why it's it's just I mean Whatever, okay, so k off on net BSD. I threw this in there. Although. It's not particularly relevant just because One I wanted something from net BSD And two it's really powerful, but there's no user line interface It would be good. I'm just saying to any net BSD people out there I know there was some subsystem construction still suffers from being ad hoc being inadequate software support for managing the programs data structures. So basically 1978 okay But but that's that's nothing to be ashamed of at all because again the same mistake. This is a tradition I mean that goes back to the early 1970s. So we're just following tradition that has been laid back by our four our four bears Um, chaos is interesting that there were a lot of attempts to do jails over chaos Even I think capsicum over chaos, but nothing really came out of it, but that's not Sandbox in it is a very useful one. That's completely hidden away from view on Mac systems Who's who's even heard of sandbox or sandbox in it on Mac? Yeah, it's it's a tricky one and there's no document I mean what we'll see about this later in the last one being capsicum who's heard of capsicum And this one is very well marketed and very I'll talk a lot about capsicum So as you can see though in terms of timing There's a little bit of a break there, you know, we have about 18 years between set our limits and in 4.1 CBSD and jail were basically Nothing happened whatsoever So what was happening during that time in terms of security was probably the point where we're broken in a lot And then we try to fix it later and now we seem to be back at the we're broken in a lot phase But anyway, so so we have lots of tools to use all of these are available on BSD systems today right now Who has used 50% of these? 40% 30 20 Okay, so he and I think the why is a useful question But I'm not even gonna ask it because I think it's obvious the why would be because it's hard, right? They're hard to use. I mean and we'll see you later as we talk about chum out and set you ID is that they're hard and Two is lack of documentation and we'll look at that also briefly. So let's go over these more or less one by one And I want to briefly talk about some concepts because not all of these are the same obviously We're talking about kind of different things here and I'm lumping them all under security But they're not all the same thing. We have three basic concepts One is containers I think this is what we're most familiar with containers are like a jail or a chew roots or sun container or Linux v Server or whatnot where we're actually taking our world view and Constraining it to a given file system to a given set of processes to a given set of network interfaces And then everybody in that jail can see the same things So it's basically a way of containing not only a process, but maybe a user or something like this It's very heavy-handed and and very very useful in many regards. So it's a kind of way of partitioning the system a Very different is the concept of capabilities where we say a given process or a given user Can cannot see Parts of its maybe contained environment so we can use capabilities within the container We can say you're in your jail, but you can only see these files or only see those files You can only access these sockets. You can only do this you can only do that It's a way of saying what a process is capable of or a user is capable of and then the last one I didn't really know what concept name to give it. So I just said labeling basically access control lists Chimad said you ID all these things are basically saying You're part of this group or you're this user thus you can do that. So it's kind of a way of capabilities with labeling And but this this is the most venerable. I think at some point we've all been exposed especially in the past few years to privilege separation and Chimad said you ID and friends Priv dropping as well Form the bulwark of that and I think a very nice quote This is supposed to be the thing we should be best at because we've had it since Yeah, you next v1s. We've had this since 1971. Yeah. Oh, yeah So that's that was a 40 something year-old concept you were just able to find bugs in So we're all supposed to know this so well, right? We're all supposed to know you you fork a process you do all your privilege work in one you do your your sensitive work in another You communicate over some sort of socket or something like this and and yet nobody gets this right I mean even probably one of the the most well-known programmers and Most powerful in terms of brain says requires complicated and very detailed programming for non-trivial programs That should terrify you because that's the other rats saying that I mean, I don't think at least I for one I'm not really packing the same guns and if somebody else who's like that says it requires complicated and very detailed programming for me That just says impossible So But doable for simple programs, which is nice. So who has ever done privilege separation. It was actually written Was it easy for which programs just have a curiosity Okay So you've done it for several was it was it was it a difficult was it doable and simple programs? Or was it required complicated and simple and very detailed programming? So if you start Getting forced to do it the right way. What if you had to start with existing code? You think it would have been as easy Yeah, it's it's basically it's it's it's it's easy for us to imagine I think is a better way of saying this but actually doing it demand if I it's getting really stuffy now But actually doing it doesn't entirely oh Okay Right So essentially this is what we should be best at and yet when you actually look at the history of our doing it's It's pretty complicated. I think did anybody go to Henning stock yesterday If you went to Henning stock, he actually had one slide that that went over the privilege separation process of Do you remember which demon it was was it bgpd? Yeah, it was a whole slide with arrows everywhere and little circles and everything it was very complicated I saw it and I cried because it's something that we have had available to us since 1971 and it's just still very difficult to do And that's that's that's just one of these that I'm talking about right now Chirrut is another one Chirrut never was a security mechanism. I don't know when it became one It's this is the the Chirrut that you see right there was actually from the initial Chirrut implementation There was no security check. It just said okay do it And then it was only in a 1981 commit by Bill Joy that some initial Security constraints were added so it's not trivially easy to break out of it It was never meant to be a security mechanism people have to stop thinking about it as a security mechanism It's a convenience mechanism and nothing more Set our limit who uses set a limit for anything but cores For anything, but you limit C Okay, a few people This one is useful, but very tricky and we can talk about that briefly in a case study at the end of this So set our limit is useful, but if somebody really gains control of your system, they can just change it back, so It's useful, but but but very brittle Jail I think was the first big, you know now we're gonna be serious about security done by Paul Henningham And of course lots of people here have used jail jail is nice, but it's a very First you have to be rude to run it second it can be recursive. It's a nice container, but the implementation of that container is such that We don't know if there are holes in it and I talked about this several years ago when I was doing molds We're not going to go into it right now But for all intents and purposes, it's a great system that more people should use But it's still not going to help you when you have two processes that are in the same jail that both need to access a Similar set of files and you don't want to have one overwrite the other. Yes Yeah Yeah, you cannot do that Okay, so you can you can run a jail from within a jail Okay, but that's new in that case that new. Oh, okay. Well, that's great news in that case We can scratch that one out. So jail is it is a useful tool and I've always kind of like jail because it's simple You just run it like this You don't need to worry about the details and and I think because we've talked so much about how Complexity is hard. We should really take a look at that not in terms of how it's done But the fact that such a simple interface of just saying jail me worked and and and because people are so familiar with it Obviously, it worked not just in terms of utility, but that we understand it enough to just be like, oh, yeah It's a jail and this is really useful Cistra's does not have the same benefit. So we've had a few people use this trace It was well by Niels provos. I could not remember whether it was originally done in net BST or open BSD And I couldn't find the original commits. It was one or the other They were both merged at roughly the same time is all I really remember And there was a really big bruja on 2007 when Robert Watson found vulnerabilities and it's Using Cistra's there are two ways to use it You can either use a user land program Cistra's one in a policy file that says this program is allowed to do that and that or You can do a programmatically in what can only be described as a very intricate dance It's it's performance art and we can see some examples of this if you'd like There are also some major problems if you're doing this programmatically You cannot Cistra's yourself You can only Cistra's a child or another process and this immediately adds another level level of complexity to programs Well, we're inheriting them because now we have to do the whole fork if we're already privileged separating then it's not so difficult But if we're working with existing code, it can be quite hard So again the privilege separation complexity applies to Cistra's and that is a major problem Other than that Cistra's I think is the first And really still almost only capabilities based system that we have available to us today Unfortunately, it's not so good for security anymore. So this is almost not even useful to talk about I mean if we're gonna allow fork then you're gone So Cistra's is useful, but Next is POSIX POSIX 1e and again this was a lot of Robert Watson's work actually So he really brought a tremendous amount of security information to the BSD community via trusted BSD He brought ACL who uses access control lists not file permissions. You actually use them Okay on the VFS So VFS file Access control this or for other things as well Okay. All right. So we there are some actual users of this, which I think is interesting because I thought there wouldn't be any They want to move this into the next version of POSIX. Do you also use? Yeah, it's Right, that's that's we'll get to this problem So that there are facilities for doing this on but it's just free BSD and Darwin The ACL three-man pages is both on free BSD and Darwin set F ACL set file access control This is something that they want to push into POSIX. I don't think it's there yet though There's also mandatory access controls which nobody can really define succinctly So it's a bit of a mystery word, but essentially it's this whole military grades Defense measures that I was talking about that were done again in the 70s using the same people Biba Multilevel security Bella Padula that were done of course in the 1970s as well. So it's what's what's old is new again I Suggested people look at these man pages and try to figure out what they do because I think it's impossible There are many of them. They're all over the place and it doesn't really say just do this It says you have to know everything about your system and you have to do this and you have to do that they're it's very complicated and That's not necessarily bad about the writer of the documentation. It could be that the system itself is very complicated Either way, I tried reading it all I went through everything that was there. I finished it I still didn't really understand it We will talk about sandbox in it and that I'm gonna hold up as a as a good Framework that was kind of screwed up because it's Apple Chaos, I'm not gonna say much about because again, it doesn't have a user line interface. We can't really use it chaos was influenced by Mac 10.4's Sandboxing which was in turn from trusted BSD. So chaos was influenced at least by the same things we just saw But again, I'm not gonna go over it Sandbox in it is very useful It's on your Macs and if you want a sandbox a given process you've run one function and that's all and you tell that function What do I want this process in its children to be able to do? No internet no network no writing no right except temporary and just pure computation. That's the easiest Way of Doing sandboxes or resource constraints that I was able to find but it's only of course on Mac Actually finding the fact that that exists was quite difficult and we'll see Yeah, the documentation for sandbox in it is is basically that So you are basically seeing the man page right now. It's it's awful a much better read for what sandbox And it does is available in the case study will briefly talk about because I'm running out of time Which is open SSH which would reveal to me what this does not do now This is not available anywhere in the documentation. I have no idea how the guys who wrote The sandboxing which we'll talk about for open SSH figured out What these actually do or do not do maybe it was just trial and error, but it's a great interface And I think we can learn something from it because really if we think about sandboxing our programs That's all we really care about You know all we want to do is set some broad limitations and then maybe fine-tune them later But unfortunately, it's just completely undocumented, which is a problem Capsicum is the last and probably the most complicated of all of these very recent work It's also kind of hard to wrap your mind around because capsicum is very large and capsicum actually requires us to think somewhat differently about Unix because We know what a descriptor is we have file descriptors. We have file descriptors that are really sockets Capsicum also introduces a descriptor that's for processes as well So it's it kind of jams this into the whole file descriptor model and it does that with PD fork However, people are actually using capsicum on FreeBSD, which makes me really happy. There's a list in them out there You can just search through the the source tree to find it but we have BS patch, BSDF, TCP dump, fetch, pzip2, syslogd and so on. These are all actually using the capabilities that are available from Capsicum, which is great So that that gives me a little bit of hope, but it's really complicated to use all the same. So So this is the last thing I'm gonna do because I'm pretty much out of time right now There's one program that I found that really tries to bring all of the sandboxing together that we can really learn from and that's OpenSSH Who's used OpenSSH sandbox mode Yeah, you all should raise your hand because you're using it by default I think so it's it's it's there You are being protected every time you use SSH that should give you this warm Nice feeling that that somebody out there is really thinking I could screw all of this up Probably gonna make sure I don't do that so they sandbox and And that's great For us as the users But I feel badly for the people who developed this because they had to take that huge list We saw earlier and say I need to make this portable to Linux the bsd's I'm sure there are other operating systems out there. I don't know and they have to consider all of that so Actually doing sandboxing and OpenSSH. Yes, right. I'm aware of that. I'm just I'm keeping it as general as possible So in order to do sandboxing on OpenSSH It's about a thousand lines to do that Portably now think about how many bugs can live in those thousand lines. It's a little scary So this is a list on if we go to the OpenSSH source code, which we probably all have somewhere because it's a good study and We look at how it's actually involving sandboxing and when they say sandbox all they really mean is I want to take This process and its children and disallow them access to the environment certain parts of the environment Which from their perspective is basically everything in Order to do that properly it took a thousand lines That's scary. I mean this is yeah Yeah, without second Right, it's it's for portability. Yeah, so the reason we have so many is because All these security things we talked about you know what I had written next to it which bsd It's available on some were open bsd some were free bsd some are Darwin So in order to write a sandboxing for portable code You have to think about all of them and it's it's a little bit of a nightmare So second filters for Linux we can disregard that so that brings us down only to about six or seven hundred lines of code So in terms of security that it's just a little ridiculous and it's no wonder that in 1975 people were saying It's just too complicated to secure our own systems simply because it really is it takes 700 lines to do and these guys are Extremely good too. Yeah, I recommend reading the source code by the way It's it shows you what the documentation for the the sandbox systems does not tell you The methodology they use is just privileged separation and they have to do that simply because of cistrace So cistrace is the most complicated of all of these if we look at the list that I had So the first one Chimald and said you ID are probably the most difficult Chiroud is just one command Set our limit the same jail has a system called interface, but It's a container. So we're not really going to go into it cistrace hugely complicated I mean anybody who looks at the cistrace main page is just It's very long. Nobody actually understands the POSIX 1e. So Anyway chaos also we're not gonna talk about sandbox in it one function very easy capsicum Also slightly more complicated, but not as bad as cistrace So anyway It just uses privilege separation and it has to do that because of cistrace. It's you have to look at the source yourself It's not easy to do this A small other case study is a program that I had written that was modeled after open SSH's sandbox for a CGI framework Just as comp I wanted to make it really easy for myself. I want to have sandboxing and Still without even including Linux. It's already almost at a thousand lines. It will be there very soon It's just no matter what no matter how you do it. It's going to be complicated and this is a problem. It's like it's a major problem So anyway, we're now I think at the very close of this So I thought I would leave you with something that doesn't really make sense anymore It's a quote by Ken Thompson, which says you can't trust code that you did not totally create yourself Who trusts their own code? Yeah You want to raise your hands you all want to I guess but now you're not gonna do it because of What's the expression about roads and good intentions So this this this quote I think Guided a lot of people in terms of how they think about security It's the whole do it yourself and not an entered here But we make so many mistakes as it is that I mean it's ridiculous Of course, we're they're not intentional mistakes We're not intentionally trying to damage our systems, but Probably our library writers are also intentionally not trying to use scan F Or they're intentionally not trying to use gets or something like this, but they might have them in there So, you know, this is something that we really should take away that it's not exactly true You can't trust yourself. How are you going to deal with that and? Unfortunately, you're not going to deal with it with less than a thousand lines So this is my favorite picture by the way in the world. It's a case. You can't see it It's a dog sitting at a computer saying I have no idea what I'm doing and when I was writing the thousand lines for sandboxing I really felt like that. It's like, you know, the documentation was wrong the Or just so inscrutable. I had no idea what I was doing Things just failed left and right tried to set our limit actually using that to limit the number of file descriptors You have open you don't know how many file descriptors you already have open to start very easily So you can't just say, you know, I want no file descriptors. Your program is gonna crash like that So it's it's it's very ponderous There's a bit of a downer. I know but That's that's the state of affairs Thank you I'm wondering a bit what can be done about it And one thing is obvious you could take code like ntpd or open SSH and Look at it and try to do something similar That is for the short short term probably not that bad But in the longer term you want something simpler and the solution probably isn't to Just invent a tense framework. What would you say? Where should we go? So I personally like I like the sandbox and it concepts I like it because it's easy and that is for me is really important I want to be able to in a single command basically say I want to be able to do nothing but look at the file system. No sockets Nothing fancy just file system I also want to be able to say just network or or nothing at all because most of the stuff I do is pure computation And I think that they got that right Unfortunately, what that really means is a different story. What does it mean not to be able to open files or sockets? There's a lot of wiggle room there and the documentation is very poor Also the moment you start to need more than that the moment you say I don't want any files Except one that's what we run into a major problem because we don't have something that bridges the gap there and I think capabilities tries to do this by saying you can just restrict everything by default and Then you can add in little bits at a time that you want That's really opposite you say what you want and then you just allow everything else but I think that there needs to be a lot of thought done into how to I'm not going to say markets I'm going to say document, but I really mean markets and the tools that are out there already Because they're very poorly explained to the extent that it takes hours just to understand even the most basics And usually what you end up doing is what what I did I just abandoned looking at the documentation and I looked at what other people had done and said of looking at NTPD I looked at SSH because I knew that it had a sandbox About that NTPD on it basically it runs without a root privilege anymore because it doesn't need it after all you just want to set the clock and What we did is introducing a pseudo device that allow resetting the setting the clock from iOS ATL And the file permission to the pseudo device allows NTPD to do it as an unprivileged user Right, and I think that that's also the easy case too because when you think about NTPD all doing is basically one thing But a lot of the programs that we write are accessing a few files a database usually You know sockets one or two things either a database connection or maybe RPC or something like this So it's never as easy as we want it to be But I think that the whole concept of starting with denying everything and then adding it in is useful But it makes all of us work much harder. So in go that's your question. Really. I don't know I don't know what the good approach is all I know is that what we're doing now Didn't work before and it still doesn't work now because nobody's using it if only open SSH and NTPD and privileged separation for a few others are really using any sort of security whatsoever and That's either we think that we're brilliant and obviously we don't or we just don't understand I mean it's it's one or the other and I know that we are not we're great We're awesome, but our code is bugs in it So how are we getting from we know our code has bugs in it too? We're going to be exploited what we do about it. You know, we need some sort of way of connecting these Unfortunately, I don't have a good solution right now all I know is that the problem exists and it's pretty significant So we have all the tools out there We have to make them work together Let's think we're speakers