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
next prev parent 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