Thread (53 messages) 53 messages, 8 authors, 2012-02-27

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

From: Indan Zupancic <hidden>
Date: 2012-02-22 23:46:43
Also in: linux-arch, lkml

On Wed, February 22, 2012 20:47, Will Drewry wrote:
On Wed, Feb 22, 2012 at 8:23 AM, Ben Hutchings
quoted
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

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help