 I'm the SMAC maintainer among other things that I'm doing here. I've been working on secure systems since the 1980s. So I have a bit of experience with this, and that's why SMAC came about. A SMAC is a third-generation multi-level secure system. The first generation of multi-level secure systems used strict Bell and Mepogela security model, which is to say you had a level and a set of categories that you used to make your access control decisions. So you could have a secret level on your data or on your process and then a set of categories which you might be cleared for. And that was great. It worked really well. But everybody we tried to sell it to said, gee, I'm not in the U.S. DOD. That's not what I want to do. That doesn't work for me. Even if you actually then went out and demonstrated that you could actually do exactly what they wanted to do with it, people would say, but you don't understand. I'm not the U.S. DOD. That's not what I want to do. But you're just using it this way a little bit. You're not even using it differently. You're using exactly what this does. They would still say, but I'm not the U.S. DOD. That's not why this doesn't meet my requirements. So we fiddled around with it for the second generation and said, fine, what we're going to do then is we're going to provide some aliasing capabilities so you can give a name to something. And we're going to give you bibe integrity as well. So you can do integrity checks in addition to your sensitivity checks. And people said, yeah, that's really great, but you know what, it doesn't do what I want to do. I'm not the U.S. DOD. So we scratched our heads and said, well, okay, what's the problem with it? Well, I have to specify all this stuff, like my levels and categories, and I don't use levels and categories. I just want people like this to be isolated from people like that. Okay. So we put in an alias mechanism. That worked really well. As people were using just aliases, they kind of forgot that they had bell and lapogela underneath. And so the third generation was, well, why am I bothering with these levels and categories and bibe integrity grades and divisions when I could just say, here's the name. Here's the name of your security bit here. And then do the comparisons based on that. And that's what SMAC does. And it doesn't do other things. It doesn't do discretionary access control. We've got mode bits and heaven forbid access control lists if you really want to do that. It doesn't do privilege. We have a capabilities mechanism that works just fine unless you consider sysadmin. So SMAC doesn't do that. It does mandatory access control. And that's all it does. So SMAC is a mechanism that uses labels on subjects, labels on objects to determine what kind of access you have for something. Basically when you create an object, it gets the same label that the process that creates it has. Pretty simple there. If you're doing IPC, that's treated as a write operation. So if process A is going to write to process B, process A needs to have write access that process A's SMAC label has to have write access to process B's SMAC label. That's, I guess, straight out of Bell and Lopodula there. It's a write operation. It has to be some kind of operation to make it a write operation. We have a couple of other process attributes or process file attributes that we can use to clear up some of the more obvious problems. For example, we have an exact attribute that you can put on a process, on a program file, so that the process will run with that SMAC label instead of the SMAC label, the process that invoked it. Also we have a spiffy transmute attribute you can put on a directory so that files that are created in that directory will get the label of the directory rather than that of the process under certain circumstances. I'm simplifying things just a little bit here because I know that I'm just before lunch. But those are the basic things. Basically every process has a label. Every object has a label. They're used in comparison to do your checks. So SMAC implements a simple separation policy which simply says that we're going to compare the labels and under the right circumstances we're going to deny or grant access. So the basic rule is that if the labels don't match you don't get access. Pretty simple there. Isolation is easy. Sharing is hard. All the problems that we have in advanced security come from the fact that people want to share things other than the things that they're directly related to. So in addition to the basic labels, we have some special labels that I'll talk about a little bit more in a minute here that allow you to address things like DevNull where everybody should be able to write to DevNull. Everybody should be able to read from DevNull and explicit relationships can be defined. So if I decide that I want a process with the label snapped to be able to access things that are labeled POP, we can create a SMAC rule that allows that. And you can allow that read access, read write access, append access depending on how you want your policy to work and give it execute access as well. So the whole idea here is that you've got two labels, you're going to do a comparison if they're equal, great. If they're not equal, you're going to find a rule that identifies the two labels and provides you the access. And it turns out that by doing it this way, we don't have to compile a policy. There is exactly one rule that describes the access between those two labels. And that simplifies things greatly. If you want to know, for example, when I'm looking at a subject, when I'm looking at an object, will it have access? There's one rule that will tell you that. You don't have to decompile your policy. You don't have to determine what the phase of the moon is. You don't have to know what namespace you look and you can see the rule. And it's just there. I mentioned special labels. We've got a couple of special labels here. And by the way, I didn't say what a label was. A label is a text string up to 24 characters long. And they're not interpreted in any way. They're merely compared. All right, so the special labels we have, the floor label. This is the label that you put your system data at, the root of your file systems. And it's the label that processes get started at, that the init process is given unless you tell it otherwise. It has a special property in that all processes, any label has read access to the floor label. So that's how you solve the problem of how do I get at my libraries when I'm not running at the same label as the system is. Right? You have the star label. This is really good for, I don't know, because everybody needs to have access to that. And then we have the hat label. The hat label is used for things like backup. Hat label has an interesting property that if your process has the hat label, it can read anything on the system. It doesn't give it write access, but it does give it read access. And as far as the networking goes, SMAC enforces networking by network access control by default. So uses the SIPSO mechanism in order to pass in IPv4 to pass the label with the packet. So if I'm trying to send a UDP datagram from one process to another, the packet gets the label from the sending process. It goes over to the other side. Colonel pulls it out of the, pulls the label out of the packet and says, would a subject with this label be able to write to this process? If it can, it gets delivered. If it can't, it gets dropped. So that's enforced throughout the networking there. Unlabeled packets are taken care of by what we call the ambient label. So if an unlabeled packet comes in, it's going to be delivered to a process. It gets assigned the ambient label. And if a subject with the ambient label can write to that process, then it goes through. Otherwise, it gets dropped. Ambient label is specifiable. So you can set, you can specify it so that it's any value you want it to be, if you're privileged. And we also have a mechanism whereby you can say, any packet that comes from this host will be given this label. And you can only send information to that host if you have that label, or if you have right access to that label. So that takes care of almost all the situations you have where you're talking to, talking out to the world on the internet. Who's using SMAC? It actually does have users. Tizen, if you have a Samsung television or a Samsung camera, or just about any device Samsung has made over the past few years, it will have SMAC in it. Automotive-Raid Linux is using SMAC. So if you have a new Toyota, it's got SMAC in it. And the Yachto project mechanism for building Linux systems, heard it referred to as a Linux Otron, actually has good support for SMAC and SMAC policies in that build system. So what's new in SMAC these days? SMAC has actually been relatively stable over the past few years. But what is new, we've got support for overlay AFS, which was missing for a good long time. And now the privilege, if you have privilege, you can change keys. Key value used to be you couldn't change a key if your label didn't match that of the key, even if you had had the CAP-MAC admin privilege. That was actually a bit of a problem in a couple of cases, but we've got to fix in for that. There are a couple of other things coming in as well. So yeah, what's fixed recently? We had some memory leaks. They were actually fairly obscure, but got some fixes in for those recently. IPv4 over IPv6 had some issues as well. Those have been fixed. UDP light and DCCP, those changes came in. Generally, what we tend to find is that most of the problems that show up in SMAC come in when somebody fixes something else. We've had a number of cases where the INOD initialization for sockets has been optimized to the point where they weren't putting enough information in early enough and that interfered with TCP sockets getting created. But those tend to get fixed in a relatively reasonable fashion. So what do we have coming up, coming down the pike? We have some networking projects involved. The first one, we don't support Calypso yet. We'd really love to have somebody work on that. Anybody has a keen interest in becoming a network security developer. This would be a great place for somebody to start. We also have some cleanup that needs to be done in the current NetLabel implementation for SMAC. A combination of a few poor design choices early on and the fact that the NetLabel code has advanced at a higher rate than I've been able to keep up with means that there's some significant cleanup work to be done there. That may be higher on my list now than it was a year ago. We'll see about that. But that would be another area where if somebody wanted to contribute, that would be really welcome. You have a bunch of other projects as well. As namespaces have become more and more interesting in the community, SC Linux is working on namespaces. We just heard about app farmers work with namespaces. We actually had some work done with SMAC namespaces, a couple of years ago, at Samsung's kernel development group in Warsaw. Unfortunately, their use case disappeared. So, yeah, that has been abandoned. It would be really nice to pick that back up. I'd love to support InfiniBand. My home laboratory doesn't actually have an InfiniBand network. That's the kind of hardware that's kind of obscure to get. But if somebody wanted to work on that, that would be really a positive thing. Well, Libvert, EBPF, and we have a test suite under development that hasn't actually gotten corporate clearance to get out yet. Once we can get that out into the community, then we can get some more work on that. That would be a very positive thing because people frequently say, how do I make sure that my system is working right? Well, the test suite would be the right thing. Yeah, I just have to get it out to you. And probably the, oh, fiddle-dee-dee, I have a new clicker. And it's really a great clicker, but I haven't learned how to use it yet. Okay, so the biggest thing that would make my life easier and probably make the acceptance of SMAC go more swimmingly would be a rule set for distributions. So if we had a good rule set for, say, Fedora or Ubuntu, we could probably get a lot more adoption. This is not a small project. I have considered the SED script, which takes the SE Linux attributes on files and translates them into SMAC labels, which is pretty easy, and then do the same for processes, but then that would require reading the SE Linux policy and decomposing it somehow. But if somebody wanted to do that, that would be great, and that would be cool, and you could probably get a master's degree for that. Same for app armor policy, although that might be a little bit easier to deal with, or it might be a little bit harder. I'm really not sure of two minds on that. So that's about all I've got. I know that it's almost lunchtime here, so any questions? Questions? Thank you for this presentation. I'm Andre from London, working on security specialist. I have one question. Do you have a complaint mode on, like a complaint mode on APPR mode? Do you have this on SMAC? Do I have a... One way to test... Are you in permissive mode? Yes. No. I'm sorry. And that's on purpose. There are some debug facilities. You can tell the system to report anytime that an access is granted by a non-default rule. You can also specify that a single label that is going to be allowed to do anything at once. But those are strictly for debugging purposes. The problem with permissive mode, and I have seen this time and time and time and time again, is that when you give somebody permissive mode, what they do is, as the system is in development, they turn on permissive mode, they do all the development, and then three days before release, they say, okay, now we're going to switch on security, and everything falls flat on its face. And everybody throws up their hands and says, what's wrong? And they say, well, my code works just fine, but security broke it. And then there's a big meeting, and all the executives come together, and they say, well, what shall we do? And they say, well, we can ship with security with it in permissive mode. Oh, and then everything works? Yes. Oh, but we've got security enabled, right? Yes, it's enabled in permissive mode. Okay, we are good. And I know that people don't want to do that, and I know that people have plans to not have that happen next time, but guess what? Next time rolls around, and four days before the release, they turn security on, everything falls on its face, because nobody's been given time to go actually fix it. And so it ships with permissive mode again. So I know that every major user of SMAC has a patch on their own to create permissive mode. It's not hard, it's about three lines of code, but I'm not going to carry it, because I know that when people use that, it causes problems, and it always has, and it always will, and it's just inherent in the notion of having a permissive mode. It's just the way things work. Has been, always has been, always will be. Thank you. Any other questions? People are waiting for lunch. Let's thank Casey. Thank you, everybody.