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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090725002916.GB13556@shareable.org>
Date:	Sat, 25 Jul 2009 01:29:16 +0100
From:	Jamie Lokier <jamie@...reable.org>
To:	Eric Paris <eparis@...hat.com>
Cc:	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

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.

> >    - No file name for things that happen in a subdirectory.
> 
> Actually I should be more clear about that.  If you call
> setsockopt(FANOTIFY_ADD_MARK) where
> 
> struct fanotify_so_inode_mark {
>         __s32 fd;	= "/tmp/"
>         __u32 mask;	= (FAN_OPEN | FAN_EVENT_ON_CHILD);
>         __u32 ignored_mask; = 0
> };
> 
> and someone opens /tmp/file1 you are going to get an open fd
> for /tmp/file1 NOT for /tmp.  This is different than inotify.

If you inotify for IN_OPEN on /tmp, it would return an event when you
open /tmp/file1, with the name "file1" and the directory /tmp.  It's
no so different.  The main difference is inotify returns a name and no
inode number (so it's racy, sigh), whereas fanotify returns an open file.

Do I see right that you need to open the directory before you can set
the mark on it?

The main reason behind inotify's design wasn't the API (although it is
better than dnotify); it was to avoid having to open thousands of
directories, and to allow a filesystem to be unmounted while it is
being watched.

Does a fanotify mark stop a filesystem from being unmounted?  If not,
if the filesystem is unmounted and remounted, is the mark lost?

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