linux-kernel - Re: fanotify - overall design before I start sending patches

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: <20090727192342.GA27895@shareable.org>
Date:	Mon, 27 Jul 2009 20:23:42 +0100
From:	Jamie Lokier <jamie@...reable.org>
To:	Andreas Dilger <adilger@....com>
Cc:	Eric Paris <eparis@...hat.com>, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, malware-list@...sg.printk.net,
	Valdis.Kletnieks@...edu, greg@...ah.com, jcm@...hat.com,
	douglas.leeder@...hos.com, tytso@....edu, arjan@...radead.org,
	david@...g.hm, jengelh@...ozas.de, aviro@...hat.com,
	mrkafk@...il.com, alexl@...hat.com, jack@...e.cz,
	tvrtko.ursulin@...hos.com, a.p.zijlstra@...llo.nl,
	hch@...radead.org, alan@...rguk.ukuu.org.uk, mmorley@....in,
	pavel@...e.cz
Subject: Re: fanotify - overall design before I start sending patches

Andreas Dilger wrote:
> On Jul 25, 2009  01:29 +0100, Jamie Lokier wrote:
> > Eric Paris wrote:
> > > But maybe I should jsut do the 'if you have fanotify open, you don't
> > > create other fanotify events'...   so everyone gets what they expect...
> > 
> > O_NONOTIFY.  Similar security concerns, more control.
> > 
> > The security concern is clear: If you allow a process with fanotify
> > open to not create events, then any (root) process can open a fanotify
> > socket to hide it's behaviour.
> 
> I think the "fanotify doesn't generate more fanotify events" makes the
> most sense.  Given that the open will be done in the kernel specifically
> due to fanotify, this doesn't actually allow the listener to open files
> without detection (unlike the "O_NONOTIFY" flag would).  The fanotify
> "opens" would only be in response to other processes opening the file.

Nice idea (if I understand it) - the file descriptors opened by
fanotify wouldn't cause fanotify events?  Effectively having an
in-kernel O_NONOTIFY flag which can't be set from userspace?

'if you have fanotify open, you don't create other fanotify events' is
too severe - it means you can circumvent fanotify entirely for
everything your process does by just opening a fanotify socket and not
using it, which is clearly worse than having an O_NONOTIFY flag.

All ways to avoid creating fanotify events introduce security and
cache integrity problems though.

Why should processes which simply _watch_ the filesystem, without
modifying any files, ever fail to receive information about file
changes?  Why should they be unable to claim they provide integrity
guarantees because of the loophole?

So before we implement that loophole: let's ask ourselves if we really
need it at all.

What's wrong with fanotify-using applications generating events when
they modify files themselves?

An example was given where app A gets an event and modifies the file,
then app B gets an event and modifies the file, and app A... cycling.

But if you have two "virus checker" style applications fighting over
modifying the same file without locking, you have much bigger problems
already.  There's nothing to gain by fixing the fanotify cycle.

Maybe there's no need to suppress events after all.

Programs monitoring for writes to maintain caches or integrity checks
will be much happier if they know they're getting all file modifications.

-- Jamie
--
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/