linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Elladan <elladan@eskimo.com>
To: redph0enix@hotmail.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: Linux C2-Style Audit Capability
Date: Sat, 4 Aug 2001 13:48:55 -0700	[thread overview]
Message-ID: <20010804134854.A2270@eskimo.eskimo.com> (raw)

This is a classic producer-consumer problem.  There are only two solutions:

* Discard log events (unacceptable for security - anyone could just turn off 
  logging whenever they want by spamming the system with spurious log events)
* Block the producer

So, really, you have no choice but to block the producer of the log events, eg.
block all logged system calls until the buffer is depleted again.

Of course, this leads to all sorts of enjoyable deadlock conditions in the
system...  The audit daemon itself cannot block on anything safely, really.
Eg:

What if the audit daemon is just passing the log events on to a log daemon on
the same machine?  The log daemon itself gets logged, so it gets blocked
waiting for the audit buffer.  The audit daemon is trying to deplete its own
buffer by sending to the log daemon, which will never be available...  Poof!

What if the audit daemon is just passing the log events on to an external log
daemon on another machine?  This seems ok, as long as the other machine is
visible.  As soon as it dies, the audited machine will hang until the log host
comes back.  It can't even be shut down, since the shutdown command will be
logged ...

...  But what if the logging machine itself is just a router that sends off
streams from multiple machines to be warehoused?  This seems fine, except...
What if the warehousing machine is itself audited?  It tries to log its audit
stream back to the router, which comes back to itself, which blocks the entire
computer network until someone kicks something.  Ack! 

So it seems that to avoid losing a few system calls in a kernel ring buffer,
you've now crashed an entire NOC.  :-)


The audit daemon will have to be smart and log to some sort of ring buffer on
disk, but of course, disk space is not infinite, so eventually it will have to
start throwing away old log events, just as the kernel does.  So we're right
back where we started.  But perhaps it will take a few days before you have to
do this, with a big disk buffer.  

(Or perhaps not...  If you logged every lstat(), and each log line was 100 
bytes, it seems a malicious user could generate 103 gigabytes of log data in 1
hour, thus erasing their malicious actions at the start of the hour.)

-J

             reply	other threads:[~2001-08-04 20:49 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-08-04 20:48 Elladan [this message]
     [not found] <fa.hg36o7v.1076epo@ifi.uio.no>
     [not found] ` <fa.i3h9gdv.45k3go@ifi.uio.no>
2001-08-06 22:07   ` Linux C2-Style Audit Capability richard offer
  -- strict thread matches above, loose matches on Subject: below --
2001-08-04 23:01 Hank Leininger
2001-08-04  7:03 Red Phoenix
2001-08-04  9:23 ` Alan Cox
2001-08-04 16:46   ` Ralf Baechle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010804134854.A2270@eskimo.eskimo.com \
    --to=elladan@eskimo.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=redph0enix@hotmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).