[Bug 3478] Default "kill" action of seccomp sandbox is fragile

[bugzilla-daemon at mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=3478

--- Comment #2 from Colin Watson <cjwatson at debian.org> ---
(In reply to Darren Tucker from comment #1)
> Arbitrarily failing syscalls that do not normally fail has been the
> source of serious security vulnerabilities in the past (eg
> CVE-2000-0506).  That's why the default action is "kill" instead of
> "fail" and others are considered on a case by case basis.

I don't think this is _not_ an issue, and I agree it requires care -
that's why I included the umask case - but I think we have more
problems the other way round.

> I think that's a pretty good argument that glibc should provide an
> interface that is usable by applications that does not have that
> layering violation.  Even just being able to specify the filters by
> libc function name rather than syscall name would help a lot,
> however I suspect doing that would be challenging given that the
> kernel and glibc are developed independently.

Sure, but there seems little appetite to do this with actually-existing
Linux and glibc (I certainly don't have time for that sort of
multi-year project), so where does that leave us?  Tracking syscall
minutiae forever doesn't seem appealing.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.