seccomp filters: Why kill?

[Jamie Strandboge]

On Tue, 2016-04-05 at 09:01 -0500, Jamie Strandboge wrote:
> On Tue, 2016-04-05 at 08:15 +0200, Didier Roche wrote:
> > 
> > Le 04/04/2016 21:33, Jamie Strandboge a écrit :
> > > 
> > > 
> > > On Mon, 2016-04-04 at 14:56 -0400, Kyle Fazzari wrote:
> > > > 
> > > > 
> > > > On 04/04/2016 02:03 PM, Jamie Strandboge wrote:
> > > > > 
> > > > > 
> > > > > 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.
> > > > I agree. I also imagine upstream contributions to deal with ERRNO will
> > > > be viewed as making things more robust rather than "make this work with
> > > > Snappy." Do you remember the original rational for using KILL?
> > > > 
> > > I do not; perhaps others on this list do.
> > Just to add another use case, I got exactly the same issue (with
> > setpriority even! ;)) on ffmepg, where the error is dealt internally in
> > code, but we didn't give it a chance to handle that exception by
> > returning an ERRNO instead of quickly killing it.
> > 
> > I think that most of upstream code is handling those kind of try/expect
> > cases and it would be better in case of denials, to let them handling it
> > (maybe their handling will be then exit(1), fine in that case)? This is
> > typically what is used with the new dynamic security permissions on
> > Android for instance.
> > 
> I'm inclined to just queue this up in the next launcher upload.
> 
FYI, this will not be in the next upload as seccomp doesn't currently support
logging with ERRNO(EPERM). I've discussed this with upstream and they are
considering updating seccomp for this. If that happens, we'll need to add this
patch to the list of required patches for snappy kernels, update libseccomp and
then adjust the launcher.

Note, the lack of seccomp logging also has an impact on developer mode since
only KILL is logged. I'm discussing this with upstream as well.

-- 
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/20160407/c3fe3a9e/attachment.pgp>