All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Moseley <moseleymark@gmail.com>
To: unlisted-recipients:; (no To-header on input)
Cc: linux-kernel@vger.kernel.org, linux-audit@redhat.com
Subject: Re: linux-audit: reconstruct path names from syscall events?
Date: Wed, 10 Oct 2012 15:45:08 -0700	[thread overview]
Message-ID: <CAOH1cHkowcv6k0D2bkXFcjU3k4UtG2WX3nSwNa267qmODNfs_w@mail.gmail.com> (raw)
In-Reply-To: <20121009235446.GZ2616@ZenIV.linux.org.uk>

On Tue, Oct 9, 2012 at 4:54 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Tue, Oct 09, 2012 at 04:47:17PM -0700, Mark Moseley wrote:
>> > BTW, what makes you think that container's root is even reachable from
>> > "the host's /"?  There is no such thing as "root of the OS itself"; different
>> > processes can (and in case of containers definitely do) run in different
>> > namespaces.  With entirely different filesystems mounted in those, and
>> > no promise whatsoever that any specific namespace happens to have all
>> > filesystems mounted somewhere in it...
>>
>> Nothing beyond guesswork, since it's been a while since I've played
>> with LXC. In any case, I was struggling a bit for the correct
>> terminology.
>>
>> Am I similarly off-base with regards to the chroot'd scenario?
>
> chroot case is going to be reachable from namespace root, but I seriously
> doubt that pathname relative to that will be more useful...

Possibly not, but it'd still be good to have some sort of indicator
that this entry is being logged relative to the chroot, like an
additional item in the audit entry or even some kind of flag. But in
this case, and far more so in the unlinkat/chmodat/chownat case, I'd
think the least surprising thing (to me, at least) would be for the
directory item in the audit entry to have a pathname relative to
namespace root.

> Again, relying on pathnames for forensics (or security in general) is
> a serious mistake (cue unprintable comments about apparmor and similar
> varieties of snake oil).  And using audit as poor man's ktrace analog
> is... misguided, to put it very mildly.

Caveat: I'm just a sysadmin, so this stuff is as darn near "magic" as
I get to see on a regular basis, so it's safe to expect some naivety
and/or misguidedness on my part :)

I'm just using it as a log of files that have been written/changed on
moderately- to heavily-used systems. If there's another in-kernel
mechanism that'd be better suited for that sort of thing (at least
without adding a lot of overhead), I'd be definitely eager to know
about it. It's a web hosting environment, with customer files all
solely on NFS, so writes to the same directory can come from an
arbitrary number of servers. When they get swamped with write
requests, the amount of per-client stats exposed by our Netapp and
Oracle NFS servers is often only enough to point us at a client server
with an abusive user on it (but not much more, without turning on
debugging). Having logs of who's doing writes would be quite useful,
esp when writes aren't happening at that exact moment and wouldn't
show up in tools like iotop. The audit subsystem seemed like the best
fit for this kind of thing, but I'm more than open to whatever works.

WARNING: multiple messages have this Message-ID (diff)
From: Mark Moseley <moseleymark@gmail.com>
Cc: linux-kernel@vger.kernel.org, linux-audit@redhat.com
Subject: Re: linux-audit: reconstruct path names from syscall events?
Date: Wed, 10 Oct 2012 15:45:08 -0700	[thread overview]
Message-ID: <CAOH1cHkowcv6k0D2bkXFcjU3k4UtG2WX3nSwNa267qmODNfs_w@mail.gmail.com> (raw)
In-Reply-To: <20121009235446.GZ2616@ZenIV.linux.org.uk>

On Tue, Oct 9, 2012 at 4:54 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Tue, Oct 09, 2012 at 04:47:17PM -0700, Mark Moseley wrote:
>> > BTW, what makes you think that container's root is even reachable from
>> > "the host's /"?  There is no such thing as "root of the OS itself"; different
>> > processes can (and in case of containers definitely do) run in different
>> > namespaces.  With entirely different filesystems mounted in those, and
>> > no promise whatsoever that any specific namespace happens to have all
>> > filesystems mounted somewhere in it...
>>
>> Nothing beyond guesswork, since it's been a while since I've played
>> with LXC. In any case, I was struggling a bit for the correct
>> terminology.
>>
>> Am I similarly off-base with regards to the chroot'd scenario?
>
> chroot case is going to be reachable from namespace root, but I seriously
> doubt that pathname relative to that will be more useful...

Possibly not, but it'd still be good to have some sort of indicator
that this entry is being logged relative to the chroot, like an
additional item in the audit entry or even some kind of flag. But in
this case, and far more so in the unlinkat/chmodat/chownat case, I'd
think the least surprising thing (to me, at least) would be for the
directory item in the audit entry to have a pathname relative to
namespace root.

> Again, relying on pathnames for forensics (or security in general) is
> a serious mistake (cue unprintable comments about apparmor and similar
> varieties of snake oil).  And using audit as poor man's ktrace analog
> is... misguided, to put it very mildly.

Caveat: I'm just a sysadmin, so this stuff is as darn near "magic" as
I get to see on a regular basis, so it's safe to expect some naivety
and/or misguidedness on my part :)

I'm just using it as a log of files that have been written/changed on
moderately- to heavily-used systems. If there's another in-kernel
mechanism that'd be better suited for that sort of thing (at least
without adding a lot of overhead), I'd be definitely eager to know
about it. It's a web hosting environment, with customer files all
solely on NFS, so writes to the same directory can come from an
arbitrary number of servers. When they get swamped with write
requests, the amount of per-client stats exposed by our Netapp and
Oracle NFS servers is often only enough to point us at a client server
with an abusive user on it (but not much more, without turning on
debugging). Having logs of who's doing writes would be quite useful,
esp when writes aren't happening at that exact moment and wouldn't
show up in tools like iotop. The audit subsystem seemed like the best
fit for this kind of thing, but I'm more than open to whatever works.

  reply	other threads:[~2012-10-10 22:45 UTC|newest]

Thread overview: 23+ 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
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 [this message]
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=CAOH1cHkowcv6k0D2bkXFcjU3k4UtG2WX3nSwNa267qmODNfs_w@mail.gmail.com \
    --to=moseleymark@gmail.com \
    --cc=linux-audit@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.