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:	Thu, 5 Nov 2009 15:56:48 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Miklos Szeredi <miklos@...redi.hu>
Cc:	miklos@...redi.hu, 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,
	jamie@...reable.org, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 resend] vfs: new O_NODE open flag

> > Fortunately you can patch it by hand.
> 
> How do you patch it by hand?

I find "joe" quite useful, some people prefer vi or emacs

> All of this is about new and unexpected semantics.  I don't think
> anything more needs to be done than document it in the manpage:

It's a security changing behaviour. It's effectively a regression for
security and that is usually bad news.

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

Which is contrary to the assumptions made by systems designers for the
past forty years, so its a very dangerous assumption to break.

What are the sematics with regards to vhangup ?

What are the sematics of O_NODE opening a device file when the device is
later unloaded and a new device is created on the same node with totally
unrelated permissions ? [happens all the time btw]

> > But that isn't the case for some things - consider CIFS and other network
> > file systems.
> 
> Why?

open O_NODE
remote file moves
new one appears
reopen

Now what should happen and what does happen ?

> of the volume does not allow any access to the user, so normal
> open/chdir won't work.  Yet open(O_NODE) will and so user can pin the
> volume.

and without permission on the node.

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

That doesn't seem to be the case testing it, but its fixable trivially if
so and its fixable without API breakage. Its at worst an implementation
corner case. The O_NODE case is a real nasty API level problem,
particularly as Linux still lacks revoke().

In fact I'd say given the need to get rid of O_NODE references to an
object that you need revoke() first and that revoke must kill O_NODE
references to an object as well.

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