The path through which an activity occurs could be very elaborate, and not all IDSs can detect the full range of conditions. For example, you might log in under your normal user ID and run a program that opens a socket to background daemon. When you send commands to the daemon through the socket, one consequence could be that the daemon reads a file that you could not normally access and then sends data about the file to you through the socket. The OS is happy because the access control decision for the read operation succeeded because the daemon had sufficient authority to access the file. In this case, if the security policy is violated, it is because the daemon did not perform enough checking to verify that your program had the necessary privileges. Hopefully, weak security programming such as this does not exist at your site.

What would an IDS need to track to detect the policy violation? Here is a partial list of what the IDS must know about you:

•  The login event generated by you

•  The process or thread create event emitted when you ran your program

•  The socket events for your program— create, read, write, and possibly bind

For the daemon process, the IDS would need to know the following:

•  The identity of the process—its UIDs, GIDs, and other privileges

•  Socket events

•  Resource accesses, such as files created, deleted, read, or written

Knowing these two sets of events is useful but not sufficient. What else is missing? Assume for the moment that your program is the only one communicating with this daemon. How would the system know that you were somehow given access to data in a file that is normally unavailable to you? The IDS might watch for a sequence such as the following:

•  A write socket event from your program

•  A read socket event from the daemon

•  A read file event from the daemon, of which the file is one that your UID or GIDs cannot access

•  A write socket event from the daemon

•  A read socket event from the daemon

Not only would these individual events need to be monitored, but the IDS would need to somehow correlate the events into a higher abstraction such as a session. Correlating events is not difficult when they share data values. In this case, its the socket endpoints that define the relation between the event records in the audit trail or system log. Because the session is defined as the 4-tuple <source address, source port, destination address, destination port>, and your program and the daemon share these four values, events on these sockets can be clumped together logically.

Still, this sequence of events is not proof of a problem. Many background daemons and programs regularly access privileged files on your behalf without disclosing information in the files. The only way to know for sure that you were allowed to read data that you should not have access to is to monitor some lower level operations, such as the following:

1.  The daemon program reads from a file into a buffer.

2.  Your UID and GIDs do not have access to this file.

3.  The buffer is written to the socket by the daemon.

4.  You read the socket.

Aha! Now we’re getting somewhere. Here is clear proof that the daemon read some data and dumped it into the socket that you read. What happens if the buffer is manipulated by the program? Can that be tracked, too?

1.  The daemon reads from a file into a buffer.

2.  Your UID and GIDs do not have access to this file.

3.  The buffer is copied into N different smaller buffers.

4.  The secondary buffers are written to the socket by the daemon.

5.  You read the socket.

OK. This most likely can be tracked, too, but the IDS probably is getting a bit tired and frustrated. More complications are on the way:

1.  The daemon reads from a file into a buffer.

2.  Your UID and GIDs do not have access to this file.

3.  The buffer is transformed though any number of operations into N other buffers.

4.  These secondary memory buffers are further convoluted and transformed.

5.  The secondary buffers are written to the socket by the daemon.

6.  You read the socket.

Still, this seems to be something that an IDS can track. As long as a path can be found from the source buffer to the final memory storage location written to the socket, the IDS will be able to detect that data has been compromised. Before you get another cup of coffee or tea, consider a more complex scenario. The daemon’s first two steps are the same as before. Instead of transforming or copying the buffer as the next step, the daemon follows an algorithm:

1.  Grab the first byte of the buffer and store it as an integer in temporary variable X.

2.  Compute the X^th Fibonacci number and write it to the socket.

3.  Your program reads the socket and computes Fibonacci numbers until you find the same result, and now you know X.

This is really getting hard. Of course, you could have picked a more efficient algorithm. The point is that the path is getting harder to follow. The compromised data is becoming more obscured. Now instead of the path being based on memory copies and elementary transformations, all we know is that part of the buffer was used in computing some function f(x). The result of the function then was written to the buffer. There is more to consider before drawing some conclusions:

1.  Grab the first bit of the buffer and store it in temporary variable X.

2.  If X=1, write an odd number to the socket, else write an even number to the socket.

3.  Your program reads the socket and inverts the previous step.

In this case, the action the daemon took by inspecting the buffer indicates a problem, and not the fact that the buffer itself or some derivative of it was communicated to your program. This is a simple case of a covert channel. Anytime one program can leak at least one bit of information to another program, there is a threat that a read constraint will be violated. Any number of operations not related to the socket could have been performed to leak the bit of information contained in X:

•  The daemon could create a file in directory A that is readable by your program when X=1, and create a file in directory B otherwise (where B also is readable by you).

•  The daemon could write data into a file that you are allowed to read. Then the daemon reads data back from this file into a buffer. The buffer then is written to the socket for you to read. The IDS would not know, without detailed knowledge of the file’s history, whether the data sent to you was allowed or not. Note that an MLS OS will not permit this operation because it does not allow write down when the operation violates sensitivity labels.

•  If X=1, the daemon runs the /bin/true program, else it runs /bin/ls.