PROGRAM DESCRIPTION: For this project, you will implement a simple secure system in C++ following the BellLaPadula (BLP) security rules simple security and the *-property in addition to following strong tranquility. Your system will have subjects and objects. Each object has a name and an integer value (initially 0) while each subject has a name and an integer variable called temp that records the value it most recently read (also initially 0). You will implement a Subject as a class as well as an Object as a class. Subjects can perform READ and WRITE operations on objects. For a READ, the subject reads the current value of the object and saves that value into its temp variable (a subsequent READ will smash, or change, it). When a subject does a WRITE, the objects value is updated.

The input to your system is a file of commands. Legal commands are of the form/syntax: ADDSUB subject_name security_level ADDOBJ object_name security_level READ subject_name object_name WRITE subject_name object_name value

The subject and object names are strings while the value is an integer (also, the temp variable is an integer). Except for requiring a valid syntax, ADDSUB and ADDOBJ are not subject to the security rules (i.e., any syntactically valid ADDSUB and ADDOBJ should be passed to the reference monitor to add the subject and object, respectively. You will read successive lines from the file and parse each into an instruction object (perhaps a struct or a class). Commands are not case-sensitive (even subject and object names). Arbitrary whitespace is allowed in commands, though you may assume that each command is on one line. You must perform error checking for any file operations.

Be sure to deal with the possibility of errors in the instructions (i.e., neither ADDSUB, ADDOBJ, READ, or WRITE, wrong number/type of arguments, etc.). For syntactically illegal instructions, you will indicate that it is a Bad Instruction and print out the illegal command (but you will not pass it to the ReferenceMonitor described below). Now, lets add security to our system. Start by giving both subjects and objects associated security labels (i.e., levels). These labels are maintained by a ReferenceMonitor class object and cannot be changed after they are created (i.e., they have strong tranquility). Essentially, the reference monitor will manage the two mappings from the subject and object names to their security labels. In the secure system, whenever a subject requests to perform a syntactically legal action (i.e., READ or WRITE), the parsed instruction object is submitted to the reference monitor, which decides whether to perform the action or not based on the BLP properties (i.e., the simple security and the *-property). If the instruction is both syntactically legal and is allowed by the BLP rules, the reference monitor indicates that access is granted and then calls the applicable CSCE 4550 Introduction to Computer Security Fall 2018 2 objects (i.e., the Subject object and/or Object object) to perform the appropriate action. Otherwise, the reference monitor indicates that access is denied and prints the instruction object, but no objects are accessed. In the secure system, we also extend the notion of when an instruction is syntactically illegal in such that an instruction that references a subject or object that does not exist is a bad instruction (though this can be passed to the reference monitor).

All subject and object accesses MUST go through the reference monitor. If the subject is performing a READ, it then stores this value (from the object) to its temp variable. Think of the reference monitor as a firewall around the subjects and objects. The subjects and objects themselves dont care about labels or security. They just do what the reference monitor tells them (through simple accesses). The main function (contained in BLPSecure.cpp) manages the reference monitor and also serves as the command interpreter. It reads successive instructions from the instruction list, parses them, and submits syntactically legal commands to the reference monitor. Your task is to implement this secure system, subject to the following constraints: The SecurityLevel should be defined as LOW, MEDIUM, and HIGH with a dominates relation. You may assume that levels are linearly ordered. That is, it is a total order so you do not need to worry about categories. When you parse a command from the input file, for any syntactically legal command you will create an instruction object with fields representing the instruction type (i.e., ADDSUB, ADDOBJ, READ or WRITE), the subjects name, the objects name, and value, if any. It is this instruction object that you pass to the ReferenceMonitor. For an ill-formed instruction, you can simply indicate that it is a bad instruction and print out the command. To see how your system is behaving, you will write a printState method in the ReferenceMonitor class that prints out the names and current values of all the subjects and objects after every ten actions (i.e., ADDSUB, ADDOBJ, READ, WRITE, or bad instruction) are processed and at the end, once all instructions have been processed. Note, however, that this kind of information is not something that typically a secure system would do, but it is being asked for here in the context of the assignment. The main function should perform the following tasks: Read successive instructions from the input file and execute them, following the BellLaPadula constraints on reading and writing. You should have methods addSubject, addObject, executeRead and executeWrite within your ReferenceMonitor class that check access requests and perform the appropriate action (if any) on the state, following the instruction semantics outlined above. To ensure that your C++ code is compiled correctly, you will need to create a simple Makefile. This allows our scripts to just run make to compile your code with the right libraries and flags. Your program will be tested using a suite of 3 5 input files on the CSE machines, some of which will exercise your programs ability to correctly execute commands and some of which will test your programs ability to catch error conditions. You should not hard-code any items in your system. Be sure that you thoroughly exercise your programs capabilities on a wide range of test suites.

REQUIREMENTS: Your code should be well documented in terms of comments. For example, good comments in general consist of a header (with your name, course section, date, and a brief description), comments for each variable, and commented blocks of code. Your program will be graded largely on whether it works correctly on the CSE machines (e.g., cse01, cse02, , cse06), so you should make sure that your program compiles and runs on a CSE machine. Please pay attention to the SAMPLE OUTPUT for how this program is expected to work. If you have any questions about this, please contact your instructor, TA, or IA assigned to this course to ensure you understand these directions. This is an individual programming assignment that must be the sole work of the individual student. Any instance of academic dishonesty will result in a grade of F for the course, along with a report filed into the Academic Integrity Database.

I need help gettinng it started and outlined mostly...and it's sude Monday and midnight >.< sorry .Any help would be appreciated!