Auditing - Snare, LAuS, SELinux

Jonathan Abbey jonabbey at arlut.utexas.edu
Wed Sep 8 13:22:52 UTC 2004


On Wed, Sep 08, 2004 at 11:33:23AM +0200, Thomas Biege wrote:
|
| 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...)

Yes, if the data is formatted in such a way as to make that process
simple, either through adequately descriptive binary encoding or by
the use of some visually easily processed text format.  I could see
putting some redundancy and event numbering / date information into a
binary format so that such custom tools could be written to scan for
blocks on disk, but I can also imagine binary encodings that attempted
to be parsimonious on space at the cost of retrievability in the event
of a partial log host disk failure, and etc.

I babble.  I would rather see a textual format as well, just to aid in
the programmatic analysis of the log files, but an openly documented
binary format, with free code in the wild for doing analysis (Perl,
Python modules..) would be a good second, there.

| 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. :)

Yet, completely adequate to the NISPOM Ch. 8, PL 1 regulations in the
United States, oddly enough.  Those regulations clearly say 'yeah, if
your attacker has root, we don't really expect you to be able to do
anything reliable in your auditing'.

That doesn't make it not stupid, of course. ;-)

Snare does come out of the box with support for remote logging and
analysis.

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

So what are the low-level advantages of Rik's framework over LAuS,
again?  Just the low free trapping of syscalls in the non-audited
case, and its current acceptance into the 2.6 line?

What kind of userland tools are necessary now to really make audit.rik
useful?

 Jon

| 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
| 
| --
| Linux-audit mailing list
| Linux-audit at redhat.com
| http://www.redhat.com/mailman/listinfo/linux-audit

-- 
-------------------------------------------------------------------------------
Jonathan Abbey 				              jonabbey at arlut.utexas.edu
Applied Research Laboratories                 The University of Texas at Austin
GPG Key: 71767586 at keyserver pgp.mit.edu, http://www.ganymeta.org/workkey.gpg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 185 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20040908/0f3f78fd/attachment.sig>


More information about the Linux-audit mailing list