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]

Message-ID: <20140320152657.381956ff@alan.etchedpixels.co.uk>
Date:	Thu, 20 Mar 2014 15:26:57 +0000
From:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To:	David Herrmann <dh.herrmann@...il.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	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()

On Thu, 20 Mar 2014 16:12:54 +0100
David Herrmann <dh.herrmann@...il.com> wrote:

> Hi
> 
> On Thu, Mar 20, 2014 at 3:41 PM, One Thousand Gnomes
> <gnomes@...rguk.ukuu.org.uk> wrote:
> > I think you want two things at minimum
> >
> > owner to seal
> > root can always override
> 
> Why should root be allowed to override?

Because root can already override it by say mmapping the kernel memory
and patching. It also tends to be valuable for debugging horrible
problems with complex systems.

Imposing fake restrictions on root just causes annoyance when doing stuff
like debugging but doesn't actually change the security situation.
> 
> I'm fine with F_SET/GET_SEALS. But given you suggested requiring
> MFD_ALLOW_SEALS for sealing, I don't see why we couldn't limit this
> interface entirely to memfd_create().

But if someone does find a non memfd use for it then it's useful not to
have to go "this fnctl for memfd, that fnctl for the other"

Just planning ahead.


> > Whether you want some way to undo a seal without an exclusive reference as
> > the file owner is another question.
> 
> No. You are never allowed to undo a seal but with an exclusive
> reference. This interface was created for situations _without_ any
> trust relationship. So if the owner is allowed to undo seals, the
> interface doesn't make any sense. The only options I see is to not
> allow un-sealing at all (which I'm fine with) or tracking users (which
> is way too much overhead).

Ok - that makes sense
--
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/