 Hey folks, can you hear me? Yes. Thank you. Can everyone see the screen, the web browser I just shared? Thank you. All right, we'll get started in a minute. Y'all are in for a treat right now. All right, thanks everyone for coming. So normally this will be the recorded lecture of Thursday's lecture, but before we do that, it is time for assignment two. Yay, oh my gosh, so awesome. He hears everyone say to themselves, cool. So yeah, the first part of this assignment should be pretty simple. We're gonna continue on with grade scope. So it's grade, oh sorry, grade scope, bandit. So the next one's gonna be bandit levels five through 10. So in other words, you'll have to reach level 11, run the Weach out command to sync that up. I hope by now everyone is familiar with that process. If you're not familiar with it, please contact the assignment one, check it out, read through those instructions, and that should be good. Cool, okay, so I'm not gonna spend any time on that. That one is easy. Okay, so the second part of the assignment is a programming assignment that is going to be digging into the purpose of this assignment is it's going to get you to be thinking about how to actually implement security policies. And if you recall, we talked about a potential problem with security policies written in English is that they can maybe be ambiguous. So what you're gonna write is basically a smart house simulator. So this smart house simulator is gonna implement this security policy that's gonna be given here. And the name of your simulator is gonna be called secure underscore house. So this will be the program that you have to generate. And just like you had to do in assignment one, part four, you can do this in any language you want, as long as you submit a make file and when we run make it creates an executable called secure underscore house. Okay, so first things first, let's talk about the policy. So the policy is only users with an authorized key can enter the house. This makes sense. We talked about this when we discussed the house. To enter the house, the user must first in this order put their key into the lock and we'll see later the syntax of how this is done. But first the user puts their key into the lock, then the user turns the key in the lock and then the user attempts to enter the house. Now an important thing in here is that testing of a key is valid is done only when the lock is turned. So only when the lock is turned. We'll see later, there's no possible response from putting your key in. And of course we want our house to be able to be rekeyed which means we're gonna replace the locks in our house. So this means that the old keys are no longer usable and we're gonna replace them with new keys by the owner. But this can only be done by the owner. So only the owner is allowed to rekey the house and only if the owner is inside the house. Firefighters are special. We talked about the need for security and service personnel to enter maybe your house. So we talked about maybe a secure system. Can we get maybe emergency personnel in there? So firefighters, any firefighter can enter the house with this secret key. So you can think about the secret key as it's only known to firefighters. So there's no way to know who is a firefighter except for this. Okay, other things about the lock. This is an important thing. So the lock will always be accessed with these three steps. So you don't have to worry about any other type of steps. It will always be first inserting a key into the lock turning, I guess it's just they turn the lock not turn the key, but I guess technically if you turn the key, it's turning the lock. So turn the lock and then enter the house. So these three steps, the same three steps on here will always be accessed in this order. So it'll never be the case that a test goes first insert the key and then try to enter the house. But it's not guaranteed that the same user actually performs these three actions. So you will need to check that to make sure the policy is correct. And other commands can be issued in between insert turn and enter. As we'll see, there's other things of asking who's in the house, you need to be able to handle that. But you don't have to worry about any other things happening in there. So this is our security policy that we're going to implement. And the interface to this, so how you're actually gonna implement this, you're going to, again, this is why we had the assignment on command line parameters. We will execute your program, the very first argument to your program on the command line argument is the owner's name. So on the policy, it's specified the owner name. This is how we know what the owner's name is followed by one, two, n, any number of keys. So all the rest of the arguments on the command line are all the authorized keys for the house. Other things that help all inputs to the programs will be lowercase a through z, uppercase a through z, zero through nine underscore or dash. And everything is case sensitive. So just like everything in the class, if the case doesn't match, if you submit a file that's lowercase readme, that's not the same thing as a file that's all caps readme. So you have to make sure that that's correct. Now what your program will do is it'll be reading from standard input a series of events separated by a new line. So every line will contain an event and your program must track these events, respond appropriately while enforcing the security policy. And every input will end in a new line. And so every one of your responses must end in a new line. This means it's not the same as doing slash r slash n. So you make sure your line endings are correct. If you don't know what those are, please follow these links to learn more about that. And so it will be, so now all the different things that can happen. So he said, so it can be insert key, the username and the key that is being inserted. This means that username inserts key key into the door. The only possible response is key and then the same key that was given inserted by username. That's it. The next one, turn key username. So this is the username who turns the key that they already inserted. So this means that username turns the key in the door. Possible responses are success, username turns key key, or failure username unable to turn key. This is the only two possible responses. This makes sense because as if you check the policy, we're only checking whether the key is valid on turn. And then they can try to enter the house. So then enter house username and the username attempts to enter the house. Possible responses are access denied or access allowed. These are the only two possible responses. And then we can ask our house, our house simulator, some status updates. So we can say who's inside the house. So who's currently inside the house and the response is a comma separated list of usernames ordered by access time. So that means the earlier person in the house goes in first. So this would be username one, we'd be the very first person out of the house, then username two, and then username three, or nobody home if there's no users in the house. Chat, if the user who enters the key isn't the same user who turns the key, should it be a failure? Yes, because we, it has to be those three steps have to be in order by the user. So according to the policy, the user must first do these three steps. If anybody else tries to intervene, it should prevent that. We have a little bit of a smart lock system. Then we have the ability to change the locks. So like we said, changing the locks is the username wants to change the locks to the new keys. So again, rekeying means we get rid of the old keys, they're no longer valid and only these new keys are valid. So if a user wants to rekey the house with these new keys, again, according to the policy, this is either access denied or okay. And finally, we have the ability for users to leave the house. This isn't like the hotel California, they can leave whenever they want. So we can say leave house username and now username leaves the house. So possible responses are either okay or username not here. If any events you've received are not according to the specification. So if it's just the line leave house with no username or if it's leave house username username, then send the response code error. So just send one line error and that's all you need to do in reply. And so walking through this example, so if we run the program as follows, so we say dot slash secure underscore house, Selena foobar. So according to the spec, this means the owner of the house is named Selena and there's only one key and it's called foobar. So if it's given this input, if we say insert key, Adam key, no, the program doesn't exit on error, it just prints out error and keeps processing is the question. So insert key, Adam key. So Adam inserts a key named key. Adam tries to turn key with turn key Adam and enter house Adam. So this should say, and we'll go to the output key key inserted by Adam and failure Adam unable to turn key key. So why is Adam unable to turn the key here on the second input? Yeah, the key, it doesn't have anything to do with the owner. It's not the right key. The key's name is foobar. The key is not named key, right? So it's only about the key. It's just like a normal key, right? A normal key, it either matches or it doesn't. It's not, it doesn't know that necessarily you're the same, the owner. The owner is only about rekeying. Cool, so failure Adam unable to turn key key. And then when we tried to go in, when Adam tries to enter the house, it says access denied. Can't enter, you didn't open the door. Okay, now we have Pat. So Pat inserts a key foobar, Pat turns the key and Pat enters the house. So this should be successful. So key foobar inserted by Pat, success. Pat is able to turn the key and then access allowed Pat is able to join. And now if we say who's aside, it should say Pat. Okay, similar exact same implementation as before with these languages are installed. If you want any more, let me know. This time, oh, I added an extra plus. Yeah, it's extra plus E, okay. So there's a test script. So you can use this test script and this will save you a lot of heartache. So start here. This is if you, this is basically exactly how it's testing your test cases with the example. And one of the test case on the server is the example. So what you'll want to do is submit. So you can download this, insurance executable chmodit plus x, which we'll actually get into today in the class and dot slash test.sh. There's also a debug that will give you the output of your program that you can use in place of it. Another important thing is that your program must be able to accept arbitrarily large inputs. So don't be using fixed size buffers because you'll likely fail a test case because we're testing this. And just like part four of assignment one, you'll submit on grade scope your source code along with a make file and a read me file. Again, has to be called exactly make file and has to be called exactly read me no extensions. The make file should create your executable called secure underscore house when the program make is ran. Your read me file must be plain text and contain your name, user ID, ASU ID and a description of how your program works. Oh, Python is definitely on this list. I just didn't put it on there. People were asking about CNC plus plus so I want to be explicit but I'll add that during the recording. Cool, so get started on it now. Let's do next Wednesday before midnight. So, oh, the other important thing, I'll update this, we're gonna, well, actually I'll talk about that later. So anyways, yeah, assignment is out now. So I encourage you to get started on it after class. Don't get started on it right now. It should be up on grade scope so you can submit and that'll be great.