Selectively monitoring of 'information flow' events??
rwatson at FreeBSD.org
Tue Nov 22 17:09:01 GMT 2005
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.
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
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
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
More information about the trustedbsd-audit