Selectively monitoring of 'information flow' events??

[Robert Watson]

On Sun, 20 Nov 2005, Marcin Koziej wrote:

> I'm working on intelligent intrusion detection system for 
> academic/educational purposes. The labeled objects with information flow 
> model in TrustedBSD would really be very usefull in my research.
>
> I'd like to plug into TrustedBSD framework and get records: source 
> -information flow-> destination, possibly being able to change 
> monitoring selectively by changing the labels (eg: interest level)
>
> It seems OpenBSM is not for me (It gathers information from cooperating 
> applications). Maybe I couls write a MAC policy based on 
> src/sys/security/mac_* which gathers information into a cyclic buffer 
> for userland to read from later? Meybe there is an audit function 
> already which provites this feature?
>
> Could You provide me with Your reflections on this topic and/or pointers 
> to documents/source code.

Marcin--

There are a number of ways you could collect relevant data, and it depends 
a bit on what you want to accomplish.

First -- while the OpenBSM package is a user space library, tools, etc, it 
is intended to be used with a kernel component, the TrustedBSD audit 
implementation, which can generate records regarding process behavior in a 
mandatory way.  This allows detailed tracing of system calls relating to 
security, as well as collection of audit records from higher level events 
in user space (submitted by components running with privilege, such as the 
login process).

You could also do what you suggest regarding using the MAC Framework to 
create a policy module that performs tracking as part of its operation. 
One of the "tricky" things about tracking information flow is that IPC is 
typically asynchronous: writes to one IPC object, such as a pipe, file, 
socket, etc, occur asynchronously with respect to a later read by another 
process.  You can either label and control conservatively (based on 
expressed intent when attaching to the object), or you can track the 
message itself for message-oriented communications methods, and then 
generate the event when the receive occurs, using labeling of source 
information.

In the first pass merge of audit support, the audit and MAC subsystems are 
relatively independent.  Wayne Salamon has a number of prototype changes, 
based on work done by Patrick LeBlanc, which allow MAC modules to tag 
additional label information into the audit trail, as well as modify the 
pre- and post-selection criteria so that MAC modules can be involved in 
the decision to gather audit data for various classes of events.  This is 
still experimental work, but should provide additional support for the 
kind of thing you're looking at.

So the best thing to do depends a bit on your requirements -- there's a 
lot of information available via the audit trail mechanism, but there are 
some disadvantages: you have to "work backwards" to tie together sets of 
related events, deal with the added performance cost of pushing all the 
data to disk, and so on.  A MAC module would allow you to hook the 
underlying sources of the events in the kernel, but comes with its own 
potential overheads, as well as added complexity.  One particularly useful 
thing about using a MAC module is that you could use labels to make the 
gathering of data easier, subject to labels being availabel for the IPC 
types you're interested in (for example: pipes, being stream-oriented, 
don't carry labeled data -- the pipe endpoints themselves are labeled 
though).  In the short term, using MAC, you'd need to provide your own 
data streaming mechanism for events, whereas with Audit we provide the 
complete mechanism up front.

Robert N M Watson
To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-audit" in the body of the message