Re: seccomp for 2.6.11-rc1-bk8

[Valdis . Kletnieks]

On Sun, 23 Jan 2005 01:52:13 +0100, Andrea Arcangeli said:

> Why should I be kidding? The client code I'm doing, has to be at least as secure

Maybe in your estimation it *has* to be that secure.  However, actual experience
with other operating systems indicate that the mail programs and web browsers
have *higher* security requirements than ssh - because ssh can afford to trust
legitimate users, while MUAs and browsers have to protect the system against
actions taken by legitimate users.

> as ssh and the firewall code, what else has to be more secure than that?

Mail programs, web browsers, and I'm sure there's plenty of applications in
the various Three Letter Agencies that want even more security.

It's a poor idea to confuse "secure" with "can't break out of the sandbox".

> Nor ssh nor the firewall code depends on ptrace for their security. The

And they don't even depend on seccomp or ptrace for the security either...

> Once seccomp is in, I believe there's a chance that security people uses
> it for more than Cpushare while I don't think there's a chance you'll

Security people probably won't be interested, specifically because it's
way too inflexible.  Very few real-life applications can be made to fit
into a "open all the files you might need, then shut yourself into a 
read/write syscalls only" model.

In fact, a case could be made that the unnatural contortions needed to
restructure applications into a seccomp model actually *decrease* the
overall security, because of more complicated setup code being more
vulnerable to attack.  Also, the fact that you need to keep open() out
of the permitted set for seccomp to make any sense means that you need to
open all the possible files up front.  So now you're handing the program
*more* access to files than they should....

> see security people using ptrace_syscall hardcoding the syscall numbers

Oh, come *ON*, Andrea.  This is a red herring and you *know* it.  The only
people who will be hardcoding syscall numbers are the same idiots that
hardcoded capability masks instead of "#include <linux/capability.h>" and
using the CAP_* defines.

> in every userland app out there that may have to parse untrusted data
> with potentially buggy bytecode (i.e. decompression bytecode etc..).

And if a filename has a runtime dependency on the untrusted data (consider
any sort of web server or browser or mail program or anything else that
accepts a "suggested filename" as input), things get very difficult very quickly.

I can pass ptrace a SYSCALL_OPEN, and then call my untrusted code, and then
look at the filename at runtime and see if there's something hinky going on.
I can even apply heuristics like "The first file opened should be THIS one,
then THOSE 4 shared libraries in order, then THIS file, and then the NEXT file
is dependent on user input, but has to start with $USER/tmp/workdir, and then
there's two other opens of files X and Y, and then no others should happen".
Using seccomp, you don't get that choice.  You either have to jump through
hoops to get all that set up beforehand, or allow open() in all its glory.

Attachment: pgp00000.pgp
Description: PGP signature