linux-kernel - Re: [RFC 1/1] seccomp: Add bitmask of allowed system calls.

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]

Date:	Thu, 7 May 2009 15:34:58 -0700
From:	Adam Langley <agl@...gle.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Frédéric Weisbecker <fweisbec@...il.com>,
	Tom Zanussi <tzanussi@...il.com>,
	Li Zefan <lizf@...fujitsu.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	linux-kernel@...r.kernel.org, markus@...gle.com
Subject: Re: [RFC 1/1] seccomp: Add bitmask of allowed system calls.

> That assessment is incorrect, there's no difference between safety
> here really.
>
> LSM cannot magically inspect user-space memory either when multiple
> threads may access it. The point would be to define filters for
> system call _arguments_, which are inherently thread-local and safe.

If I hook security_operations.socket_connect, I can validate the struct
sockaddr after the final copy_from_user. However, since the sockaddr lives in
userspace memory, if I try and validate it from ftrace SYSCALL_ENTER, I can't
know that it won't change before sys_connect reads it again.

Because of that, there are system calls which an LSM hook can safely accept
that an ftrace hook cannot. However, as you point out, any arguments passed in
registers are inheriently safe and these may be sufficiently powerful.

> There are two problems with the bitmap scheme, which i also
> suggested in a previous thread but then found it to be lacking:
>
> 1) enumeration: you define a bitmap. That will be problematic
>   between compat and native 64-bit (both have different syscall
>   vectors).

I /think/ it works out, but I've been bitten before with subtle 32/64 bit
compat issues and accept that it's a bit ugly.

> 2) flexibility. It's an on/off selection per syscall. With the
>   filter we have on, off, or filtered. That's a _whole_ lot more
>   flexible.

Absolutely.

Is there a git tree that I can pull this parsing code from?
(git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git
maybe?). I can patch in the seccomp-on-ftrace work and try building the
filtering on top of that. I'll see how it turns out anyway.

Thanks

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