Elliott C. Back: In Aere Aedificare

A covert channel is a way of secretly transferring information between two policies that are forbidden from communicating. It can be done easily through page faulting, cpu utilization, or file locking. The sender process produces these events which a receiver then tries to poll. Of course, the two are unsynchronized by default so the receiver will be unable to receive with 100% accuracy–it may miss some events, or record too many. And, since the receiver cannot send a message back to the sender without a complex interlock system, it’s hard to build in reliability.

That said, here is some Java 5 code that demonstrates covert channels via file locking:

import java.io.*;
import java.util.*;
import java.nio.channels.FileChannel;
import java.nio.channels.FileLock;
import java.nio.channels.OverlappingFileLockException;

}

And here is the Sender class:

import java.io.*;
import java.nio.*;
import java.nio.channels.*;
import java.util.*;

// give up lock
lock.release();
channel.close();
} catch(Exception e){
e.printStackTrace();
}
}
}

When you execute the programs, they produce the following kind of output:

%java Receiver temp.txt 50
Quantitative Information Flow
Lecturer: Michael Clarkson

%java Sender temp.txt data.txt 50
0101000101110101011000010110111001110100
0110100101110100011000010111010001101001
0111011001100101001000000100100101101110
0110011001101111011100100110110101100001
0111010001101001011011110110111000100000
0100011001101100011011110111011100001010
0100110001100101011000110111010001110101
0111001001100101011100100011101000100000
0100110101101001011000110110100001100001
0110010101101100001000000100001101101100
01100001011100100110101101110011011011110
110111000001010

The Sender and Receiver take one step to assure that they communicate properly: before each character is sent, a block of 8 1s is transmitted. The Receiver can use these to try and delineate the blocks. This isn’t a robust approach, just a hack to try and prevent frameshift mutations!

Using the new java 1.5 Scanner class is tricky if you want it to stop reading input when it reaches a blank line. To do this, use two nested java.util.Scanner instances, one to read lines, the other to parse each line:

import java.util.*;
public class Test{
	public static void main(String [] args){
		Scanner s = new Scanner(System.in);

		while(s.hasNextLine()){
			Scanner ss = new Scanner(s.nextLine());

			if(!ss.hasNext())
				break;
				// line empty, quit

			while(ss.hasNext()){
				// handle input types
				ss.next();
			}

			ss.close();
		}

		System.err.println("Done program");
		s.close();
	}
}

That’s all there is to a complicated use of Scanner for line-by-line text tokenization!

I’m writing documentation for my compiler due later today, and I double click on it in Eclipse:

The Eclipse IDE uses OLE to dynamically include an instance of MS Word in its project space. That is cool… I am impressed!

Java 1.5 introduces this great feature long present in other languages called an enumerated constant. In theory, it lets you replace ugly java code like this:

public static final int PANCAKE = 0;
public static final int ORANGES = 0;
public static final int CEREAL = 0;
public static final int MILK = 0;

With a simple one line definition:

public enum breakfast { pancake, oranges, cereal, milk };

This is good because it improves the readability and maintability of the code. Enums are also strictly more powerful than a list of integers, as they are actually a shorthand for a class, and contain methods and fields of their own. However, transitioning to using java 1.5 is not as easy as you think. I wanted to use an enum in a switch / case statement, but was having trouble. My first incorrect try was to fully qualify the enum:

switch(visited.operator){
    case BinaryExpression.Operator.and: … break;
}

This gives the following error:

The enum constant BinaryExpression.Operator.and reference cannot be qualified in a case label

Searching for tutorials online didn’t help–the only one I could find that was truly useful was this one from InformIT. I finally discovered that it inherits the context from the type of the object in the switch() statement, and that cases can simply use unqualified names. The code now becomes:

switch (visited.operator) {
    case and: … break;
}

One you get used to them, enums in Java 1.5 are great. They really should have been there all along!