Security代写:CSCE4550Bell-LaPadulaRules


代写一个满足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.

文章作者: SafePoker
版权声明: 本博客所有文章除特別声明外,均采用 CC BY 4.0 许可协议。转载请注明来源 SafePoker !
  目录