[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <60d94ae06f380ff088f6270c3a536ee9.squirrel@webmail.greenhost.nl>
Date: Thu, 23 Feb 2012 00:46:35 +0100
From: "Indan Zupancic" <indan@....nu>
To: "Will Drewry" <wad@...omium.org>
Cc: "Ben Hutchings" <bhutchings@...arflare.com>,
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 20:47, Will Drewry wrote:
> On Wed, Feb 22, 2012 at 8:23 AM, Ben Hutchings
>> I would have thought the way to make sure the architecture is always
>> checked is to pack it together with the syscall number.
I missed that suggestion, putting the syscall number and arch in one
data field would indeed make it harder to not check the arch.
> 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.
Using AUDIT_ARCH_ has the advantage that it contains the endianness and
width of the arch, which is crucial info for archs that support multiple
modes with the same arch. E.g. MIPS got:
#define AUDIT_ARCH_MIPS (EM_MIPS)
#define AUDIT_ARCH_MIPSEL (EM_MIPS|__AUDIT_ARCH_LE)
#define AUDIT_ARCH_MIPS64 (EM_MIPS|__AUDIT_ARCH_64BIT)
#define AUDIT_ARCH_MIPSEL64 (EM_MIPS|__AUDIT_ARCH_64BIT|__AUDIT_ARCH_LE)
So just EM_MIPS isn't enough info.
> 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?
No, it's not a safe assumption. E.g. look at arm_syscall() in
arch/arm/kernel/traps.c:
"0x9f0000 - 0x9fffff are some more esoteric system calls"
You could check if the filter read the 'arch' field and deny it if it
didn't when it returns though. Or check it in the filter check function.
Wouldn't be the nicest code ever, but it would give the same assurance
as packing it with the syscall number.
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.
