4:33 a.m.
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(a)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