lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20343600.HhDMLCt7mX@sifl>
Date:	Tue, 10 Feb 2015 19:58:35 -0500
From:	Paul Moore <paul@...l-moore.com>
To:	Jan Kara <jack@...e.cz>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>, linux-audit@...hat.com,
	Eric Paris <eparis@...hat.com>, stable@...r.kernel.org
Subject: Re: [PATCH] fsnotify: Fix handling of renames in audit

On Tuesday, February 10, 2015 04:00:12 PM Jan Kara wrote:
> Commit e9fd702a58c4 (audit: convert audit watches to use fsnotify
> instead of inotify) broke handling of renames in audit. Audit code wants
> to update inode number of an inode corresponding to watched name in a
> directory. When something gets renamed into a directory to a watched
> name, inotify previously passed moved inode to audit code however new
> fsnotify code passes directory inode where the change happened. That
> confuses audit and it starts watching parent directory instead of a file
> in a directory.
> 
> This can be observed for example by doing:
> cd /tmp
> touch foo bar
> auditctl -w /tmp/foo
> touch foo
> mv bar foo
> touch foo
> 
> In audit log we see events like:
> type=CONFIG_CHANGE msg=audit(1423563584.155:90): auid=1000 ses=2
> op="updated rules" path="/tmp/foo" key=(null) list=4 res=1
> ...
> type=PATH msg=audit(1423563584.155:91): item=2 name="bar" inode=1046884
> dev=08:0
> 2 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=DELETE
> type=PATH msg=audit(1423563584.155:91): item=3 name="foo" inode=1046842
> dev=08:0
> 2 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=DELETE
> type=PATH msg=audit(1423563584.155:91): item=4 name="foo" inode=1046884
> dev=08:0
> 2 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=CREATE
> ...
> and that's it - we see event for the first touch after creating the
> audit rule, we see events for rename but we don't see any event for the
> last touch. However we start seeing events for unrelated stuff happening
> in /tmp.
> 
> Fix the problem by passing moved inode as data in the FS_MOVED_FROM and
> FS_MOVED_TO events instead of the directory where the change happens.
> This doesn't introduce any new problems because noone besides
> audit_watch.c cares about the passed value:
> fs/notify/fanotify/fanotify.c cares only about FSNOTIFY_EVENT_PATH events.
> fs/notify/dnotify/dnotify.c doesn't care about passed 'data' value at all.
> fs/notify/inotify/inotify_fsnotify.c uses 'data' only for
> FSNOTIFY_EVENT_PATH. kernel/audit_tree.c doesn't care about passed 'data'
> at all.
> kernel/audit_watch.c expects moved inode as 'data'.
> 
> CC: linux-audit@...hat.com
> CC: Paul Moore <paul@...l-moore.com>
> CC: Eric Paris <eparis@...hat.com>
> CC: stable@...r.kernel.org
> Fixes: e9fd702a58c49dbb14481dca88dad44758da393a
> Signed-off-by: Jan Kara <jack@...e.cz>
> ---
>  include/linux/fsnotify.h | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)

I can confirm this is indeed broken.

Thanks for the patch.  I'm building a test kernel as I type this, assuming all 
goes well I'll send this to Linus with the other audit patches for v3.20.

-- 
paul moore
www.paul-moore.com

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ