1724098 - seccomp policy should account for umask's infallibility

Status: NEW

(Core :: Security: Process Sandboxing, defect, P5)

Description

[Jed Davis [:jld] ⟨⏰|UTC-8⟩ ⟦he/him⟧]

The umask system call is documented as always succeeding and never returning an error. The system call stub in glibc simply returns immediately after the syscall instruction, without the usual sign test. Therefore, if we try to return an error for it in the seccomp-bpf policy, the negated error number will be returned to userspace and treated as if it were the old umask value. Currently, we'll generally return -ENOSYS on non-Nightly builds (which, at least on amd64, is effectively 0732 which is not a very useful umask).

There's essentially no valid reason for a multithreaded program (or library code that might be used in one) to ever call umask; however, on the other hand, for a sandboxed process which can access the filesystem only via an out-of-process broker, it has no effect anyway, so in theory there's no harm in allowing it.

(Annoying details: we currently allow umask for content processes at sandbox levels lower than 4, because of PulseAudio; the current default level is 4, meaning that we no longer allow it by default. Content processes at level 1 do access the filesystem directly, but that configuration is only for testing and has a tendency to break without being noticed, so maybe we should get rid of it.)