Auditing - Snare, LAuS, SELinux

[Thomas Biege]

On Wed, 1 Sep 2004, Peter Martuccelli wrote:

> Hello,

Hello.


> We have some new people to the list, welcome.  The latest post follows,
> I have added my comments to Leigh's summary at the end.
> > > I'm very much in favor of binary formats, actually. printf formatting
> > > wastes a lot of time and space on stuff that nobody's ever going to look
> > > at anyway, except using a toolset.

I prefer binary format too because the semantic of data can easily and 
clearly be gained by using structures. This helps developing host-based
IDSs. The reason for the lack of HIDS on Linux is a missing syscall 
auditing and audit trail mechanism.

But it is just a technical detail not worth discussing about. :) Just 
add a switch (or a post-processing tool) and let the admin decide.


> > Binary records (ie: Stored as binary on disk, rather than as a
> > transition format between kernel and daemon) can be a real problem -
> > we've run into the following examples:
> > 
> > * Trying to conduct forensics investigations on another machine is very
> > difficult:
> >  - UID mappings are often different, so UID '123' on one machine,
> > translates to an entirely different user on another. Converting to text
> > format on the host machine at daemon write-time solves this problem.
> > This same problem exists on windows, with SID mappings.
> >  - Even if analysed later on the same machine, user 123 may have been
> > deleted.

This happens even in text-format.. there will be always a race between 
syscall generation and meaning of audit tokens like IDs, filenames, 
sockets, whatever.


> >  - Trying to view a Windows binary eventlog on a machine that it was not
> > generated on can cause massive problems - the "string conversion DLL's"
> > that exist on one machine (eg: exchange server) to translate event
> > strings to text format, may not be installed on another machine, so
> > windows reports garbage.

This is a technical problem of Windows. :)


> > * Disk forensics are more difficult
> >  - There have been situations where a system (including audit log) has
> > been utterly trashed. dd if=/dev/hda | strings (or slightly more
> > targetted tools) can provide some potential audit strings of interest if
> > you can kill the system quickly enough before the attacker does too much
> > overwriting. Pulling out binary data is a little harder when you don't
> > have inodes to work with.

Such a setup is even prone to more errors resulting in problems while 
doing post-mortem analysis.

If someone has root to trash the hdd he is even able to delete log entries 
no matter of the format. (btw: text, binary, it's all data. so just 
using the right tools to grep can help...)

In an ideal setup logs are signed, encrypted, and sent away over a 
dedicated secure network to a secure log host on-the-fly.
Keeping the logs only on the disc of an exposed machine is... stupid. :)


> > Ok, In summary, it sounds like we:
> > * Want to make audit independent of SELinux - even the file-audit
> > settings
> This seems to be a popular request.  Do people prefer we start with
> replicating the SELinux functionality and making a clean separation
> between the two, or using SELinux as a base and adding audit specfic
> extensions?

A clear separation avoids complexity. Adding SELinux to a customized
kernel seems not to be easily done. Bloating SELinux up more makes the 
task even harder and may result in a bad acceptance of SELinux as well
as auditing in the community.
Additionally people will have the freedom of choice.

 
> > * Want to make it easy for the selinux guys (or any other module
> > provider) to inject audit log data 'through' the audit subsystem.
> > * Go with a binary format between kernel and daemon, but ensure that the
> > logs are written in text format.
> I suggest that we preserve the text interface for SELinux, making the
> binary format an option.  LAuS stored the audit records in binary format
> which required audit specific tools, augrep, aucat, to analyze the data.
> Did 'aucat -F' ever get fixed? ccb? Thomas? :-)

Hey, "-F" is an undocumented option (not in aucat.1). ;-)


> I agree with writing the records in text format.
> > * Meet CAPP requirements where possible (eg: halt-on-audit-fail), but
> > provide a reasonable fallback position for real-world use.
> I am working through the CAPP requirements to see if we have any issues
> that need to be resolved with the current implementation.  If anyone
> knows of any issues where audit does not meet CAPP requirements please
> post them to the list.  I will follow up with my list when completed.
> > * Try and implement filtering in-kernel for items such as filename,
> > using wildcards where appropriate.
> Do we try to resue the LAuS filtering code? Olaf?
> > * Use Rik's code as a base, try and integrate Olaf's stuff (particularly
> > for certification reasons), and use a sprinkling of Snare concepts.
> 
> Agreed.

Enhancing Rik's framework with LAuS code is really the best choice in my 
opinion.



Bye,
     Thomas
-- 
 Thomas Biege <thomas at suse.de>, SUSE LINUX AG, Security Support & Auditing
-- 
  Anyone who considers arithmetical methods of producing
  random numbers is, of course, in a state of sin.
                     -- John von Neumann