[RFC] Syntax Proposal for Seccomp Filters in Upstart

[Steve Langasek]

Hi James,

On Fri, Dec 14, 2012 at 02:35:01PM +0000, James Hunt wrote:
> Other thoughts:

> - What happens in a scenario where multiple system calls have been
> specified, but only a subset are available on the platform the job is
> running on?

> Presumably, the only safe option would be to fail to start the job. If so,
> we'd need to find a way to notify the admin as to why the job is not
> starting (which could just be to document that when first
> developing/testing a new job using the seccomp-filter, ensure Upstart is
> in debug mode).

FWIW I think this is the wrong question to ask.  There's nothing unsafe
about ignoring a seccomp filter declaration for a syscall that's not
*supported* on the platform the job is running on; if the syscall is
unsupported, any attempt to call it will return ENOSYS, so there's nothing
to be filtered.  Isn't the problem when we have a seccomp filter declaration
for a syscall that *upstart* doesn't know about for this platform, and thus
can't map to a numeric value?

That means that if you declare a filter for syscalls that upstart doesn't
know about (via a library or otherwise) for the current architecture, you
should fail closed and refuse to run the job since we can't do what the user
is asking for.  But as long as the rule can be parsed into a filter and the
kernel accepts it, we shouldn't need to worry about whether the syscall is
implemented on the current architecture, should we?

> - What if the syscall is known, but cannot be filtered on by the currently
> running kernel? (running back-level kernel with newer libc / seccomp libs,
> or running in a chroot environment)

Is that actually a real concern?  Don't seccomp filters apply equally to all
syscalls as long as seccomp support is present?

> 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).

In this scenario, since it's the host system's init (upstart 1.7)
responsible for parsing the job files, if the host system can't map the
syscall name then the job is invalid and shouldn't be started.  So the right
answer, if you need to be able to deploy upstart jobs referencing syscalls
that are unknown to the host init, would seem to be to use a container or a
VM.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/upstart-devel/attachments/20121217/da4cdef3/attachment.pgp>