[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABqD9hYRPQbAY2KejstrutEO_jXU3QgBB9og_ByAaFcXZx4GHg@mail.gmail.com>
Date: Wed, 22 Feb 2012 13:47:23 -0600
From: Will Drewry <wad@...omium.org>
To: Ben Hutchings <bhutchings@...arflare.com>
Cc: Indan Zupancic <indan@....nu>, 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, Feb 22, 2012 at 8:23 AM, Ben Hutchings
<bhutchings@...arflare.com> 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.
This is the biggest challenge with using the split-labeled approach. I
started with the first patches supporting compat and non-compat
side-by-side. It makes things complicated with inheritance. If you
have a parent that installed filters for arch=i386 and arch=x86_64,
then a child process installs a filter for arch=x86_64, its behavior
when spawned by that parent is that any i386 calls the parent allows
are allowed, but when it is spawned without any inherited filters, no
i386 calls would be allowed. This was part of the reason why I
abandoned that approach and went with locking the compat bit. I don't
think there is a clean way to support inheritance and
implicit-disallow without it being hideous. (I had tried it before
with annotations saying if a filter was inherited or self-created, but
that made the code much more complex for very little gain, imo.)
> I would have thought the way to make sure the architecture is always
> checked is to pack it together with the syscall number.
If the current patchset used the elf machine only and not the
AUDIT_ARCH_* that might be possible since e_machine is only 16 bits.
However, that would still assume that an arch wouldn't introduce a
syscall number above 65535 which is most likely not a safe assumption.
Am I wrong there?
thanks!
will
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.
