sandbox: Update known syscalls to kernel 3.17

sandbox: Update known syscalls to kernel 3.17

Updated Arm, Mips, x86_32 and x86_64 syscall defines
to match the latest kernel 3.17 at the time of this commit.

BUG=406123
TEST=sandbox_linux_unittests

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=291315

[leecam, 2014-08-21 22:23:12]

Had a chat with Robert and we decided to split the syscall defining from
https://codereview.chromium.org/487143003/ &
https://codereview.chromium.org/494743003/ into a separate CL updating all the
architectures to include all the current syscalls.

[jln (very slow on Chromium), 2014-08-21 23:36:05]

lgtm with a small nit.

https://chromiumcodereview.appspot.com/493603003/diff/1/sandbox/linux/seccomp...
File sandbox/linux/seccomp-bpf-helpers/syscall_sets.cc (right):

https://chromiumcodereview.appspot.com/493603003/diff/1/sandbox/linux/seccomp...
sandbox/linux/seccomp-bpf-helpers/syscall_sets.cc:849: case __NR_sched_setattr:
Please, alphabetize.

[jln (very slow on Chromium), 2014-08-21 23:38:01]

Oops, I read a bit too fast. Not lgtm, since I don't think we should allow
seccomp(). Was there a specific reason for allowing it?

https://chromiumcodereview.appspot.com/493603003/diff/1/sandbox/linux/seccomp...
File sandbox/linux/seccomp-bpf-helpers/baseline_policy.cc (right):

https://chromiumcodereview.appspot.com/493603003/diff/1/sandbox/linux/seccomp...
sandbox/linux/seccomp-bpf-helpers/baseline_policy.cc:56:
SyscallSets::IsSeccomp(sysno);
We should not allow this system call in general. This opens a lot of attack
surface.

[leecam, 2014-08-21 23:57:13]

Fixed it up...

https://codereview.chromium.org/493603003/diff/1/sandbox/linux/seccomp-bpf-he...
File sandbox/linux/seccomp-bpf-helpers/baseline_policy.cc (right):

https://codereview.chromium.org/493603003/diff/1/sandbox/linux/seccomp-bpf-he...
sandbox/linux/seccomp-bpf-helpers/baseline_policy.cc:56:
SyscallSets::IsSeccomp(sysno);
Yeah I guess once its set we shouldn't allow it again. I've changed it to
disallow. 

On 2014/08/21 23:38:01, jln wrote:
> We should not allow this system call in general. This opens a lot of attack
> surface.

[jln (very slow on Chromium), 2014-08-22 00:05:17]

lgtm with minor nits.

https://chromiumcodereview.appspot.com/493603003/diff/20001/sandbox/linux/sec...
File sandbox/linux/seccomp-bpf-helpers/baseline_policy.cc (right):

https://chromiumcodereview.appspot.com/493603003/diff/20001/sandbox/linux/sec...
sandbox/linux/seccomp-bpf-helpers/baseline_policy.cc:167: return Error(EPERM);
I know that this function is getting quite messy, but normally the order should
be:

- What we allow
- What we restrict
- What we EPERM
- What crashes.

Do you mind moving this below, with the other EPERM stuff?

https://chromiumcodereview.appspot.com/493603003/diff/20001/sandbox/linux/sec...
File sandbox/linux/seccomp-bpf-helpers/syscall_sets.cc (right):

https://chromiumcodereview.appspot.com/493603003/diff/20001/sandbox/linux/sec...
sandbox/linux/seccomp-bpf-helpers/syscall_sets.cc:850: case __NR_sched_setattr:
Alphabetize this one as well :)

[leecam, 2014-08-22 00:07:52]

The CQ bit was checked by leecam@chromium.org

[commit-bot: I haz the power, 2014-08-22 00:09:15]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/leecam@chromium.org/493603003/60001

[commit-bot: I haz the power, 2014-08-22 02:02:20]

Committed patchset #4 (60001) as 291315