[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
