public inbox for linux-audit@redhat.com
 help / color / mirror / Atom feed
From: pg@aud.list.sabi.co.UK (Peter Grandi)
To: Linux audit <linux-audit@redhat.com>
Subject: Re: peculiar disappearance of most audit rules
Date: Tue, 22 Apr 2014 21:53:15 +0100	[thread overview]
Message-ID: <21334.54971.174073.755376@tree.ty.sabi.co.uk> (raw)
In-Reply-To: <21333.33865.378826.157120@tree.ty.sabi.co.uk>

>> I don't know what is managing your system, but its probably
>> deleting paths.

> I am the sole user (as far as I know...) of both systems, [
> ... ] None of the "disappeared" paths seems to have been
> modified in any way. [ ... ] Anyhow, I have now recorded the
> inos of the watched directories, and I shall also run
> 'inotifywait -m /' to catch if possible any changes in '/opt'
> and '/boot'.

I have done this and this morning during 'mlocate' treewalking
some of the usual paths disappeared; I verified the inos and
the 'inotify' output and no inos changed nor any of the watched
directories changed.

Since the list of directories that *do not* disappear is
usually:

  LIST_RULES: exit,always dir=/bin (0x4) perm=wa key=pkg-s
  LIST_RULES: exit,always dir=/etc (0x4) perm=wa key=pkg-s
  LIST_RULES: exit,always dir=/lib (0x4) perm=wa key=pkg-s
  LIST_RULES: exit,always dir=/usr (0x4) perm=wa key=pkg-s
  LIST_RULES: exit,always dir=/fs/sozan/loc (0xd) perm=wa key=pkg-l
  LIST_RULES: exit,always dir=/fs/sozan/com (0xd) perm=wa key=pkg-l

and those that disappear tend to be far less frequently used
directories like '/boot', '/opt', '/lib32'. Rereading this:

>> [ ... ] device and inode information. This is, technically,
>> what your watch is on. If the inode disappears, then the rule
>> is ejected. Rules can survive across renames but not deletions.

it appears that I misread earlier: this says "inode", not
"inum". Also it says "inode disappears", which is not
necessarily always because the on-disk inode is deleted.

Thus I have come up with a potential explanation:

  * The 'audit' module does not identify the watched file and
    directory by (device,ino) but by a pointer to an inode table
    entry, a bit like a filesystem module would.
  * During treewalks a lot of inodes get cached in the in-memory
    inode table.
  * This creates pressure on the inode tables and thus the least
    used (in some sense) inodes get evicted, and this includes
    those for the "disappearing directories".
  * When these least used inodes are evicted the 'audit' module
    sees it as if it was a removal of the inode.

If the above is the right explanation it is a pretty big deal,
because it means that a way to disable many/most 'audit' watches
on files is to create and access a lot of inodes, which is
pretty easy to do.

  reply	other threads:[~2014-04-22 20:53 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-21 17:49 peculiar disappearance of most audit rules Peter Grandi
2014-04-21 18:28 ` Steve Grubb
2014-04-21 18:35   ` lists_todd
2014-04-21 19:03     ` Eric Paris
2014-04-21 20:49   ` Peter Grandi
2014-04-22 20:53     ` Peter Grandi [this message]
2014-04-22 21:46       ` Steve Grubb
2014-04-23  8:04       ` Peter Grandi
2014-04-23 14:34         ` Eric Paris
2014-04-27 20:33           ` Peter Grandi
2014-11-05 16:55             ` Richard Guy Briggs

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=21334.54971.174073.755376@tree.ty.sabi.co.uk \
    --to=pg@aud.list.sabi.co.uk \
    --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