linux-kernel - Re: [PATCH 2/3] [RFC] seccomp: give BPF x32 bit when restoring x32 filter

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: <1405095813.2357.3.camel@flatline.rdu.redhat.com>
Date:	Fri, 11 Jul 2014 12:23:33 -0400
From:	Eric Paris <eparis@...hat.com>
To:	Paul Moore <pmoore@...hat.com>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	Richard Guy Briggs <rgb@...hat.com>, linux-audit@...hat.com,
	linux-kernel@...r.kernel.org, Al Viro <aviro@...hat.com>,
	Will Drewry <wad@...omium.org>
Subject: Re: [PATCH 2/3] [RFC] seccomp: give BPF x32 bit when restoring x32
 filter

On Fri, 2014-07-11 at 12:21 -0400, Paul Moore wrote:
> On Friday, July 11, 2014 12:16:47 PM Eric Paris wrote:
> > On Fri, 2014-07-11 at 12:11 -0400, Paul Moore wrote:
> > > On Thursday, July 10, 2014 09:06:02 PM H. Peter Anvin wrote:
> > > > Incidentally: do seccomp users know that on an x86-64 system you can
> > > > recevie system calls from any of the x86 architectures, regardless of
> > > > how the program is invoked?  (This is unusual, so normally denying those
> > > > "alien" calls is the right thing to do.)
> > > 
> > > I obviously can't speak for all seccomp users, but libseccomp handles this
> > > by checking the seccomp_data->arch value at the start of the filter and
> > > killing (by default) any non-native architectures.  If you want, you can
> > > change this default behavior or add support for other architectures (e.g.
> > > create a filter that allows both x86-64 and x32 but disallows x86, or any
> > > combination of the three for that matter).
> > 
> > Maybe libseccomp does some HORRIFIC contortions under the hood, but the
> > interface is crap...  Since seccomp_data->arch can't distinguish between
> > X32 and X86_64.  If I write a seccomp filter which says
> > 
> > KILL arch != x86_64
> > KILL init_module
> > ALLOW everything else
> > 
> > I can still call init_module, I just have to use the X32 variant.
> > 
> > If libseccomp is translating:
> > 
> > KILL arch != x86_64 into:
> > 
> > KILL arch != x86_64
> > KILL syscall_nr >= 2000
> > 
> > That's just showing how dumb the kernel interface is...   Good for you
> > guys, but the kernel is just being dumb   :)
> 
> You're not going to hear me ever say that I like how the x32 ABI was done, it 
> is a real mess from a seccomp filter point of view and we have to do some 
> nasty stuff in libseccomp to make it all work correctly (see my comments on 
> the libseccomp-devel list regarding my severe displeasure over x32), but 
> what's done is done.
> 
> I think it's too late to change the x32 seccomp filter ABI.

So we have a security interface that is damn near impossible to get
right.  Perfect.

I think this explains exactly why I support this idea.  Make X32 look
like everyone else and put these custom horrific hacks in seccomp if we
are unwilling to 'do it right'

Honestly, how many people are using seccomp on X32 and would be horribly
pissed if we just fixed it?

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