linux-kernel - Re: [PATCH] open(2): document O

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] [day] [month] [year] [list]

Date:	Tue, 8 Jan 2013 18:52:02 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
Cc:	mtk.manpages@...il.com, Mike Frysinger <vapier@...too.org>,
	linux-man@...r.kernel.org, Richard Weinberger <richard@....at>,
	lkml <linux-kernel@...r.kernel.org>, pschiffe@...hat.com
Subject: Re: [PATCH] open(2): document O_PATH

On Thu, May 03, 2012 at 03:11:56PM +0100, Al Viro wrote:
> On Thu, May 03, 2012 at 07:34:35PM +0530, Aneesh Kumar K.V wrote:
> 
> > I looked at dnotify_flush, they remove markers on an inode.
> > But then it also checks for filp to match. So I am not sure
> > whether skipping dnotify_flush for O_PATH descriptor have any impact. We
> > can't use O_PATH descriptor for dnotify fcntl any way. So in
> > dnotify_flush we will not match the filp.
> > 
> > Viro,
> > 
> > Any reason why we skip dnotify_flush  ?
> 
> See your last sentence above - why bother finding the mark, scanning the
> list, etc. when we know that there won't be any matches?

[Apologies for replying to the wrong posting, but this is the closest thing
thread-wise to what I wanted to reply to that I've got sitting in my mailbox]

The rules are:
	* syscalls acting purely on descriptor level are allowed - close(),
dup(), dup2(), dup3(), fcntl(F_DUPFD{,_CLOEXEC}), fcntl(F_[SG]ETFD),
fcntl(F_GETFL), passing descriptors in SCM_RIGHTS datagrams)
	* syscalls using the descriptor just to indicate a location in
the tree - *at() family, fchdir(), fstat()
The list might get expanded - for example, fstatfs() arguably belongs to the
second group.  The approach had been conservative - the second group gets
expanded on per-case basis.  E.g. anything requiring the file to have
been opened for write is *not* a candidate, so it really has to be reviewed
separately for each syscall of that sort.

As far as dnotify and POSIX locks go, close() (and replacing dup2(), etc.)
are irrelevant - the rules are exactly as usual.  All dnotify watches or
POSIX locks associated with that opened file get evicted; it's just that
there is no way to *set* them on O_PATH descriptors in the first place.
We might eventually allow fcntl(F_NOTIFY) on them, but I'm not sure there's
any good reason to do so; allowing to use them for setting POSIX locks is
almost certainly a bad idea wrt security.

The test in filp_close() is just an optimization - if/when we allow F_NOTIFY
on O_PATH descriptors, the same commit will need to make the call of
dnotify_flush() in filp_open() unconditional.  All there is to it...
--
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/