 Hello, I'm Casey Shelton and I'm going to be talking to you today about our efforts to implement a reference policy for the SMAC Linux Security Module. SMAC is a mandatory access control security module and it implements a mechanism called simple separation where we simply separate objects and subjects with different arbitrarily defined labels. It's an offspring of the Bell and Lopodula sensitivity, Bible integrity, and it follows very closely classic Linux security policies. Now, if we want to compare SMAC to SC Linux, what we find is that SMAC has fewer entities that it actually is concerned about. SC Linux wants to provide act controls on just about anything you might think might be considered security relevant. SMAC, on the other hand, is simply a subject and object oriented access control system. It doesn't concern itself with things that are not subjects and not objects. This gives SMAC considerably coarser granularity of specification, which tends to make the specification simpler. If, for example, you want to send a UDP packet on SMAC, you have the sending process is the subject, the receiving process is the object, and their single operation, single access check. On SC Linux, if you want to do the same operation, the sending process sends information to the socket, which sends information to the port, which sends information to the transport, sends information to the interface, and that goes back up the stack from the interface to a transport, a port, a socket, and finally to the receiving process, giving you an opportunity to make access control checks or security checks in general at each of these transitions. This is a finer granularity and it has its advantages, but it tends to be a bit more complicated to describe the transition. Now, if we want to compare SMAC to App Armor, what we find is that while SMAC is a complete system implementation, that is, all subjects are controlled by SMAC, all objects are controlled by SMAC, all accesses are controlled by SMAC. Under App Armor, an application may be given a profile to exit and how it behaves with regard to specific path names, but it's not all the objects on the system, it's not all the processes on the system, it's just the ones for which you have created profiles. Now, this has a lot of flexibility to it and has advantages, and if you're only targeting particular things, it's certainly advantageous to be able to do this. But it's a very different mindset from the all subjects and all objects mindset of SMAC. SMAC, as I mentioned, it is accesses between subjects and objects, it's not a privilege system. It does not implement any kind of notion of privilege, simply a matter of, can I do this based on the SMAC policy? Now, SMAC works in conjunction with the Linux capability model in regard to exceptions to the SMAC rules. Administering the SMAC system, for example, requires you have CAPMAC admin, which will allow you to modify the policy configuration or to set SMAC attributes on objects or subjects. CAPMAC override allows you to override the SMAC policy. So, for example, if you have CAPMAC override, you can access objects that you would not be able to otherwise. Now, SMAC is based on a simple rule-based scheme, and the basic rule is that if the labels match, you're allowed access, and if they don't, you don't. Now, there are certain cases here where we need to have exceptions to this. The system defines a set of labels that are used for explicit purposes. The first of these is the star label, which is the asterisk. Any subject can read and write to an object with the star label. Very useful for things like DevNull and DevZero. It has to be used very carefully, very judiciously. Another one is the floor label. The floor label is useful for things like the root of a file system or a system binary. All subjects have read and execute access to objects with the floor label. And, of course, if you have the matching label, you have access to that, too. Now, sometimes you want a mundane label to be able to have some other kind of access to objects with another label. For example, if you have an apple subject and you have an orange object, you can specify that the apple subject can read or execute access to the orange object, thereby allowing you to compare apples and oranges. With subject labels, we have special behaviors for some of the system-defined labels as well. A subject with the hat label is able to read any object on the system or has read access to any object on the system. Useful for things like backups, virus scanners, etc. A subject with the web label, which is an ampersand, is allowed to write to any object. Now, it turns out processes are not allowed to have the web label. This is only used in particular network configurations. Access modes are another important thing. SMAC doesn't introduce much in the way of different access modes over the standard read, write, execute, and append that are common in the Linux system. In general, these are sufficient in order to implement a very reasonable policy. Now, Linux has some access quirks. We find that, based on the file system rules, that you usually need to have read access in order to do a write operation. This has serious implications when you're writing a policy, because if you require read access and write access, then you have a different mindset than if you only require read or only require write. Packet delivery, on the other hand, is a blind write. You can write a UDP packet from one process to another and never even know the other ones there. Signal delivery, we have that as configurable under SMAC, because it can have it either a write or an append operation. If you have it a write operation, then it's the same access control as would be on a packet delivery. If you have it an append, then they're different. And if you want to have a policy that's different for sending a signal than for sending a packet, that can be very useful. And actually, the Tizen system does that. We also have an interesting situation with read locks, because you can have a file open for read and set a read lock, which is the write operation. And although that might seem harmless, it's a covert channel. You can have a side channel attack based on read locks. So we have a separate privilege, if you will, of an access mode, which is lock, and you can have a set that separately. And although read implies lock. Now, we have to be very much aware that because we have some of these access control quirks and because most applications were not written with mandatory access control in mind, that our security model is going to have trouble on occasion dealing with legacy applications, of which we have nothing but. And we need to come up with a threat model because if we don't have a threat model, well, we don't really know whether we've actually achieved anything with our access control policy. So back in the old days, back when mandatory access control was introduced, the threat model was fairly simple. It was that you had a group of people sharing a computer and these people had a variety of clearances and the information they were dealing with had a variety of different sensitivities. And it was imperative that information be segregated by a sensitivity so that users with a particular clearance couldn't see information they weren't cleared for. Today's model is a little bit different. In fact, it's very different. Today's model is we're not worried about the other person using the computer because quite frankly there isn't another person using the computer in most cases. What we're concerned about is the fact that there's this bunch of malicious software out there which is designed to go out and find information that it shouldn't have access to and provide it to some nefarious human being somewhere who's going to buy mink coats or some other items with the value they get from the information. We also have a lot of flawed programs out there, programs that were not written with security in mind, programs that can be convinced to do things that they shouldn't oughtn't. And sometimes you need a malicious program to tweak them and sometimes they're completely exploitable just by accident. And we have a bunch of people out there, devious users who are out actively to exploit the flawed programs and the malicious programs to get things for their financial gain. Sometimes we refer to these people as security researchers. Sometimes we refer to them as using other less reputable names. But the threat, the real threat that we have today is software that is capable either intentionally or by accident to get information that you don't want it to have, you don't expect it to have. So there are some complications that we have to deal with. Things like shared directories slash Etsy, which used to be where all of the configuration information was dumped. Some applications you want to have look at the information, sometimes you don't. We've evolved now, Lib has become a repository for configuration information. Some of which is shared, some of which is private to a particular service or application. We have socket-based services, which use the IP protocol security model, which is to say none. They're responsible for doing it, doing any access control they want themselves. We also have dynamic resource creation. You mount a file system, all of a sudden you have a whole lot of new objects. You unmount it, you mount it somewhere else. Same objects, different place. Somebody plugs a camera in, you have a whole new device, a whole new set of access control considerations to worry about. So when you take these things into account, we have policy that we actually have to address not only is a dynamic once up front. We have to make sure that the system is capable of modifying itself and its configuration as it goes along. So now we're going to create a reference policy. We're going to have to make some tough choices here. Because we know that there are things we're not going to be able to do and things that we're going to have to be able to do. And we're going to have to decide how we're going to go about doing things. So the first thing we're going to have to do is choose a use case. We could choose a lamp stack that would be fairly simple, but it wouldn't be very satisfactory as far as a reference policy goes. Reference policy you actually do want to be relatively complete. And since 2023 is the year of the Linux desktop, that makes a desktop a very good choice. We also have to address the fact that reference policies for App Armor and SE Linux are based on desktop systems. They're already in distributions. Desktops are in distributions readily available. So we really have a hard time saying that we're going to do something other than a Linux desktop. So we have some tooling considerations, things that we have to deal with that we're constrained by. First of all, is are we going to use system D? System D is a very powerful tool with a lot of configuration options, but it's also big and unwieldy. So we have to consider whether that's something we want to use. Do we want to use a system generator like Yachto project? Yachto project has certain advantages. It's very useful for a board support project, but it's really kind of difficult to use to do something on the order of a desktop system. And the small distros have a lot of the same problem, things like Alpine. Again, very useful, very small, lesser of a concern. But we don't have all of the advantages that we get if we try to do a full desktop system. We have a reference policy that is less useful and less extensible if we have limited ourselves, constrained ourselves too much by choosing a small distribution. So a large distribution probably does make more sense. So when we look at the big distributions that are readily available, we find that Ubuntu has some real advantages. For one thing, it's commercially supported. Another thing is it's using security module stacking, which is still in development for upstream, but which gives you the very powerful tool of being able to use the out-of-the-box configuration in addition to adding your SMAC reference implementation. Of course, it's free as in beer, which is always a good thing. And really fairly important because we want there to be as few obstacles to adoption as possible. Yes, we looked at Fedora, decided that the RID hat really just does have too much invested in SE Linux for that to really be a viable approach going forward. So on the whole, in the end, Ubuntu seemed to be a pretty clear choice. One of the things that's already been done with SMAC is the notion of a three-domain policy. A three-domain policy is actually a pretty simple notion. It's been used on Tizen, it's been used on an early version of Automated Growth Linux, and it provides a simple mechanism, a simple way to look at the security policy for the system. The three-domain model simply says you've got three kinds of information and three kinds of activities out there. You have the floor information, which is essentially static. Everybody should be able to read it. Nobody is going to be changing it much. It just kind of sits there and everybody can use it. It's safe, but it's just safe there. Then there's system information. This is the system services. The services that the system itself provides. The data that the system needs in order to maintain itself, keep itself running properly. Then there's the user data. The user data is, user might probably be a misnomer for this, but it's close enough. This is the stuff that's outside of the system control or maybe outside of the system control. It's the business logic. It's what the user types in. It's what the user cares about in particular. Now, if there is no user data on the system, you don't need to have any separation. What are you separating out? Well, we trust everything on the system, so why do we need any access control at all? You don't. So that's what's important. That's what we're protecting from everybody else and protecting everybody else from is, in fact, the user data. So we have the three domains. The floor domain, which is essentially static. The system domain, which is all the stuff you have to do in order to make the system work. Then there's the user data, the user domain, which is what the user is in control of and where we expect there to be any malicious activity going on. So when we look at our system, we're going to have to actually have some tools we use in order to actually make determinations about whether we're actually being successful with our security policy implementation. Good news is system D already supports SMAC, so we don't have to worry about how we're actually going to get SMAC running on the system. We have that, but we are going to need to have tools for analyzing our results. And SMAC doesn't have a permissive mode like SC Linux. Permissive mode lets you go off and just run the system and say, oh, that would have failed. That would have failed. Unfortunately, it doesn't actually fail them. So you can't actually tell what path it's going to take in the failure case. SMAC does, however, have a bring up mode. Bring up mode is a little bit different from permissive mode. And what bring up mode does is it reports when access succeeds because of a particular specification. We added that a little bit more in just a little bit here. System D support allows us to write off the bat, identify subjects into particular domains. So we can put system D into a domain. We're going to call that system system D. Why not? Any system service that we want to run with a different label, we can specify that. So we can set the process label on some system service to system something. And user services are already supported in system D because there's a particular service which actually runs an instance of system D for on a user's behest. So we can label that with the user label and say, great, we have a user service now. That's where all our potential emotions stuff is going to happen. And we can also say any services that we want to run as part of that, we can specify explicitly. So we're great. We have the tools. We know we have the tools to actually implement our policy. And when we do this, we're going to want to have some way to determine whether or not what we are going to try is going to work. Snack bring up mode is kind of the answer to permissive mode on SC Linux. But it's very differently oriented. Under no circumstances are you allowed to do things that the rules say you can't. However, what you can do is you can specify the bring up bring up mode and make your mark your rule with the bring up up bring up mode. And this says that when I run the system, if an access is permitted based on this rule, log it. So now I can go out and run the system. And I can look in the log and I can find that in this particular case, a process with the user label access an object with the system D label. And at wanted read access. And here's the file system and the the I know. Unfortunately, that's all available to the security module hook at that point. And here's the name of the process. Ah, so this is the user space system D. And it looked at this particular system defile. Well, I can go look, look that up by I know, find dash item and identify what object it was that is accessing. If I look in my log overall, I can then find all the things that this that this rule allowed that would not have been allowed otherwise. I can then determine what requires access and then I could determine whether or not I want that access to be permitted. And then decide what mitigation I'm going to take in order to allow that to happen. So we come up with an initial rule set that we're going to have our three domains or we're going to have the user domain. We're going to have the system system D and we're going to have the floor. Okay. And what we're going to do is we're going to do complete complete cross access, give everybody access to everybody else and turn on the bring up option. And so anytime I get access to something because of an access control rule. I can find out what object it was and then I can determine whether or not I like that. And so we run this bring up the system. Yes, set this in place. Set the system reconfiguration to set these labels and what happens. Well, we run it for a while. We look in the logs, sort them out and just determine that on an a bunch of systems straight out of the box, the system and user domains have complete rewrite access to each other. System D has read write access to the floor. The floor actually there's some system processors that get fired off outside of system D. They need read write access to the system D domain and user actually does writing to the floor domain. Oh dear. Well, that's not what we wanted. What did we want? Well, the things that we don't want are cases where when you have two domains, they either they have mutual read write access. Or that or that the more trusted has that the less trusted has more access than the the more trusted. So for example, in this case, we don't want the user domain to have write access to the floor. We don't want that. We need to figure out why why it's doing that. And the system and user domains, they're reading and writing to each other freely. Well, we really don't. It's okay if they both write to each other because they're just sending messages. They're not going to corrupt each other's data. If they have read access. Well, they're not going to corrupt each other's data either. They're just going to look at it. If the user has read write to the system, it can change the files. If the system has read write to the user, that's not such a bad thing because we trust the system more than the user. But what we really don't want to have here is we don't want the user to have read access to the system because they need to communicate in order to use services. And at this point, what we have is a service based system. So what do we need to do? Well, we go look at the logs and find out who's looking at what what objects are being accessed by the user. What is user writing to in the floor domain? Well, we find that there's some pretty simple configuration things that are going to make things a whole lot better. First off, you dev the system devices. We can change those and can change the configuration on those so that they have smack labels that are appropriate to the things we're going to use. So we can set the smack label on a device that's only used by the system. And we can set the smack label on a device that's only used by users. These are home directories need to be labeled with the user label so that when we log on the configuration logs that are all set to the right label, the same label as the user. Okay, that's pretty obvious. There's some mount options we can use on file systems to set up the directories by default in a way that makes them better useful for sharing. For example, mounting slash temp with a star label so everybody can write to it. That's pretty simple. And there's some temporary files we can specify. There's a whole temp file configuration mechanism in system D. So we can set things appropriately. So great, you know, we do this, we go through, make a first pass at some of these configuration things. And then what do we get? Well, what we find is that we've solved the user writing to floor problem. So floor is now reading from user and writing to user so that we still need to deal with that. But we still have the problem here that system and user have mutual right access. We haven't addressed that yet. Well, gosh, what's the problem there? Why is this happening? So again, we go go look at the logs and what we discover. I got a little bit ahead of myself what we've got. So when we looked at it, we found there's some some things we could do that would really make things things less complicated as far as who's accessing whom. The first one is we could break out. We if we run the the GNOME user user space window system environment as you in user. A whole lot of the accesses go away. So we'll we create a user gnome label. We'll run that that service as a user service. Eventually we'll do the same with you dev and with debus because debus is communication thing that everybody talks to and you dev is actually very, very focused on devices which not everybody else does. So these things can obviously break out. So what happens then when we break out the user? Well, we take GNOME and run it as part as a user part of the user domain instead of as part of the system. Well, what we get is no less access but a whole lot more arrows. Now this isn't really sad really that satisfactory. What is it that we've missed here? Well, again, go look at the logs. What do we find? Well, we find there there in addition to a lot of other things, there are three primary areas. Where we actually find sharing going on in on a grand scale. These three places slash run var log and var var lib apt. Well, okay, just keep what we find is that system D uses slash run as the place where it wants play everybody to communicate. Var log is another place where you've got logging going on and sharing of logs going on and apt is the application database. So if we can make it so if we could control the sharing on these three directories, we'd also have a big win. So how are we going to do that? Here's the good news smack has a notion of transmuting directories. So transmuting directory has the attribute that if the access control rule that allows access to to the directory includes the transmute mode, then an object created in that directory will get the label of the directory, not the label of the process that created. So in our example here, we have three labels writer one writer two and reader. We're going to put them in a direct transmuting directory labeled shared. Well, if writer one creates a file in that directory, it's going to say, Oh, there's a they've got the T bit here in the in the mode. So when I create the file there, it's going to be labeled shared. Same thing for writer two. So now writer one and writer two can share information in that directory that they couldn't share with each other and they don't have to be able to read each other's information at all. Except for what's in that shared directory. Now reader comes in and he's allowed to read that. We don't give him the transmute because he's not allowed to create anything in there anyway. He can now share information, read information that's shared by writer one and writer two without looking at any of their other information. And it's done in an isolated place. It's easy to track and easy to control. So we're going to do slash run. We're going to mount the file system with the transmute with the transmute option. So it's going to give it the label run. We're going to give transmute read write access to you dev user and no, and they're all going to be able to share information in slash run. Again, it's an isolated place for an isolated purpose. Yes, it's possible to put information in there that you shouldn't. But you shouldn't be using information from there that you're not explicitly looking for. You shouldn't just be be running at looking at arbitrary data and run, you know, should when you go to run, you should be going to look for specific things. That's going to solve. So that's going to solve. Now, what about VAR log? Well, user and user know, hey, they're both using this information as well. So most of the information that's in the GNOME that's provided by the GNOME service that user wants is actually in VAR log. So we're greatly reducing the amount of information that user needs out of GNOME by putting them by making VAR log transmutable and giving it the log label. The application installation database in VAR lib app is maintained by the system and the user is going to access that. Now, you could argue that we really want this to have the floor label transmitting that the floor label doesn't work because that would probably be considered a downgrade under just about anybody's definition manager X control. So you don't really want to do that. But this way we say, okay, now user can check and see, hey, do I need to update my applications and get the answer? Yes, you do. And so it can then invoke the service that's actually going to go out and get the new application, new version of the applications. So now we make those changes and we run the system, we gather up the logs, and we discover that in order to make this system work, having broken out D-Bus and Udev from System D, 22 rules are required in order to create this active three domain system. Now, that's not very many. 22 rules are really about enough. You can pretty much understand them, especially when you can go in and say, all right. So, for example, user, user doing it right about the red ones right up here over there. I can look at that and I can say, all right, user and user no. Okay, they read write execute user no my user read write execute. And I'm going to have to look at that some more. But now I can look at the look at the accesses that are actually required. I can run the system with this set of rules and actually have something that that I think makes sense. Now, okay, looking at this, this graph is kind of unpleasant. So we can look at it graphically. Well, looking at it graphically, what do we see? Well, we see that the only processes that the only processes that can write it right onto the floor are the system D processes. Okay, that's good. That's exactly what we want. In fact, if there's if there's anything that is important, that is it. We have user no user and user no. And they can write they can both write to system D. Neither of them can read from system D. So, okay, that's that's pretty good. Now D bus. We may we probably have a little bit more to do. Well, wait a minute. No, he's only reading. He's reading from people from domains to other domains are reading from him. Nobody else is writing to him. He's fine. Okay, same with you dev. People are things are getting read out of there. We look over here at user and user no. And we see they have mutual read write. Well, they're both users. So we're going to have we're going to have come look at that more. All right. So, but on the whole, we look at this when we say that looks like something that I can explain. I can explain why it is. I think that I've got six got an improved security solution here. Now we have to actually step back and remember that we have implicit access from the floor domain. Because everybody can read the floor domain. We don't have to have a rule to set that up. The good news is that we when we look at it, the dotted red dotted red arrows, we see that this really doesn't provide anything. Let's give us any any kind of security concern. The only place that might have security concern is system D being able to read and write to floor. But that's okay. That just implies that it's able to update files in their end system is the one we want doing that anyway. Okay, so that's we're okay here at this point. Now we have to bring in privilege. I say now we have to bring in privilege. Well, we've got the dashed arrows here as well as the dotted arrows here and it's starting to get to be a bit of an eye chart. And we need to be a very concerned about these. All right, because these are privileged accesses that will circumvent the SMAC policy. But now what we see here is we have a system D bus is writing to floor. We want to look into that. Maybe we don't want that to happen. We see that D bus is writing to system D. Again, we might want to system D is reading from D bus floor is reading from D bus. We'll want to look at those. Okay, so floor is also reading from user. We're not so sure about we're happy about that. Udev is writing to floor and users writing to floor using privilege. You're not sure we want we really like that we're going to have to look into that further. And Nome and user are still rewrite access. So there's some particular things we're going to need to track down on this, but still on the whole, the most important access is here. If we ignore privilege are okay. And we think we can look at the things that are being done with privilege and see what we can do about those. See what's most important. And now we bring in the shared data, of course, the that we talked about earlier on that the apt don't the apt label. That's just fine. Yeah, users reading it system D is writing to it. There's no debt flow there. The log is all shared within the user domain between user and user Nome. They both have rewrite access to it. They have rewrite access to each other anyway. And the run domain, the run label. Well, this is all D bus. This is all D bus communications. And although that's something we need to look at carefully. It isn't what we don't. We expect that that's exactly what it's supposed to do. And that's just how it's doing it. So we need to be careful about that and how you D bus is actually used. Can we declare victory? Yeah, not quite. We're pretty close. But we have to resolve things like LD dot SO dot cash, which gets updated by system D by system D processes all the time. And that changes label of system D, which means anything that wants to look at that cash has to be able to look at system D process objects. Generally, that's not necessary, but it lives in Etsy. So that's a little bit complicated. We haven't addressed IP network configuration at all. Which actually turns out to be fairly straightforward. We want to set the mount option for slash run in system D, because it doesn't do that yet. We don't need a mechanism for labeling home directories and we don't want to do what I see Linux does, which is every time it boots, checks and sees if the labels on the file system might be corrupt and relabel everything. We don't want to have to know the label of everything all the time. And we really want to reduce the use of CAPMAC override. There's just too much of that. Things we want to consider again when we look at the data, when we look at the what comes up, how did they bring up? Okay. Do we want to break out? That might actually reduce some of the share some of the rewrite ambiguity that we've been careful to try and carefully trying to avoid. A bunch of other services, modem manager, network manager, account deamon, we may break those out just because they're otherwise isolated and not in the sharing that they do with other domains is actually pretty well under control. And do we want to consolidate user and user gnome because they have mutual rewrite access anyway? Well, there's a couple of things that gnome does that user doesn't gnome is going to have some privileged accesses. So if we have privileged accesses that we want to carefully guard having that as its own domain might still make sense. And of course we have if we're going to get this into a distribution, we've got some work to do there. First off, we need to get their buy in. Second off, we need to make some enhancements to systemd. Nothing major. The patch here, patch there, some of the configuration on slash run, for example, creating an option to initialize the network labeling. Also, minor patches. Systemd configuration, there's a whole bunch of it, setting up, setting process labels to get to start services with, including the user service. Again, that's a small matter of configuration. UDF configuration, not big, but very, very important. And there's some smack user space code, library, and a couple of utilities that we really would want to have on the distribution. Again, not hard, well understood technology, just has to get done. So with that, I want to thank you. I'm Casey, CaseyHeltherCA.com. If you have any interest in participating in this effort or convincing on the effort or telling me better ways to go about doing things, I'm perfectly happy to hear about it. And hope to be working with more of you forward, working forward on this. Actually, we should never get to this slide. That's the Intel logo. Thank you very much.