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


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