seccomp filters: Why kill?

[Jamie Strandboge]

On Mon, 2016-04-04 at 08:23 -0400, Kyle Fazzari wrote:

 
Often times the syscalls being made aren't strictly required (e.g. MySQL
trying to control its thread priorities with `setpriority()`), which
typically leads to my starting with (2) and moving to (3).



FYI, this particular syscall is going to be allowed soon once seccomp argument
filtering lands, which should be before 16.04 release.


Every time I do (3) however, I get the same question: "Why does Snappy
use SECCOMP_RET_KILL instead of SECCOMP_RET_ERRNO?[1]" My only response
is "I don't know." I'd like to stop saying that, thus this email :) .

To make sure we're on the same page, Snappy's ubuntu-core-launcher uses
libseccomp to load the filters, which it initializes with
SCMP_ACT_KILL[2], which means that when a non-whitelisted syscall is
made the caller is immediately killed with no chance to recover.
Contrast this to SCMP_ACT_ERRNO which would allow for such syscalls to
fail gracefully and be handled by the caller. For example, the code in
MySQL would have handled this with no changes by printing a warning
about being unable to change the priority-- perfect. But since Snappy
uses SCMP_ACT_KILL it requires a code change to never attempt the call
in the first place.

This makes packaging snaps harder than it seems it needs to be, so I
feel like there must be a good reason for it.




The decision on which to use (KILL vs ERRNO) was an active one back in Capetown 2014
sprint (iirc), but perhaps it is time to revisit it based on this feedback.
AppArmor uses deny and log so to me it makes some sense to do the same with
seccomp.

-- 
Jamie Strandboge             | http://www.canonical.com


-- 
Jamie Strandboge             | http://www.canonical.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/snappy-devel/attachments/20160404/914cebd0/attachment.pgp>