Security代写：CSCE4550 Bell-LaPadula Rules

代写一个满足Bell-LaPadula安全模型的系统，实现基本的安全策略制定。

Program Description

For this project, you will implement a simple “secure” system in C++ following the Bell-LaPadula (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 subjects and objects 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 object’s value is updated.

The input to your system is a file of commands. Legal commands are of the form/syntax:

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).

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.

Be sure to deal with the possibility of errors in the instructions (i.e., neither READ nor 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 Reference Monitor described below).

Now, let’s 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 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 don’t care about labels or security. They just do what the reference monitor tells them (through simple accesses).

The main function (contained in SecureClass.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 and 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., READ or WRITE), the subject’s name, the object’s 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 when an action (i.e., READ or WRITE) is performed. 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.

To make things easier, you will limit the number of subjects and objects to those specifically identified below. The main function should perform the following tasks:

• Create six new subjects as follows:
  • adam with security level LOW
  • james with security level MEDIUM
  • tim with security level HIGH
  • sara with security level LOW
  • kristy with security level MEDIUM
  • liz with security level HIGH

The initial value of the temp variable should be 0. As an example, my code uses the function createSubject in the reference monitor to add adam with security level LOW:

refMon.createSubject("adam", LOW);

• Create six new objects as follows (that correspond to the subjects):
  • aobj with security level LOW
  • jobj with security level MEDIUM
  • tobj with security level HIGH
  • sobj with security level LOW
  • kobj with security level MEDIUM
  • lobj with security level HIGH

The initial value of each value should be 0. As an example, my code uses the function createObject in the reference monitor to add aobj with security level LOW:

refMon.createObject("aobj", LOW);

• Read successive instructions from the input file and execute them, following the Bell-LaPadula constraints on reading and writing. You should have methods 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 program’s ability to correctly execute commands and some of which will test your program’s ability to catch error conditions. With the exception of adding the six subjects and objects as described above, you should not “hard-code” any items in your system. Be sure that you thoroughly exercise your program’s capabilities on a wide range of test suites.

Requirement

• 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.