CS 587: KernelSec assignment
A little peek at the state-of-the-art :)Objective
The assignment was to write low-level KernelSec configuration for a MilSec-like system with three security levels (Public, Confidential and Secret). The security levels can be considered as security clearances for the users and labels for the objects in the system.
You've been given the configuration files for a system with just two security levels.
Configuration
This is about the changes that have to be made to the given configuration files.
Domain transitions given in the configuration files looked
< r|w, <*, Confidential>>:
switchTo(confidential-domain);Split the "r|w" into two separate privileges (as below):
< r, <*, Confidential>>:
switchTo(confidential-domain);
< w, <*, Confidential>>:
switchTo(confidential-domain);
-
Security-level of user 'kernelsec' can be set by changing the newUser rule in the milSecTemplate. To achieve this:
Delete the files in the directory milsec-config/groupset/members/milSec/.
I think there are four files for the four users in the system, viz., kernelsec, public_user, conf_user and secret_user.newUser rule:Change the newUser rule to
newUser: login1min, confidentialTag;
if you want user 'kernelsec' to be a confidential user. Change it to
newUser: login1min, publicTag;
if you want user 'kernelsec' to have just public clearance. The reason to do this would be to verify that the user is not allowed to open confidential files when having just the public clearance. If you see a message in the kernel log (that you can see using the command dmesg):
Missing privilege < w, < 1000, 34994>>
This prevents the error messages from the application (like read_12) from being printed on the screen. To fix this:
change the privilege (in the domains (or security cards))
< r, < *, root3>>
to
< r|w, < *, root3>>
The config files for the system with two security levels can be found here (note this may not be up-to-date with some of the above changes).
Testing the system with your config files
This section shows some screen-shots of some of the common tests that can be done to verify that only allowed information flows happen.
To verify security clearance for user 'kernelsec', look at the kernel logs (shown below) after you run the parser program.
Look at the entries for the Groupset 2002. This is groupset MilSec. The entry with 1001 is for the user 'kernelsec'. And 35002 is for the confidentialTag (that you set with the newUser rule).
Read confidential data:When a process run on behalf of a user with atleast confidential clearance tries to read a confidential file, a domain transition to the confidential-domain (1102 -- given in the config file) is performed by the operating system. The following screenshot shows the output of running the program and the corresponding log messages.
To verify that the writes that happen are only the allowed ones
A simple program that reads one file and writes the contents to another file (both provided as command-line args) can be found here. Instructions on transfering the program into the VM can be found here
To execute the write utility, do
read_1_write_2 k [source-file] [target-file]
To run it needs two file names. It tries to read the contents of the source-file and tries to write into the target-file.When the read and the write operations are allowed the output looks as follows:
Things to note:
- The message "Opened file with fd: 4" is to indicate that the open for write of the target-file was successful.
- The log messages indicate a domain transition needed to write to a confidential file
- Contents of the confidential file are the same as the public file (indicating a successful write operation)
When the read and the write operations are NOT allowed the output looks as follows:
Things to note:
- The message "Error opening file" is to indicate that the open for write of the target-file was denied.
- The message "Switching to domain 1102" is for the read operation on the source-file which is a confidential file.
- For the missing privilege "< w, < 0, 36001>>", the log is missing the message "Switching to domain 1102" to indicate that the operation of write to a public file was not permitted
- As you can see, the contents of the public file are unchanged.
Moving data into the VM
To move data into the VM
- outside the vm (on the host machine do "mv [downloaded-file] /tmp/kernelsec.iso" to move the downloaded file to /tmp/.
- inside the vm, mount the cdrom using "mount /cdrom"
- inside the vm,copy the data using "cp /cdrom/[filename] /root/"
[ Back to top ]