unexpected syscall failures

unexpected syscall failures

[Justin Cormack]

[-- Attachment #1: Type: text/plain, Size: 749 bytes --]

I noticed that in some places we assume some system calls will not fail,
one example being in nice that I was looking at the other day, but there
are others:

return setpriority(PRIO_PROCESS, 0, getpriority(PRIO_PROCESS, 0)+inc);

Now in Linux you can use security frameworks (eg type 2 seccomp) to make
any system call fail. Do we want to program defensively around these cases?
(In the case of seccomp I think most people use it to abort the program not
error, but you can).

I am inclined to think that if someone makes getpid fail they deserve
anything they get. I can't see any security issues, just some potentially
confusing behaviour, eg here nice might succeed (but set errno) if
getpriority fails. But testing does have downsides.

Justin

[-- Attachment #2: Type: text/html, Size: 1319 bytes --]

Re: unexpected syscall failures

[Rich Felker]

On Tue, Apr 16, 2013 at 09:02:31AM +0100, Justin Cormack wrote:
> I noticed that in some places we assume some system calls will not fail,
> one example being in nice that I was looking at the other day, but there
> are others:
> 
> return setpriority(PRIO_PROCESS, 0, getpriority(PRIO_PROCESS, 0)+inc);
> 
> Now in Linux you can use security frameworks (eg type 2 seccomp) to make
> any system call fail. Do we want to program defensively around these cases?
> (In the case of seccomp I think most people use it to abort the program not
> error, but you can).
> 
> I am inclined to think that if someone makes getpid fail they deserve
> anything they get. I can't see any security issues, just some potentially
> confusing behaviour, eg here nice might succeed (but set errno) if
> getpriority fails. But testing does have downsides.

Yes, I'm aware of the issue and don't intend to address it. If you
take an interface that has no reason to fail (e.g. something that just
reads process-local information) and make it fail, you deserve what
you get. As far as I'm concerned, Linux security modules have a
serious security design flaw: they should not be able to deny
arbitrary syscalls (which can actually make security worse, in cases
like this) but rather deny access to resources on a more abstract
level.

Note that even if we handled the case where interfaces fail in
situations like the example you gave, that only deals with a tiny
fraction of the problem. There are much bigger issues -- for example,
in some cases, it may be impossible for the program to make forward
progress if a syscall which should not be able to fail has failed. The
best example I can think of right off is sigprocmask: if an interface
has to temporarily block signals to do its job, and can't unblock them
before returning, it has left the process in an inconsistent and
possibly-dangerous state. There are also probably places where forward
progress is impossible when getpid fails, or at least where it's
impossible to report the error (and thus the program, if it continued
running, would be running on incorrect assumptions). Another great
example is _exit -- we actually go into an infinite loop if the _exit
syscall fails, just in case somebody breaks the kernel that way, but
there's definitely nothing correct that the program can do.

Basically, to make any sort of correct program that interacts with the
system or the outside world in nontrivial ways, operations which "back
out" or provide essential status information the program might need
must be unable-to-fail. Otherwise you can get stuck in situations
where no forward progress is possible. So the short answer is that
musl is designed with the intent of using it to make correct, robust
programs, and if somebody has intentionally broken the system so that
it cannot be used in a correct and robust way, that's their fault.

Rich