General Mistakes and Some Hints

Missing Parts:

• Identify clearly what are objects and what are subjects.

• State how you change the sec. level of P

• The fact that a user can learn that some object or subject is at a higher level than itself is NOT a violation (as there is no way to prevent it). However, it is a violation if the value of that object can be deduced. (ssc-violation)

• Analysis of covert channels.

• If you increase the sec. level of PC, think about when you are going to decrease it.

• Think of the initial security level of the memory. If it is 0 then registers of level greater than 0 won’t be able to store values to the memory.

• Think of the conditions you have to check for each operation.

Hints:

• At a minimum, you need to capture direct information flows - e.g., you can't add R0 and R3 and place the result into R0. This is allowed in the language, but the execution must be such that it isn't detectable. This is easy enough until you get to memory and how memory is handled.

• To get you started - for those who haven't figured it out, "load 3,200" doesn't load from the previously unused location 200. This is because the program is in user-accessible memory - look to see where previous writes to memory are in relation to the program.

• You need to have level(PC) <= level(X) as there is some information flowing from PC to the variable which is being modified. For example, when X gets changed it shows that the instruction was executed and so information can flow from PC to the variable.

• Suppose level(PC)>level(x), and suppose a user's security level is equal to level(x).Then this user keeps monitoring the value of x, when he/she finds x's value is incremented by 1, he/she could decide that "x=x+1" is executed, then could decide the value of PC, which causes information leak. Even if level(PC) <= level(x),the user(whose level is equal to level(x)) could still obtain the value of PC and get relevant information. But this is allowed because level(user)=level(x)>level(PC), so it is legal for the user to learn the information and will cause no leak. If level(PC)>level(x)=level(user), then it is illegal for the user to know the value of PC, whether directly or indirectly(from x).

• The name program.txt is fixed. The name input.txt is irrelevant, as the input to the program (stuff read by input instructions) is fixed to standard input. The input comes from stdin - remember that this will be tested on a unix system. You do not need to prompt for input - if you do prompt for input, make sure it is on stderr, not stdout. The output to stdout should consist only of the final register values at the end of the program. Error output (or anything other than final value of registers) should go to stderr

• While performing a “store” operation if you check “register<=memory address”, you prevent writing down, but then the memory location’s security level can’t be changed after the first store operation on it. If you don’t do this check and just overwrite the value and security level of the memory location with the value and security level of the register, then memory locations don’t have fixed levels, but some covert channels might exist. There might be better solutions you can find, but whatever you do write down your assumptions to your project report.

• Since we have 65536 8-bit bytes of memory, each memory address consists of 16 bits. So if we have load, store or skip operations two byte argument keeps the memory address and the register code keeps the register number. In case of input, clear or negate operations the register number is kept in the register code and the two byte argument is unused. In case of add operation, the first register number is kept in the register code and the second register number is kept in the second byte of the argument(the third byte of the instruction).

One caveat: The more I think of it, the more I think it may be impossible to write a fully secure machine that executes the sample program as written. program.txt will not be one of the sample programs, so you have the option of either writing something fully secure that won't run the program exactly as written, or writing something not fully secure that will. In either case, document why - tests will distinguish between such design choices, and the fact that you recognize the choice you had to make is what really counts.