Adding Assignment 2.1 2025: Immutable-versioned files security layer #92
Conversation
JustinCappos
left a comment
JustinCappos
left a comment
There was a problem hiding this comment.
A few changes are needed...
| One critical aspect of creating a reference monitor is to ensure it cannot be bypassed and handles all cases correctly. While not a perfect way of validating your reference monitor, it is useful to create test cases to see whether your security layer will work as expected (the test cases may be turned in as part of the next assignment). | ||
|
|
||
|
|
||
| This assignment is intended to reinforce concepts of immutability, access control, and state consistency. By the end, you should understand how to design a security layer that preserves history and enforces tamper resistance. |
There was a problem hiding this comment.
Please add some context about what "immutable" means.
There was a problem hiding this comment.
added in the new version
|
|
||
| ## Specifications | ||
|
|
||
| 1. Your defense monitor should incorporate all the standard file operation methods, from opening a file, reading and writing to it, to closing it. All operations must behave identically to RepyV2 (without your security layer) except as mentioned below. |
There was a problem hiding this comment.
| 1. Your defense monitor should incorporate all the standard file operation methods, from opening a file, reading and writing to it, to closing it. All operations must behave identically to RepyV2 (without your security layer) except as mentioned below. | |
| 1. Your defense monitor should incorporate all the standard file operation methods supported in RepyV2, from opening a file, reading and writing to it, listing files, deleting files, and closing them. All operations must behave identically to RepyV2 (without your security layer) except as mentioned below. |
There was a problem hiding this comment.
added in the new version
|
|
||
| 1. Your defense monitor should incorporate all the standard file operation methods, from opening a file, reading and writing to it, to closing it. All operations must behave identically to RepyV2 (without your security layer) except as mentioned below. | ||
| 2. You can assume that no files exist when your security layer begins running the application. | ||
| 3. When a user calls `openfile(filename, True)`, if `filename` already exists, your security layer must create a new “version” of the file that can be opened. This version will be given a new version number and must begin with the contents of the latest version file as its contents. |
There was a problem hiding this comment.
explain what "version" means here.
There was a problem hiding this comment.
added in the new version
| if create: | ||
| self.VMfile = openfile(filename, True) |
There was a problem hiding this comment.
at least see if the file exists with listfiles and then create a version, etc. A little more functionality here would be useful.
| def __init__(self, filename, create): | ||
| # If a file with the same 'filename' already exists, this creates a new version 'filename.v1'. | ||
| # (Incomplete: does not handle further versions like v2, v3, etc.) | ||
| if create: |
There was a problem hiding this comment.
Added basic functionality to demonstrate version creation.
I didn’t aim to show the full versioning logic or structure here — just a minimal example.
Since the specification mentions version numbers starting from 1, I implemented a simple case (e.g., filename, filename.v1) to illustrate how it can work.
Added inline comments in the code for clarity.
2 participants
No description provided.