 I didn't create it, so that's fine. All right, everyone, let's get started. It's nine o'clock. Great job on the assignment. I was super stoked to look at the scoreboard and see that over 300 of you completed at least 50 of the levels. I think that's awesome, and I know that y'all learned a lot while doing that assignment, which brings me. What? How do you communicate to the outside world if you can't read an input or talk output? Yeah, so this is, so now we're going to shift text a little bit. We're going to go, our next assignment is going to be a programming assignment, because like I said, so some of the best security people are also some of the best programmers I know. And so we'll see how long this takes to update, if they're on it locally, if necessary. It's the problem with computers and caching, and one more time. I have a copy locally, why do I set this up? Okay, three parts to the second assignment. The first two are incredibly simple. The goal is just to kind of build up to the third part. The first one is just make files. So you're going to learn how to do make files. You've actually already done shell scripting. So shell scripting is very similar to make files. Make files are essentially a recipe of how you build a certain piece of software. And the reason why this is important is so that you can do part three in whatever language you want. So you can use any programming language to be the last part. So this has two parts. You're going to practice doing a C make file and a Python make file. So these are pretty easy. You've actually already done this in the first homework assignment. You created an executable Python script. Now you're just going to turn that process into a make file that will automatically do that. So the details will be on there. I don't think it's that part should be straightforward. The second part is also should be incredibly easy. Just write a program that takes in command line arguments. So when we talked about when we looked at C, right, argv are the arguments. What was the argv zero? I guess I'm already highlighting it. The command that's executed, right? And then argv one is the first argument and then there's as many as argc. So all you print out is the number of arguments that got passed in and the reverse of those strings. So all you do is start at the end, print out, separate it by spaces and that's it. So it's literally just getting you to use to reading from the command line arguments. Can you run in Java? Yes, you can use any language for this. So this is the kind of stuff that so grade scope that we're using uses Umuntu 1804 by default. So that's going to be our target. Basically, what this means is you can use and if you want something else that's not on here, like, you know, I didn't just put in mono and go because I love those languages. They were student requests. So if there's something there that you want to see on there, let me know and I can work on adding that. So, yeah, so the goal is kind of work on Ubuntu 1604. This one should be no problem. It's a very simple just reading from the command line printing back out. Oh, 1804 is supported until 2026 or something like that. So I think for this assignment, you should be fine. But in case there's the whole point is in case there's any discrepancies, it's got to work on that version. So that's why I'm telling you this because you can't tell me. Well, it works on my thing like we're using this version. So you can easily download 1804 LTS. You can spin it up. You can dev on there. You can do kind of whatever you want. If you're using like a Linux like environment, it shouldn't be very many problems at all. So that should not be the issue. OK, this is incorrect. This should be 50 points. Let's see. Do I dare edit this live? OK, I'll update it later. OK, and then the bulk of the assignment. So we've been talking about access control. You're going to be implementing essentially the access control policy that I'm specifying in text on this document. So you can think of we're creating kind of a simulator that's going to take an input of actions and it's going to output for every input what it's doing with those actions. So basically it's just like we talked about. So only users with an authorized key can enter the house. We'll talk about how that's done in a second. So to enter the house, the user must first insert the key into the lock, turn the key, and then enter the house. Testing if a key is valid is done only when the key is turned. So we'll see the output there. But if you can insert an invalid key into the lock and it's only detected as invalid when you try to turn it. For turning the key and entering the house, it must be the same user that puts the key in the lock, turns the key, and enters the house. We can rekey the house. So just like a normal house, we can say, hey, let's change the locks so we can rekey the house. And this means that old keys are no longer usable with new keys only by the owner. So the owner, as we'll see, we can request new keys. This is to make things simpler so you don't have to worry about. A lot of this stuff just simplifies things. So it's physically impossible to rekey the house when there's no key in the lock. So when I mean physically impossible, that situation will never occur. So there'll never be a rekey operation between inserting a key and turning a key or between turning a key and entering the house. That makes sense because how do you change the locks when the key is in there, right? So it's just fundamentally never going to happen. That's not a case you need to worry about or consider. There are two problems. What? Yeah, it's a numbering issue. Oops. All right, cool. There's only one lock and oh, it's only physically possible. Yeah, it's only whatever. You know what I mean? OK. There's one lock in one door. The lock will always be accessed in the following way. This is, again, another thing to simplify things. It will always be insert key, turn key, and enter house. Those three operations will always occur in that order. You'll never have an insert and then an enter. You'll never have an insert turn and enter. You'll never have a turn and enter. I think you can enumerate all possible things. So it's always those steps in that order. So that's the policy. Then the way we implement this in the interface. So part of the goal of this assignment is for you to take a specification like this and write code that actually fully implements this specification. So the command line interface. So we're taking command line arguments, which is why you have a part of your assignment on reading the command line arguments. The first argument is the owner name. It will always be present, followed by one or more keys than these are all the authorized keys for the house. Let's see. All inputs to the programs, keys and names will be A through Z lowercase, A through Z uppercase, 0 through 9 underscore and dash. So nothing fancy. You don't have to worry about spaces or anything like that. All matching is case sensitive. This is an important thing. People ask all the time, why is this not working? It's because you're not using the correct syntax here when you're checking. So the input to your program will be on standard input. Guess what? You guys love standard input. We were just talking about that before class. So you'll read from standard input a series of events separated by a new line. You're tracking these events, updating the state of the house, and responding while enforcing the security policy. Every input will end in a new line. Every response will end in a new line. Pretty simple. There we go. So your program must continue to process input until there's no input left. So we're not telling you, hey, there's 10 inputs, and then you process 10 and quit. This is what we talked about. So when you did some of the assignments that I talked about, the control D is a way to specify end of file on the command line when it's reading from your terminal input. So whatever language you're using, look at how you're reading data and say, how do I tell when there's no data left? That'll be some kind of argument here. Cool. And the commands, so the specific syntax of the commands, insert key username key. Username inserts key into the door. The response must be this. So you're just responding, yes, key, well, you don't say yes. You say key, key inserted by a username. Turn the key. The username turns the key in the door. This is where we do the access control check. So based on the policy, you have to say, do they have access or not? So it could be success or it could be failure, depending on if they have access or not. Enter house username. So username enters the house. Sposible responses are access denied or access allowed. Who's inside? We want to know who's in the house. So it's a comma separated lists of usernames ordered by access time. So again, list there is kind of a nice key. You can use a list for something like this. So you just add the people to a list. And then when you print it out, you separate it by commas. We can change the locks. So changing the locks says, hey, username, is asking to change the locks to these new values. And the possible responses are access denied. If according to policy, that person cannot change the locks. Otherwise, it's OK. And then finally, people can leave the house. They can leave, enter the house, leave. It's OK or username not here if the person's not there. And this is, again, another thing to make this easier for you. Test cases, all the test cases will be valid according to the specifications. You don't have to worry about what happens if it's not uppercase, leave house. It's leave this house or something. You can do technically whatever you want to make it easier. You can just output error. That's like a good way to handle that. But you can be assured that this case does not happen on any of the test cases. So an example, so we're running the Secure House program. Selena is the owner. The keys are foobar key 2, key 3. And so if we say insert key, add them key, it says key key inserted by Adam. If I say turn key Adam, it says failure. Adam unable to turn key key. If I say enter house Adam, it then says access denied. Why is it saying access denied? Key is not a key, right? It's only foobar key 2 and key 3. Then Pat inserts the key foobar, says it's inserted. Pat tries to turn the key. Success, Pat can turn the key. Enter the house, Pat. Access allowed. And then when we ask who's inside, it says Pat. Questions on the specification? Cool. There's questions, we can figure it out on Discord or Piazza. OK, 1804 again, this is exactly the same that's up there. This is all the stuff that's installed, like Kotlin. I actually don't even remember what Kotlin is. But I think somebody wanted PHP for some strange reason. But anyways, whatever you want, it's totally cool. So you'll use a make file. As long as your make file builds an executable file called Secure underscore house, you can use any language you want. That could be a shell script that runs things. There's all kinds of fun stuff there. To help you out, there's a test script. Yeah, so you can check this out on the website, download it. So there's a test script that runs this exact test case. So it tries compiling it. It checks that everything's available. It runs these two test cases. And if they're successful, then it tells you. You can also do test debug that shows you the output of your program. If it fails, these are just, again, to help you testing with these. Another important note, your program must be able to accept arbitrarily large input. And this is tested as one of the test cases on the website. And so to submit this on Gradescope, you'll send your source code, a make file, and a readme file. Does this mean you can submit a readme.txt? No, it must be exactly called readme with no extension. This happens every year. What was that? No, you can definitely do that. You just change the option to show extensions and then you can delete it or you can do it through the command prompt. Yeah, same thing. So a make file to build it, which is what you did in the other assignments, so that should be straightforward. Readme, so readme just say, hey, this is my name, my ASU ID, anything interesting about your program that you want us to know, happy to put that in there. Oh yeah, must be plain text. Don't make a PDF and call it a readme. This kind of stuff drives me insane. Just write a plain text file. Yeah. Good question. Good question, I have to check. It's whatever is on 18.04 by default. So it has Python 2 and Python 3, and you can use the shebang to decide to execute which one, and that should do it. I don't know which version of Python it is. If people demand a higher version, I can do that, that's not a huge problem. Cool, and we're going to use grade scope for this. So I think you should be able to just join the course. Let me know if you can't. I honestly can't remember how we did that, so let me know. You'll see all the assignments here. So the make file is split into two, C and Python, the secure this house. I mean, I can do this really quickly, but it's fairly straightforward. Sorry. OK, there we go. So I can, where's my submissions? There you go. I can resubmit. That's the wrong one. I hold down command to select multiple files, secure this house, read me make file, upload, upload, boom. And it's going to email me. Also, if I just wait here, it'll tell me. So again, just like on the poem.cse365. You know your grade right when you submit. So this will take a few, I don't know, roughly a minute, maybe 30 seconds to do everything, run the test cases. And then when it does, it tells us exactly what our grade is. So you should know exactly your grade on all parts of this assignment. Questions? Do we need comments in the code? Good question. Yeah, so here that took what? Less than a minute? And it tells me, yep, I passed a lot of test cases. That's good. You can do it too. I have faith in you. Oh, shoot. Goodbye, student question. OK, do we need comments in our code? You need comments in your code if you're borrowing code from somewhere else, right? You can throw comments in your code to explain something that's tricky. Yeah, it's up to you. I mean, we're not going to look at all of your things to comment on all of your stuff. So let's verify that this is now live. Yeah, there we go. Cool. I don't know. I'll post it on the offset. We'll figure it out. Don't worry. Should be fun. Good, that's great. You have to actually listen to me for 45 minutes in an hour instead. Yeah, it's an hour, 15 minutes. So yeah, you're going to listen to me for an hour instead of working on the assignment. This is great. All right, cool. So we got that. Now, back to access control. So somebody's asking, what's the likelihood of an esoteric language being considered strong? Just you have to send me a link to something to install it and I'll get it installed. So it's not any big deal. But yeah, don't just be like, oh, I want this and this and this and then you'd not end up using it. Or I have to then go figure out how to install this garbage software. So send me some instructions. Cool. All right, so we went over Unix access control lists. So somebody remind us, what are the set UID bit used? Set user ID? What does that mean? What does that do? It says D in wrapping as user information program. Close, very close. Not necessarily made, but the user who owns the program. So the file owner, the process when it executes, executes as if it was that owner, that user. Cool. Set group ID. So say it again. Set the program to, yes, exactly. So set the program to execute with the group ID. So the group owner of the file. So as we saw there, you see two things, the owner and the group of the file. Awesome. Sticky bit we'll ignore for now. Cool. So then we're going to rewrite execute for what's the highest grouping of the three bits, the owner, and then group, and then all. All right, perfect. So we saw that this is an implementation of an access control list. Why is it an implementation of an access control list? Say it again. Yeah, so the access, the rights are basically stored kind of with each object. Is this at the same level of expressiveness as the matrix model that we looked at? Yeah. Yeah? So how do you have a file that's only readable by 10 of the 11 users on the system? All would give it to all 11, not just 10. I'm the owner. I want to give that file to, I want to give read access to 10 of the other 11 users on the system. You're going into that. I'm saying that. So I'd have to make a group. What if I can't create groups? Yeah, I'm screwed. Why? No. Yes, this model cannot represent anything that every possible access control model that we can create in the matrix model. And it makes sense, right? We're essentially only using 12 bits, but we can't represent any possible crazy matrix using only these 12 bits. And actually, the things we're talking about, that's only the 9 bits, right? The lower 9 bits. So when we're grouping, by grouping everybody into the owner of the file, the group of the file, and everyone else, it means that we're fundamentally giving up the expressibility of this beautiful matrix model where we can specify the rights that every person has to every, every subject has to every object on the system. So yeah, this is what I meant when I was talking about expressibility earlier, right? The theoretical notion of an access control list versus a matrix model, they're the same in terms of expressibility. Anything you can express in the matrix model, you can express in an access control model. But when you actually start implementing these things, those may or may not be the same. So yeah, this is why other operating systems have different models. There's actually extensions on top of here to do different things. And it actually is a big pain to do this. You can do a lot with groups, but it becomes incredibly tricky to maintain. So yeah, anyways, I just wanted to talk about that. Exactly, so I think the core there, the crux there is maintaining this type of access control is actually incredibly difficult. Yeah, so SUID is the set user ID. That means when you execute this program, set the user ID of the process that runs from that as the owner of the file. So that means if there's a set you ID root program, then that means the program will execute as the root user, not as our user who executed it. Exactly, yeah, pseudo change, so there's actually a tons of things in your system that need to do this in order to update things. Like changing your password, C-H-P-A-S-S-W-D maybe, actually don't know what that command's called. And then set group ID is the same as set you ID with a group, so it executes the process as the group, not the user. So there's other kind of, and now we're, there's other types of kind of access control ideas that we can talk about and think about. Some of the things that may be useful is content dependent controls. So you may have access to different types of objects depending on properties of that object. So if you work in a company or corporations, often unlike ASU and public universities, salaries are very much kept private. Like it's kind of essentially in the company's interest for everyone not to know what everyone else makes. So you may have an access control policy that says, hey, you can only see salaries less than 50K. Right, so this is a policy that is dependent on the content of the object you're trying to view. Or you may say, hey, you can only see salaries of employees that relate to you, right? So as a manager, you need to know the salary of everyone in your organization. So everyone that reports to you and everyone that reports to them transitively down. But you can't just see somebody else's salary in another business area just because. So basically you can see down which people you can't see, salaries or a composure. Yes. Other ideas, context. So what do I mean by context here? What would be an example of some kind of access that depends on context? Our idea for the future. Over here. Yeah, yeah, that's good. So yeah, something that's only accessible during business hours, yeah. Say that again. Ah, so because you've run something, okay, yeah. So it's like the fact that you've given something permission, everything that descends from that kind of has the same. So it's contextually based on that. Yeah, that's good. Yeah, so other things would be, I guess I guess with FOMAS, it's kind of an older example, but a lot of companies would let you work remotely or access their systems through a VPN. But if you did that, you only had access to a limited set of information, right? So even though in the office you could access everything when you're remote, you can access very little. You can think that this helps if your laptop gets stolen, right? From the company's perspective, it's much more likely that your laptop would get stolen and somebody would access your VPN remotely rather than breaking into the company and accessing it there. Other things like salary is always a one thing. So we think about that we have right permissions to a file, but maybe we only have right permissions at the end of the year. So we can only update salary at the end of the year unless we need some other kind of process, yeah. Mm-hmm. Yeah, you could set up a system updating insurance policies or something like that, that occurred during an appointment. Yeah, that's pretty good. Location-dependent access, yeah. So changing access depending on source IP. The other thing we've talked about is companies earning reports are considered highly confidential information until it's announced at the stockholders meeting to everyone in the world, right? So the access on this is highly restricted until it's told to the world. Like, yeah, I mean, any kind of, yeah, any kind of essentially secret information that a company is eventually going to release, the access to that is contextual. You can also think of what about access control in like a hospital environment, right? You want to restrict access? Yes. Yeah, probably. You don't want everyone to have access to everything or just to be able to go into any room, but kind of until there's an emergency, right? So the problem is if there's an emergency and somebody is crashing, you don't want the access control system to get in the way of a doctor needing to get to a patient, right? So you have that extra layer of context that, hey, there's an emergency and sometimes we need to override things in order to handle this emergency and that emergency is more important than the access control policy. Similar things with buildings and the locks. There's a lot of locks on the buildings, right? But if the fire alarm is triggered, oftentimes those doors just open wide open, right? Because people, it's more important to optimize people getting out of the building than necessarily keeping people from coming in. Is that an emergency which is successful? Yes, the case, the key thing is thinking if you as an attacker could exploit such exceptional situations and cause them to happen so that you can get the access you want. All right, so when we actually talk about implementing access control systems, there's two main types of access control and that is actually incredibly important to think about and study these different systems and why they actually operate the way they are. So the type that you're most familiar with because you use it all the time, maybe without knowing it is what's known as a discretionary access control or like a DAC policy. And the discretionary here means that the owner of the object controls who can access the object, right? So when we looked at the UNIX model when we were looking at file permissions and changing things, I could change the permissions of a file because I was either the owner of the file or I was running as root and root can do anything and change anything, right? So in an discretionary access control, the owner of the object controls who can access the object and has permissions to basically set the rights to every other subject on the system. Why is this useful? Why? Seems like it'd be not useful for intellectual property. So that way, if someone's working on money for each of their boss, they can lock it down, see it, or edit it. That way, another person can't speak an idea and they can lose a lot of consciousness in their own. Except everything you do at a company is owned by the company, so including all the IP. So the company owns every IP that you generate while you're at work. So a company would actually not want you to be able to do that. They would much rather, they read everything if they so choose, right? Because they could take that and just give it to another employee. They won't if they're a good company, but fundamentally they own all of that IP. So you shouldn't be able to lock them out of anything from their perspective. Well, yeah. I'm talking about like other, like same loan code, so we're trying to get it changed. Yeah, the manager could decide to give a project to somebody else. I mean, it's, you know, there's nothing inherently that prevents them from doing that. But yeah, so being able to, so this is how we think of systems, right? We're the owner of some system. We own the data. We can change it and do whatever we want, right? When may you not want that? So we just talked about this IP thing. What are some other scenarios? Maybe even though we've talked in class that you may not want the owner of the file to be able to do whatever they want to the permissions. In the back. Ooh, can you expand on that? Yeah, so the example was a voting system. A voting system actually have incredibly complex like access control policies and access control rights. So that's like a fascinating subject in itself. But yeah, you may not want the owner just because you can say the owner of the object, right? Just because you made your vote doesn't mean that a week from now you should be able to say, oh, nobody can read this or nobody can write it or actually in the U.S. I think it's, I don't know if it's a state thing but it's usually illegal to like prove that you like take a picture of your vote to prove that you voted a certain way so that people can't, the threat model there is people paying you to vote a certain way and to be able to prove that you voted that way. So as long as you never have hard proof that you voted a certain way somebody shouldn't be able to cross you into voting a certain way that you don't want to. What about, yeah, that's a good one, Aaron, in the example. So going back to the ASU shared server example that we did at the start of this access control model, right? We talked about a home market system that actually had a discretionary access control system where somebody could make an accident to allow their file to be writable by everyone else on the system. And so we may not want them to do that, right? We may not want people to have full control. What about the nuclear launch codes? I was gonna use that. So somebody has to come up with those codes. Should they be able to decide who has ownership of them or in who can read them? Yeah, so the other basically class of thinking about these things is what's known as Mac or mandatory access control. And you can think of this, it's kind of in the name. Discretionary, the owner has discretion over who has access. We're in a mandatory access control. The system decides who has access to an object. And the system here is defined very broadly. So you can think of even the, even though the nuclear access codes are not like, what we traditionally think about is like pieces of software on a system. There is a system that controls access to those objects through rights and other types of things. The third kind, and this actually, you're probably inherently familiar with this even though you don't think about it, I guess. So when you're streaming a TV show from Netflix, you own that. Who's controlling your rights to that object? Yeah, Netflix. So, and you can think of even if you're using, I don't know, Spotify or Apple Music or whatever you're paying a subscription. You may download those music files, but just because they're on your system doesn't mean you own them and get to choose who gets to read or write them. The companies would much rather that they get to choose, right? Because they originated the data. And so the originator of the object controls who can access the object. So note the goal here would be no matter what happens to that object. If I allow other people to copy it, I can still control the dissemination of that information. Okay, mandatory access control. This actually maybe, so discretionary access control we basically talked about. It's very simple, the owner can choose. Originator based access control we're not gonna get into the details. But mandatory access control is a really cool kind of mathematical way of thinking about these policies that is super useful. And it was one of the early examples of people formalizing a type of access control and then being able to prove different types of properties about the system. So we're going to use a mandatory access control that uses different levels. Is anybody, I know we have some folks who are or were affiliated with the military can somebody refresh us with the military? Security levels are? What's the bottom most like the stuff that I can read? Not quite, they have a very specific name for it. Unclassified? Yeah, so there's, oh, thanks. Aaron in the chat, unclassified, confidential, secret and top secret. So why do we have, why are there the levels? What does that mean? Yeah, okay, so represents in some ways who can see the information as we'll see both subjects and objects are tagged with a level. So me as a subject, I am at the unclassified level which should mean that I can, oh, I didn't actually, are you guys having trouble hearing me in the back? I actually never turned on my mic which realized, no, it's fine, okay. That's weird. Okay, at the unclassified level, I should only be able to read things at the unclassified level. Should I be able to read things at the top secret level? No, I should never be able to do that, right? And the whole point of a mandatory access control is the system enforces that. So we'll look at how it does that. There's actually another access that we'll look at eventually. Amy, anything about security categories or no any categories? It is, it's slight, yeah, it's slightly, a little bit more expressive. I think of it as set and we'll look at that. You can have, yeah, exactly. So yeah, some examples, let's see. Five eyes is definitely a category, no form. I actually don't know that. Oh, no foreign nationals, yeah, that's, yeah, so this could be the idea is, and you can think about this from the basic example. If I have top secret clearance, should I have access to every single top secret clearance piece of information that exists in the military? No. No, they don't wanna restrict it. And this is again, another instance of the principle of least privilege, right? So if I just had top secret and I get access to everything top secret, well, but what if my job only requires me to do nuclear stuff? Like I'm a nuclear physicist. I work on nuclear things. Do I need access to, I don't know, the latest Five Eyes Intel on Russia or the aliens or something like that? Like no, I should only need access to stuff I need to do my job and nothing more. Yeah, so we'll get into some more examples of those and we'll look at kind of labels. So we'll build this up. So security levels are pretty, I feel like are pretty intuitive. So we have like many organizations, including the military have this hierarchical relationship where they inherently know and you maybe have this in your own life. I mean, you may have some data or some information that you're fine with everybody knowing. There's some data, some information that you share only with close friends. And then there's maybe some stuff you keep very close to your vest until like nobody except for your best friend, right? Or maybe, so in this way, like so you have, and it's again about how you determine these things, the system itself needs some way to determine this. Like what is the either risk to the organization? So we know like inherently the nuclear launch codes are maybe much more sensitive piece of information than like what does a certain general make in terms of salary, right? Those are pieces of information that the system knows about, but they don't have the same impact of security and the same sensitivity. Yeah, actually, so Louis was asking about Discord. Actually was trying to figure out the Discord like access control model, it's crazy. It's difficult. Like I don't, I actually somebody suggested that would be a good homework assignment for you. Like create a Discord and set it up in this access control policy such that like I can't hack it or somebody else can't hack it. And I think it'd be difficult. Yeah, exactly. So people are mentioning if you've ever tried to understand them, it's difficult. So yeah, we know like different files, different objects have different importance. And so if we can categorize them into some sort of hierarchy, that will help us. And so like we talked about, so we need to wait. So basically our system is gonna need a way to tag data on. So now we're kind of, we get focused on computers. We'll think about it at all types of levels. So we need a way to associate a security level with each entity, right? Just like we had kind of, you can think of access control lists where the access rights, you can think of our system would store with each piece of information. Is this classified, unclassified? Is this unclassified, classified? What did we say? Somebody said it was confidential. Is it confidential or classified? Unclassified, confidential, secret, top secret. Confidential is second? Okay, thanks. So we need a way to do that. So what type of relationship is this? So this is a one-to-one relationship where every object has one unique label. That would be one-to-one. Is it one-to-many where every object could have many labels? Or is it the other way where many labels can be applied to one, just one object? Or is that right? Yeah, for the security levels, one-to-one in the sense that every object in the system has one security level. And it's not a unique security level. You're gonna share security levels. Cool. So examples in the commercial space, which we didn't talk about, their highest level would be like restricted, proprietary, sensitive and public. So, and you can see that things move between them, right? Just like we talked about for a company. So the company's earning reports would be probably the proprietary or restricted. And then as the day war's on, or as the, when they release their results, that would then get de-clack, like translated into the public sphere. If the military, just like we talked about, oh yes, perfect. So look at, people in chat, very good. So top secret, secret, confidential, unclassified. So those are kind of the four levels there. There's other weird levels that aren't really talked about so much. I know Kui is, so controlled, unclassified information. So it's information that is unclassified, but they don't want it to be, have like a broad release. But yeah, these are the kind of four that we're gonna deal with. So now we're designing the system. We need some sort of policy. So we're gonna simplify things down into this model where we just have two operations, read and write. And we'll use the military example. So we have top secret, secret, confidential, and unclassified. And because we're gonna do things in a little bit of a formal notation, again, this is not anything scary. It's a pretty simple notation. So we're gonna define, let's say just like a function L, you think of it as a function L? L takes in a subject and it returns the security clearance of subject S, so LS. So if I say, okay, so this means every subject has a security label that we can basically think of query with this function. The other thing that always helps, I don't know if I mentioned this one, dealing with mathematical functions. For me, as more of a programmer than a mathematician, I always think of it as what are the types of this function, right? So in this case, this function L takes in a type subjects and returns type labels. So if I was giving like a type signature to this, that's what I think about it. So it takes in subjects and returns their security label. And then we can do a similar thing with O. So we'll overload the function L in programming terms. And now this is a function that takes in an object and returns the level of that object. So the type takes in an object, returns the level. And then all this says is we have an ordering of levels. So this just means, hey, we can order the levels, right? Which makes sense. We had that notion, we had unclassified is the lowest. You can think of that as zero. We had confidential one, secret two, and top secret three. But the exact numbers aren't important, right? The only important thing is that we can say, hey, this level is less than this other level, right? So would unclassified be less than top secret? Yes, would top secret be less than secret? Is top secret less than secret? No, because it's higher up. Is top secret less than top secret? No, is it less than or equal? Yes, okay, slight trick. Cool. Now, let's derive before we get into this. I'm sorry, can you go back up there? I can, yep. What's up? What's our security property? So it's almost like we discussed it already, right? So we already kind of said, I mean, I even said just talking about this, right? What do these levels mean? Well, if a subject is at a certain level, like I'm at unclassified, what type of information should I be able to read? Yeah, so I should be able to, so if I'm a subject and I have a security level, so L of my S is the level of S and I'm trying to read some object. So we get the security level of that object. What must be true about the relationship between the security level between the subject and the object? Yeah, the security level of the object must be less than or equal to my own. So the other way I like to think about these is in terms of, I think of it as this like vertical level. So with top secret at the top, then secret, then confidential, then unclassified. So I think of it as read down. You can read anything at your level and read down, right? We can kind of walk through some examples. If you have top secret clearance, should you be able to read unclassified documents? Yeah, if you have top secret clearance, should be able to read secret documents? Mm-hmm. Yeah, we'll get there in a second. So we'll build up to there, yeah. We're just talking about labels right now. So yeah, we'll form the rules for labels, we'll add categories and see how that changes things. Great. Okay, so we have this already. So basically a subject S can read an object O if and only if the level of that object is less than or equal to the level of the subject. What about writing? And before we talk about that, what's the fundamental security property we're trying to achieve here, right? The whole point of mandatory access control is the system can enforce security policies. So what's the policy we want to achieve? So what's our security property we're trying? So with this one, we're saying, okay, you can only read things at your level or lower, but we didn't really get into why. Why is that like, what's our overriding property? It's not a formal thing. What's the high level goal we're trying to achieve here? Yeah, we wanna, so maybe another way if I can rephrase that. So we wanna prevent people who don't have access to the information from accessing it, right? So I think another way to phrase that is we don't want information that is at a high level to be read by somebody or to be accessed by somebody at a lower level, right? So essentially we wanna make sure that top secret information stays available only to the people in top secret. Does this satisfy that property? What about writing? Again, we said there's only gonna be two operations in our system, reading and writing. So we have a rule for how to do reading. Does that violate our property? Yes. How does that leak private information to a lower level? Those are two different properties, right? Reading and writing are two separate properties. Reading is always done by this. Writing is done separately. Yeah, interesting. I think what we're gonna talk about can be done that way but I think it can be easier thinking about it in terms of these rules. Like rather than the system deciding if somebody tries to write to an object that has a certain security level and the goal here is do we allow it or deny it? Yeah, sure. So does that satisfy our property? Yeah. The new information after we classified top secret to read a top secret file, it was classified by subway for that file. Okay, so how does that impact our ability to write files? We can write to it better. Okay, so let's, we're taking the humans out. We're building a system that just either implements things. We're abstracting this problem up into like this, this theoretical domain where we don't necessarily have humans but we still want to maintain that property. So let's think about it this way. We can go through some examples. So I have top secret clearance. Should I be able to write a top secret file? Does that violate the property? Can I put any information in that file that somebody who doesn't have top secret clearance can read the violation? Okay. What about I'm unclassified. Can I write an unclassified file? Okay. If I'm unclassified, could I write a confidential file? Does that violate our property, our principle that we're trying? Does, does me having unclassified access, me writing a secret or whatever higher level file, does that violate the principle that that data that secret data or whatever has leaked out to somebody without access? Can I leak the nuclear codes? No, because I don't know them in the first place. I can't possibly create information that contains that. What about if I have top secret clearance? Should I be able to write a unclassified file? Can that allow our security property to be violated? Could I read the nuclear codes and then write them out to a unclassified file? Potentially I could. And that's the whole point, right? The system needs to prevent and make it impossible for those situations to even occur. Just like we talked about at the start with that shared homework server, right? That shared homework server, you guys actually came to that point yourselves like, hey, it's actually the administrator's fault. They shouldn't allow this to even be possible. And that's what we're trying to do here. Create a model where it is fundamentally impossible to leak the nuclear code secrets, the same level or what? Or higher, yeah. So it's a little counterintuitive. I think we just got there as a group. This is called the star property. Basically it means that we can write to objects that are at our level or up. And you can see right away, and this is probably why many people have trouble thinking about this because we did go from this military context that has very well defined. Basically if you had this, nobody with top secret clearance could ever write anything. But looking at it as a fundamental model, if you wanna guarantee this principle that you never leak secrets, which again, and this goes back to the CIA triad, in this model, the thing that we care about is confidentiality. We don't care about integrity. We don't care about availability. The only thing it cares about is confidentiality and keeping that information confidential. And so these two security properties, you can actually prove that information once it's marked as top secret can't leak out. So once the nuclear codes are created, they're marked top secret, nobody can leak them out. Yeah, you need other mechanisms to make this real and usable in the real world. But fundamentally thinking about it as a model, these are the two properties that helps us. And so the way I think about this and the way that helps me, I've never remembered those formulas. Like I just, I show them to you there and they leave my brain forever. But I just think about it like this. So you can read down, right? You can read at your area of your top secret, you can read at your area or down and you can write it at your area or right up. So read down, write up. And if you enforce this, then you're guaranteed that your top secret information will never leak, which is the cool part about this model. Now, of course, like we talked about, leakage is possible, right? So, you know, people are human. Like we can't fully control every aspect of humans. Unless we put a different brain for something, right? So we fundamentally can't do this. And so we need things like, hey, can we declassify information, right? So do we have a process for taking information that was at a classified level, declassifying it over time because it's now not as sensitive. Because otherwise you can see like the more information that gets in here just always stays in the system and never goes out. Like you also need a way for like, you know, people with top secret clearance to do their jobs, right? Go about their daily lives. If I remember correctly, from talking to some students who've worked in some installations like this, the, if you're on a like secure computer system, I think there's like the screen shows different or there's a red border or something, like there's physical and visual differences to let you know, hey, you're not on the unclassified network. You're now on like a confidential or secret or top secret system. But like we said, this is an overly broad mechanism. Yeah, yeah. So the key thing to think about is does that violate our security properties, right? So somebody with unclassified information fundamentally does not know any top secret or other information, right? Based on our other property. So there's no way that the only information they have access to is unclassified. So anything in that document that they write even though it's marked as top secret or whatever, the only information contained within there must be from unclassified. And so therefore you didn't lose, there's no way information leaks out that way. Now it gets tricky. What if you have a spy that is like technically confidential but is doing information that you then later classify as a higher clearance level? So in the real world, it gets trickier, right? But fundamentally from just a model perspective, writing up is actually not a problem at all. Cool, okay. So the problem also is that these are two core screen. So we need some other notion, again, to kind of restrict it to only the information you need access to. And that's where we have security categories. So they're usually like three letter codes. An interesting thing to think about is the, this is like, is the name of the thing itself classified or unclassified? Like if you're at a certain level and you get access to a document, like I don't know if you can read that document or not. So there's, if I remember correctly, there's like a cover page that says the exact classification level and categories of that document before. And that I believe should be at a lower classification level. So you can actually read it and understand if you can read the rest of the document. Yep, exactly. Yeah, so that's why I mean, you could go look up these categories. So nuclear is one. And the header and footer of each page as well to either remind you or to realize when something happened. NATO ACE I believe is some missile program. And the general kind of principle here is similar to least privilege. It's kind of a need to know basis for assigning categories to subjects. So now we will upgrade. So now rather than just having a level, each subject, go back. Yeah. This is like, yeah. The idea here is now instead of just having a security level, every subject and every object will have both a level and a set of categories. And again, with sets, sets can be empty. There's nothing in them. We can have all elements in the set. So this then raises the question of, so now for every subject and every object has both a level and a category. So now how do we compare subject S1 with object S1? So first thing we should think about since we're extending our previous model, do we need to change anything about the previous rules? Do we need to change that for the security levels? Do we need to change anything about that we're doing with levels? No, we're extending the system which means we still wanna enforce the old policy, right? We wanna make sure. And again, this makes sense. Our whole goal was to limit access to information so that the nuclear codes can never be leaked out. Now what we wanna do is make sure that nuclear codes that are tagged nuke are only read by people with nuke, with the nuke category. So we always compare the levels the same. That's the very first thing we do, compare the levels, right? We wanna double check the levels. The previous models, level, access always holds. So read down right up. How do we compare categories? So if I have the set containing nuke, and let's say the levels are already satisfied so we can ignore that. So I have the set containing nuke. I'm trying to read this document that's at my level that is containing that its category is the set containing nuke. Can I read that document? Yeah, I should be able to read that, right? I have nuclear access. I should be able to read that document. What if that document is nuke and NATO? So there's two elements in the set. I would need NATO as well because I don't have rights to that NATO information. So I should never be able to read anything about the NATO stuff. I should only be able to read things that have to do with nukes, right? Okay, cool. And it's pretty obvious if I had NATO and the document was nuke, I should not be able to read that, right? Yeah, you would have to have both to read it. Yeah, so that's the other thing to think about. If I had NATO and nuke, could I read a document that was just nuke? Yes. Yes, because that doesn't give me access to any additional information. Okay, what about writing? So I have nuclear access. Let's say top secret. Should I be able to make a top secret document that has no categories? Yes, so I should be able to leak the nuclear codes to anybody who doesn't have nuke. Still top secret. Well, I should, I'm sorry. Okay, both top secret, right? The security levels are the same. I have nuclear access. Should I be able to write to a document that has no classification, no categories? So empty set. No, because that could leak the nuclear codes to somebody who does not have my category. Similarly, I shouldn't be able to write to a document that has NATO, just NATO, because that could leak the nuclear codes to just somebody who has NATO. And let's see, I can't leak the document to some, I can't write to a document that has nuclear and NATO. Is that true? No, I think that's okay. Yeah, I should be able to write to nuclear and NATO because anybody who reads that document must have nuke. So it's not like it's not, oh, no, no, no. Yeah, okay, so they must have nuclear and NATO, which means any document they write must be at least nuclear and NATO, which means that they can't just write a document that has nuke, I guess that's a good example. So if I have access to nuclear and NATO information, you can think about all that information. I can't create a document that's just nuclear. Because then I could put NATO stuff in there. And I can't make a document that's just NATO because I could put nuclear stuff in there. And so what we're getting at here is, we can actually create a lattice. So the operator we're actually gonna use is a subset or subset or equal to. And so that can form a lattice, right? The bottom, there's the empty set. And above that is all of the one elements of the set, nuclear, NATO, ACE. Above that is a nuclear, NATO, nuclear, ACE, NATO, ACE, and above that, nuclear, NATO, and ACE. So what you could do, so this now, you can think about the access control decisions that we made previously was just on one line. So read down right up. Here we could read down right up only if, so this is a subset of relationship, right? The error like the line here means the empty set is a subset of the secondhand ACE. The secondhand NATO and ACE, ACE is a subset of the secondhand NATO and ACE, and it's transitive, right? So the empty set is a subset of the secondhand NATO and ACE. So we should be able to essentially hear read down, right? So if I have nuclear and ACE, I should be able to read anything that's transitively. So this now, I should be able to read any document that's a security levels match at nuclear or ACE. Also I can read documents that don't have any category, but I can't read documents that have NATO, right? Because NATO is not a subset of the secondhand nuclear and ACE, and similar with writing. So writing, I can write up directly up. So I have no categories, right? Just like before, I can create a document that has nuclear, NATO and ACE, and just write everything I want to it. But because I don't have access to that information, there's no way I'm leaking any information because I don't have access to anything in there. I can't even read the document I just created. So similarly, if I have ACE, I can write up to a document NATO, ACE, but I can't write up to a document that is nuclear and NATO, why not? Yeah, but what's the property that's like, what could I do that this is preventing me from doing? Yes, because I can leak ACE information to somebody who has nuclear and NATO, exactly. Cool. So then we can just extend our rules. And this is one of the most famous access control models is Bella Padula. They came up with this formalization, they proved things. And so what we use is this notion of dominates. So we have a security level. If L prime is less than or equal to L and C prime is a subset or equal to C, we're just kind of merging these models together. So the simple security condition is what we said. So we can breathe an object if we're at a higher level or lower and higher here is defined in terms of less than or equal to with the levels and subset relationship. And the star property is that we can write up so we can write to an object if it's at our level or higher is all this says. It's just that at our level now has to take into account that matrix, but that matrix is just using less than a subset or equal to. Cool. So, all right, the slides are online. You're good, trust me. All right. So A has top secret and ACE. B has secret NATO ACE. Can A read a document that is top secret and empty set? So did the security levels pass? Is it a read down? So I have top secret. The document that's top secret, I can read it, is so I have ACE, am I getting access to any information that is greater than my security level outside of ACE? No, because it's the empty set. It has no classification. If it doesn't have any classification, it means it can be read by anyone at that security level. What about write? Can I write to something as secret and ACE? Why not? I'm leaking out information at the top secret level to people with secret. Can I read something with top secret and NATO ACE? Why not? Because I don't have NATO. I'm trying to get access to information. But can I write to a document that is top secret NATO, ACE and NATO? Why can't I do that? I don't have NATO access. Yeah, so I can write to more security categories. I can't ever write to less. All right, can be right to something that's secret and NATO? Why not? Yes, because you could leak ACE information to this document to people who only have access to NATO. Can be read top secret NATO, ACE? No, because be only as secret, not top secret. I would have to say could be read a document that's secret, but is tagged the Nuke, ACE and NATO, ACE and Nuke? No, because they're trying to access some nuclear information that they're not classified to access. Finally, can they write to an unclassified document that has no categories? Oh, definitely not. Right, that'd be leaking secret information. Look at that. You know how many of these formulas you got this? Cool, other types of access control policies that you'll kind of encounter, role-based access controller. Our back is a huge one. This is actually a very natural way of doing access control. And even when we, before we even started access control, we were talking about that, right? In the shared homework assignment system, the role of a person determined their rights. So the fact that somebody is a teacher or a professor in a class, that means they have different rights than a TA, than a student, which is very nice because then as a, I don't have to assign each of you your individual access control rights. I could just say all students get this. So it's thinking about things in roles. So it's determined by their role in the organization. Rather than DAC is identity or basically clearance level in Mac. Another cool thing here is attribute-based access control. This is kind of a more modern thing. Users have attributes. So subjects and objects have attributes like age, ID number, group membership. And you can prove, so the policy is now a complex Boolean expression of the attributes that says like, so for instance, you may want to, maybe you get a deal somewhere by a proof showing that you're an ASU student, right? So I think, is this Chipotle still do this? If you show a student ID, you get like a free drink. Oh, you guys popped up real quick. Maybe this is only something for when I was in college. Anyways, but to do that, I have to show them my ASU ID, which shows that I'm a, you're a student, but also has your ASU student ID. Do they want your student ID? No, all they want is to verify that you are a student. So the only property of you they want to verify is that you are a student. So cool things about attribute-based access controls, they can use cryptography to prove that, hey, or if you think going to a bar, right? Wow, way more of you, your head stopped up. You show ID at the door to prove that you're 21 and older. What else is on your ID or your driver's license? What was that? Your address? Your date of birth? Your height, weight, right? These are not things related to your age, right? The only property they're trying to verify is are you 21 or over? They don't want to know your address. So this is kind of a, could you prove to, maybe not the bouncer, but somebody else, just using one property and not having to show a bunch of information. And there's all kinds of cool research into access control about federation is one thing. So like how does ASU who has a way to prove your identity be able to share that with somebody else? If you ever use login with Facebook or login with Google or login with Apple or any of these things, these are all ways that you are authenticating and proving your identity to one system. And then it tells the other system, hey, trust this person, they are who they say they are. But how do you manage those things is super interesting. Awesome. And, oh yeah. So just like what we talked about, usability is always an interesting thing. How flexible are the access control policies and how expressive? And with that, we are at the end of access control. So good job, everyone.