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:	Wed, 19 Mar 2014 20:49:28 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	David Herrmann <dh.herrmann@...il.com>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Hugh Dickins <hughd@...gle.com>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Matthew Wilcox <matthew@....cx>,
	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()

On Wed, Mar 19, 2014 at 12:06 PM, David Herrmann <dh.herrmann@...il.com> wrote:
>
> Unlike existing techniques that provide similar protection, sealing allows
> file-sharing without any trust-relationship. This is enforced by rejecting seal
> modifications if you don't own an exclusive reference to the given file.

I like the concept, but I really hate that "exclusive reference"
approach. I see why you did it, but I also worry that it means that
people can open random shm files that are *not* expected to be sealed,
and screw up applications that don't expect it.

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.

The fact that you bring up the races involved with the exclusive
reference approach also just makes me go "Is that really the correct
security model"?

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