linux-kernel - Re: [PATCH 0/6] File Sealing & memfd

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, 20 Mar 2014 09:07:06 +0100
From:	David Herrmann <dh.herrmann@...il.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Hugh Dickins <hughd@...gle.com>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Karol Lewandowski <k.lewandowsk@...sung.com>,
	Kay Sievers <kay@...y.org>, Daniel Mack <zonque@...il.com>,
	Lennart Poettering <lennart@...ttering.net>,
	Kristian Høgsberg <krh@...planet.net>,
	John Stultz <john.stultz@...aro.org>,
	Greg Kroah-Hartman <greg@...ah.com>, Tejun Heo <tj@...nel.org>,
	Johannes Weiner <hannes@...xchg.org>,
	DRI <dri-devel@...ts.freedesktop.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	linux-mm <linux-mm@...ck.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ryan Lortie <desrt@...rt.ca>,
	"Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
Subject: Re: [PATCH 0/6] File Sealing & memfd_create()

Hi

On Thu, Mar 20, 2014 at 4:49 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> Is there really any use-case where the sealer isn't also the same
> thing that *created* the file in the first place? Because I would be a
> ton happier with the notion that you can only seal things that you
> yourself created. At that point, the exclusive reference isn't such a
> big deal any more, but more importantly, you can't play random
> denial-of-service games on files that aren't really yours.

My first idea was to add MFD_ALLOW_SEALING as memfd_create() flag,
which enables the sealing-API for that file. Then I looked at POSIX
mandatory locking and noticed that it provides similar restrictions on
_all_ files. Mandatory locks can be more easily removed, but an
attacker could just re-apply them in a loop, so that's not really an
argument. Furthermore, sealing requires _write_ access so I wonder
what kind of DoS attacks are possible with sealing that are not
already possible with write access? And sealing is only possible if no
writable, shared mapping exists. So even if an attacker seals a file,
all that happens is EPERM, not SIGBUS (still a possible
denial-of-service scenario).

But I understand that it is quite hard to review all the possible
scenarios. So I'm fine with checking inode-ownership permissions for
SET_SEALS. We could also make sealing a one-shot operation. Given that
in a no-trust situation there is never a guarantee that the other side
drops its references, re-using a sealed file is usually not possible.
However, in sane environments, this could be a nice optimization in
case the other side plays along. The one-shot semantics would allow
dropping reference-checks entirely. The inode-ownership semantics
would still require it.

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