linux-kernel - Re: [RFC,PATCH 1/2] seccomp_filters: 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: <e6bc7a5b7bca20855c6e7b9c66e9662e.squirrel@webmail.greenhost.nl>
Date:	Wed, 18 Jan 2012 05:47:11 +0100
From:	"Indan Zupancic" <indan@....nu>
To:	"Will Drewry" <wad@...omium.org>
Cc:	"Kees Cook" <keescook@...omium.org>,
	"Oleg Nesterov" <oleg@...hat.com>, linux-kernel@...r.kernel.org,
	john.johansen@...onical.com, serge.hallyn@...onical.com,
	coreyb@...ux.vnet.ibm.com, pmoore@...hat.com, eparis@...hat.com,
	djm@...drot.org, torvalds@...ux-foundation.org,
	segoon@...nwall.com, rostedt@...dmis.org, jmorris@...ei.org,
	"Roland McGrath" <mcgrathr@...gle.com>
Subject: Re: [RFC,PATCH 1/2] seccomp_filters: system call filtering using
 BPF

On Tue, January 17, 2012 21:42, Will Drewry wrote:
> On Tue, Jan 17, 2012 at 2:34 PM, Kees Cook <keescook@...omium.org> wrote:
>> If this turns out to be expensive, it might be possible to break it up
>> and load the arguments on demand (and cache them); i.e. have
>> load_pointer() or similar notice when it is about to access something
>> other than bpf_data.syscall_nr.
>
> Makes perfect sense!  In theory (as a few other people pointed this
> out off list), it is entirely possible to never populate any data for
> load_pointer except an optional cache.  Just provide a custom
> load_pointer that knows to take the offset return the syscall nr or
> the args or some slice of the returned data.

That sounds like a very good idea. I don't think the cache is needed
because an argument is usually only checked once.

> This is even easier if the struct looks like:
> struct {
>   int nr;
>   union {
>     uint32_t args32[6];
>     uint64_t args64[6];
>   }
> };
>
> since you can just use the offset without doing any endian-based
> splitting.

But then the filter has to know if it's 32 or 64-bit, and still know about
endianness, or am I missing something? It seems better to provide the upper
32 bits seperately so code that cares about it can check it.

> Another suggestion (thanks roland!) was to add
>   int syscall_arch;
> to the struct populated with the AUDIT_ARCH_* defines.  This would
> help the case Indan was worried about -- portable filter programs.

I never heard of AUDIT_ARCH* before, so I have no idea how it could be
used. Do you have a documentation pointer?

A quick scan through the kernel code seems it tells what arch the system is.

Such flag could be used to use the syscall number depending on what arch it
is, but I'm not sure that would make things cleaner or easier for anyone.
Still, it won't hurt to have it and at least gives that option.

> It looks like there'd be some cross-arch plumbing to make the
> AUDIT_ARCH_ data available, but not too bad.
>
> Seem sane? I'm headed down this path now and I think it'll work out
> assuming there aren't major objections to the syscall_arch piece.

I'm not sure about the union, and no objections to syscall_arch if it just
tells what arch it is.

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/