public inbox for linux-audit@redhat.com
 help / color / mirror / Atom feed
From: Steve Grubb <sgrubb@redhat.com>
To: linux-audit@redhat.com
Subject: Re: linux-audit: reconstruct path names from syscall events?
Date: Fri, 7 Oct 2011 10:04:06 -0400	[thread overview]
Message-ID: <201110071004.06810.sgrubb@redhat.com> (raw)
In-Reply-To: <1317995458.3304.9.camel@localhost>

On Friday, October 07, 2011 09:50:58 AM Eric Paris wrote:
> Audit logs based on name are wrong and misleading.  There's a reason the
> auditable object is the inode and fs details Casey mentioned.  We might
> be able to usually give me information, but that information cannot EVER
> be used for anything useful.  Its unreliable.  Exposing it only leads
> one to believe they have knowledge they don't.

But also depending on an inode leads you to have knowledge when you don't. Inodes get 
reassigned. Depending on when you look at your logs, that inode could have been used 
in 5 different file names between the event and now. So, it is important to snapshot 
what the inode was associated with at a given time.

My thinking is that we can make the system more useful even with name spaces. By 
recording the current association we are more certain about what was being accessed. 
We should be able to record the mount command that caused the new namespace so that we 
can reconstruct a meaningful path. Maybe we need to change the session id on that 
occurance so that child processes can be properly identified.

But you raise a new point that I think we eventally have to address and that is 
containers. I think we will have to record container IDs and the like so that an audit 
event can have a proper context for what it means. We at some point could have 
duplicate uids and pids that are disjointed - not just files.

We have to address this some time.

-Steve

  reply	other threads:[~2011-10-07 14:04 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-17  0:12 linux-audit: reconstruct path names from syscall events? John Feuerstein
2011-10-01 12:31 ` Steve Grubb
2011-10-03 19:42   ` Casey Schaufler
2011-10-04 17:02     ` Steve Grubb
2011-10-04 22:09     ` John Feuerstein
2011-10-07 13:50       ` Eric Paris
2011-10-07 14:04         ` Steve Grubb [this message]
2011-10-07 17:20         ` Casey Schaufler
2011-10-07 18:02           ` Steve Grubb
2011-10-07 18:27           ` Eric Paris
2011-10-07 21:38             ` Casey Schaufler
2011-10-10 12:54               ` Steve Grubb
2012-10-09 23:09 ` Mark Moseley
2012-10-09 23:29   ` Al Viro
2012-10-09 23:39   ` Al Viro
2012-10-09 23:47     ` Mark Moseley
2012-10-09 23:54       ` Al Viro
2012-10-10 22:45         ` Mark Moseley
2012-10-10 23:00           ` Steve Grubb
2012-10-10 23:07             ` Mark Moseley
2012-10-11 17:27               ` Mark Moseley
2012-10-30  1:12                 ` Mark Moseley

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=201110071004.06810.sgrubb@redhat.com \
    --to=sgrubb@redhat.com \
    --cc=linux-audit@redhat.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