[RFC] Syntax Proposal for Seccomp Filters in Upstart

[David Gaarenstroom]

> I think that allowing the specification of an errno as a numeric rather than a
> symbol should be avoided if possible. So, 'EACCESS' is fine, but allowing '13'
> to represent nominally the same value is potentially ambiguous.

I'd allow a number as a fall-back, but I'd prefer the textual errno
just as much as you do, but it may not cover all possible errno's. The
seccomp BPF allows a larger scale of numeric values (0-0x1FFF as far
as I know, beyond that seccomp gets weird even though there's room for
an unsigned 16-bit value)...


> Upstart supports running jobs from within a chroot environment. So imagine a
> system running Upstart 1.7 but which hosts a chroot that uses Upstart 1.8. The
> host environment only has knowledge of the system calls that the actual running
> kernel provides (ie libc and the kernel version and Upstart's seccomp handling
> are all in sync). However, in the chroot, jobs may attempt to use a newer
> syscall than is provided by the running kernel (since they may have been
> developed on a non-chroot system with a newer kernel).
>
> So it sounds like you're proposing that the seccomp layer will identify the
> unknown syscall and discard it?

Normally the kernel will discard it since it does not know the syscall
number. "syscall(320);" seems to return with -1 and set errno to 26
(ETXTBSY) for amd64. (I expected ENOSYS.)

If you're using a syscall-number not yet known to an older kernel than
the one the chroot is targeted for, that program is not going to run
on that kernel, with or without a chroot. But if a seccomp rules
denies unlisted syscalls, new syscalls will be denied even before
handed to syscall, so it is treated differently...On the other hand if
unknown syscalls are implicitly allowed (seccomp-filter start with
"~") the "unknown" syscall number is approved, passed to the kernel
and the kernel will handle it with an errno.

I can imagine that when the kernel API changes, a program or libraries
such as libc may first try to probe a syscall existence by passing the
syscall-number and look at errno whether or not it failed or look at
the kernel version and not even try... I'm going to have to find such
an example first. And I don't know how likely the kernel is going to
add new syscalls that really interfere and how soon these changes are
supported by new software, I'll try to find out...

I did look at arch/x86/syscalls/syscall_*.tbl and
include/asm-generic/unistd.h and arch/x86/include/asm/seccomp*.h
(which seem to be the only include files containing #defines for (x86
related) syscall numbers) and it seems these changed in the past:
"__NR_kcmp" was added in linux-3.5
"__NR_process_vm_readv" and "__NR_process_vm_writev" were added in linnux-3.2
"__NR_sendmmsg" was added in linux-3.0

The __NR_kcmp is indeed unknown in Ubuntu 12.04LTS amd64, running a
3.6.10 kernel.


Anyway, just like with errno we could also allow a numeric value as
fall-back for future syscalls, I hope that addresses your concerns?


Kind regards,
David G