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
8:22 a.m.
New subject: Auditing - Snare, LAuS, SELinux
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(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
|
| --
| Linux-audit mailing list
| Linux-audit(a)redhat.com
| http://www.redhat.com/mailman/listinfo/linux-audit
--
-------------------------------------------------------------------------------
Jonathan Abbey jonabbey(a)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
8:40 a.m.
New subject: Auditing - Snare, LAuS, SELinux
On Wed, 2004-09-08 at 09:22, Jonathan Abbey wrote:
On Wed, Sep 08, 2004 at 11:33:23AM +0200, Thomas Biege wrote:
| 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?
See Rik's original description of the framework in
http://marc.theaimsgroup.com/?l=linux-kernel&m=107815879812958&w=2
By hooking the kernel internal routines such as getname and path_lookup,
Rik's framework is able to capture information such as pathnames and
device, inode pairs without resorting to any extra copying or lookups,
yielding lower overhead and less complexity (and less risk due to races
introduced by separate copying). The tradeoff was the invasiveness of
the patch, but since the patch was accepted into the mainline kernel,
that is no longer an issue.
The framework also provided support for other components (like SELinux)
to easily generate audit messages and trigger generation of syscall
auditing on syscall exit from any point during processing, and included
support for audit generation from any calling context, including hard
irq (needed for send_sigio permission checking).
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
6:33 a.m.
New subject: Auditing - Snare, LAuS, SELinux
| 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?
I do not know the technical details of the various implementations well
enough to compare them.
I have two things on my mind... ok let's say three:
- LAuS passed EAL3
- Rik's audit system is in the mainline kernel
- Rik's audit system is relatively small
If we combine them we have one standard audit subsystem, that is
maintained by the community, and will be CC compliant.
I also see the technical advantage of SELinux concerning filenames and the
tricks that can be played with them...
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
6:53 p.m.
New subject: Auditing - Snare, LAuS, SELinux
On Wed, 2004-09-08 at 19:33, Thomas Biege wrote:
I prefer binary format too because the semantic of data can easily
and
clearly be gained by using structures.
Binary structures are generally helpful in order to store a significant
effective volume of data, in a small amount of memory, so are
appropriate in the kernel. Outside the kernel, they are usually more of
an impediment to effective audit log processing - just another step you
have to work through before getting useful info.
This helps developing host-based IDSs.
As a developer of several host-based IDSs over the years, I'd have to
disagree. :)
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.
Fair enough.
> > 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.
Absolutely. As I mentioned earlier, I'd recommend going with a
text-based format throughout, for exactly the reasons you talk about
above. However, binary in-kernel, and as a transition format between
kernel and userspace, does have some advantages (particularly if you are
going to do filtering at the daemon).
IF we're going to go down the path of a binary transit format:
Milliseconds worth of delay is an acceptable risk for most
organisations, for most events. On a per-event basis, the chance of a
user being deleted between picking out the UID in the kernel, and
converting the event to text format when delivered to user-space is very
small.
Try and convert the binary event to text a few months, or years later
however, and you're in real trouble.
An exception is probably the file-related stuff, eg: unlink - by the
time you send the inode to user-space, there's a fair change it's
already gone - which is why I recommended text-conversion of file names
directly in the kernel, which would also assist with the process of
filename matching in the kernel as Olaf proposed.
> > - 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. :)
Absolutely. And there are about a dozen more problems with the windows
implementation of auditing.. and several more in solaris, and ... you
get the idea. However, it is a general point, that illustrates a
potential problem related to binary record format.
> > * 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.
Again, this is just an illustration of the problems of binary formats.
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. :)
Agree. However, keep in mind that 'ideal' is probably not a good term to
use. 'Ideal' means different things to different organisations - some
organisations have a low priority associated with audit log information
(they use it merely as a 'potential problem indicator', rather than
'court admissible data') - so having the overhead of signing and
encrypting log data on the client would be very bad for them.
Keeping logs only on the disk is not something I would recommend
personally in most circumstances, but there are some situations were
even this would be considered 'ideal' for an organisation in the context
of their risk assessment, and within the boundaries of other potential
controls that they have in place.
My point, I guess, is that you can put in as many options into the audit
subsystem as required, in order to meet a perceived 'ideal'
implementation, but as soon as you start mandating them, you start
loosing potential users, as their idea of ideal is likely to be very
different than ours. (eg: halt on audit fail, mandatory encryption,
etc.)
El-quicko summary:
* Binary formats are still non-optimal
* The log that's written out from the daemon REALLY needs to have any
'transitory' binary data mapped to text format (eg: UIDs, filenames). It
would be better for this to happen in the kernel so that race conditions
are less of a problem, but conversion of most data at daemon might be a
reasonable trade-off if required.
L.
--
Leigh Purdie, Director - InterSect Alliance Pty Ltd
http://www.intersectalliance.com/
7408
days inactive
7409
days old
linux-audit@lists.linux-audit.osci.io
4 comments
4 participants
participants (4)
-
Jonathan Abbey -
Leigh Purdie -
Stephen Smalley -
Thomas Biege