implement 'complain mode' in seccomp for developer mode with snaps

Bug #1567597 reported by Jamie Strandboge on 2016-04-07
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Snappy
Medium
Tyler Hicks
libseccomp (Ubuntu)
Undecided
Unassigned

Bug Description

A requirement for snappy is that a snap may be placed in developer mode which will put the security sandbox in complain mode such that violations against policy are logged, but permitted. In this manner learning tools can be written to parse the logs, etc and make developing on snappy easier.

Unfortunately with seccomp only SCMP_ACT_KILL logs to dmesg and while we can set complain mode to permit all calls, they are not logged at this time. I've discussed this with upstream and we are working together on the approach. This may require a kernel patch and an update to libseccomp, to filing this bug for now as a placeholder and we'll add other tasks as necessary.

UPDATE: ubuntu-core-launcher now supports the '@complain' directive that is a synonym for '@unrestricted' so people can at least turn on developer mode and not be blocked by seccomp. Proper complain mode for seccomp needs to still be implemented (this bug).

Changed in snappy:
status: New → Confirmed
summary: - support 'complain mode' for developer mode with snaps
+ implement 'complain mode' in seccomp for developer mode with snaps
description: updated
Seth Arnold (seth-arnold) wrote :

What's the benefit of a complain mode for seccomp in snappyland? AppArmor denials can usually be addressed by changing ./configure flags or hardcoded paths or something, but there's not much to be done for "this application uses syscalls we forbid" except eliding the syscalls from the source, right?

Allowing it to run without trouble feels like it provides a false sense of progress or control when none is intended.

Thanks

Michael Vogt (mvo) on 2016-04-20
Changed in snappy:
importance: Undecided → Medium
Changed in libseccomp (Ubuntu):
status: New → Confirmed
Zygmunt Krynicki (zyga) wrote :

Is there a bug about is in upstream libseccomp or kernel bugzilla?

Tyler Hicks (tyhicks) wrote :

No, there's not an upstream kernel bug. The kernel bugzilla isn't used much and something like this typically plays out on the mailing list.

It may be useful to create a libseccomp issue but I'm not ready to do that until I have a better idea about the kernel changes that are needed.

Changed in snappy:
assignee: nobody → Tyler Hicks (tyhicks)
status: Confirmed → In Progress
Michael Vogt (mvo) wrote :

Does it make sense to move this back from "in-progress" to "triaged"?

Tyler Hicks (tyhicks) wrote :

No, it is actually in-progress now:

http://lkml.iu.edu/hypermail/linux/kernel/1701.0/00452.html
http://lkml.iu.edu/hypermail/linux/kernel/1701.0/00472.html
https://github.com/seccomp/libseccomp/pull/64

Vacation time and a sprint last week have kept me from working on a second revision of the patches but that should happen this week.

Michael Vogt (mvo) wrote :

\o/ Thank you Tyler!

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers