linux-kernel - Re: [PATCH v2 resend] vfs: new 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] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 6 Nov 2009 01:40:20 +0000
From:	Jamie Lokier <jamie@...reable.org>
To:	Miklos Szeredi <miklos@...redi.hu>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>, akpm@...ux-foundation.org,
	viro@...IV.linux.org.uk, dhowells@...hat.com, hch@...radead.org,
	adilger@....com, mtk.manpages@...il.com,
	torvalds@...ux-foundation.org, drepper@...il.com,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 resend] vfs: new O_NODE open flag

Miklos Szeredi wrote:
>   "A file descriptor opened with O_NODE | O_NOACCESS may be used to
>    re-open the same file later with increased permissions
>    (e.g. O_RDWR) if the access mode allows.  This is true even if the
>    permissions on the path leading up to the file would prevent it"

It isn't just "the path".

The same issues apply to a file which has been deleted.  Having been
passed a file handle from some other process, you are granted greater
access to a file which has no path at all and no other handles open to
it, which it's reasonable unix security tradition to assume can't be
done.

It's not quite the same issue as /proc/PID/fd.  Someone must have
explicitly used O_NODE, which means they intend for access to be
upgradable later; they won't be surprised by it happening.

But I still think the re-open access should be limited to whatever was
the original access mode, in the same way as has been discussed for
/proc/PID/fd.

So you'd use O_NODE|O_RDWR if you want someone to be able to re-open
the file itself later with O_RDWR acces.  Use O_NODE|O_RDONLY if you
want them to be only able to re-open the file itself with O_RDONLY
access.  That would limit O_NODE|O_NOACCESS to only being able to
re-open with O_NODE|O_NOACCESS again (because O_NOACCESS by itself
isn't allowed).

Is there any reason why O_NODE|O_RDWR cannot be used for that purpose?

> Why would the server need to know anything about that?  O_NODE is
> similar to a chdir() in this respect, and chdir doesn't have a handler
> either.

chdir() needs execute access.

Note we're a bit broken w.r.t. current POSIX regarding fchdir() and
execute-only directories.  It would be good to fix that.

However, it might be possible to craft a "non-pinning inode reference"
in a similar way to inotify.  Either by not referencing the inode
directly (like inotify), or by creating a weak reference method, which
would be more reliable on filesystems without stable inode numbers.

Actually a non-pinning inode reference would be handy for other things
too.  *Must resist temptation to implement O_NOPIN option for open
files generally ;-)*

> However, there's not all that much difference between the above and
> doing "stat()" on the mountpoint in a tight loop, except the former is
> a more reliable way to prevent unmounting.

Are you sure that stops unmounting?  Doesn't unmounting just sit in a
lock waitqueue somewhere like a regular rwlock writer, until it's time
comes?

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