linux-kernel - Re: [PATCH v10 05/11] seccomp: add system call filtering using BPF

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: <d1dbcb9c671fea502f79519749095fd5.squirrel@webmail.greenhost.nl>
Date:	Thu, 23 Feb 2012 00:03:30 +0100
From:	"Indan Zupancic" <indan@....nu>
To:	"Ben Hutchings" <bhutchings@...arflare.com>
Cc:	"Will Drewry" <wad@...omium.org>, linux-kernel@...r.kernel.org,
	linux-arch@...r.kernel.org, linux-doc@...r.kernel.org,
	kernel-hardening@...ts.openwall.com, netdev@...r.kernel.org,
	x86@...nel.org, arnd@...db.de, davem@...emloft.net, hpa@...or.com,
	mingo@...hat.com, oleg@...hat.com, peterz@...radead.org,
	rdunlap@...otime.net, mcgrathr@...omium.org, tglx@...utronix.de,
	luto@....edu, eparis@...hat.com, serge.hallyn@...onical.com,
	djm@...drot.org, scarybeasts@...il.com, pmoore@...hat.com,
	akpm@...ux-foundation.org, corbet@....net, eric.dumazet@...il.com,
	markus@...omium.org, keescook@...omium.org
Subject: Re: [PATCH v10 05/11] seccomp: add system call filtering using BPF

On Wed, February 22, 2012 15:23, Ben Hutchings wrote:
> On Wed, 2012-02-22 at 09:19 +0100, Indan Zupancic wrote:
> [...]
>> Alternative approach: Tell the arch at filter install time and only run the
>> filters with the same arch as the current system call. If no filters are run,
>> deny the systemcall.
>>
>> Advantages:
>>
>> - Filters don't have to check the arch every syscall entry.
>>
>> - Secure by default. Filters don't have to do anything arch specific to
>>   be secure, no surprises possible.
>>
>> - If a new arch comes into existence, there is no chance of old filters
>>   becoming buggy and insecure. This is especially true for archs that
>>   had only one mode, but added another one later on: Old filters had no
>>   need to check the mode at all.
> [...]
>
> What about when there are multiple layers of restrictions?  So long as
> any one layer covers the new architecture, there is no default-deny even
> though the other layers might not cover it.

When I wrote the above I assumed this wouldn't be a big problem because
if filters allow prctl, they can check the arg flag for supported archs.
Or they can install a filter for all archs and do the arch check in there.
All under the assumption that allowing prctl is rare and if it's allowed,
it needs special checks anyway.

But having thought more about it, I fear sometimes needing such check may
be worse than checking the arch for each filter.

> I would have thought the way to make sure the architecture is always
> checked is to pack it together with the syscall number.

There is no default deny when passing the arch to the filter either,
nothing forces filters to check the arch.

But documenting that filters should always check the arch is simpler and
easier than telling them to check for unknown archs in prctl, or to do
something else obscure.

Greetings,

Indan


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