On 04/10/2017 10:57 AM, Andy Lutomirski wrote: > On Fri, Apr 7, 2017 at 3:16 PM, Tyler Hicks <tyhicks@xxxxxxxxxxxxx> wrote: >> On 02/22/2017 12:46 PM, Kees Cook wrote: >>> On Thu, Feb 16, 2017 at 3:29 PM, Kees Cook <keescook@xxxxxxxxxxxx> wrote: >>>> On Wed, Feb 15, 2017 at 7:24 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: >>>>> On Mon, Feb 13, 2017 at 7:45 PM, Tyler Hicks <tyhicks@xxxxxxxxxxxxx> wrote: >>>>>> This patch set is the third revision of the following two previously >>>>>> submitted patch sets: >>>>>> >>>>>> v1: http://lkml.kernel.org/r/1483375990-14948-1-git-send-email-tyhicks@xxxxxxxxxxxxx >>>>>> v1: http://lkml.kernel.org/r/1483377999-15019-2-git-send-email-tyhicks@xxxxxxxxxxxxx >>>>>> >>>>>> v2: http://lkml.kernel.org/r/1486100262-32391-1-git-send-email-tyhicks@xxxxxxxxxxxxx >>>>>> >>>>>> The patch set aims to address some known deficiencies in seccomp's current >>>>>> logging capabilities: >>>>>> >>>>>> 1. Inability to log all filter actions. >>>>>> 2. Inability to selectively enable filtering; e.g. devs want noisy logging, >>>>>> users want relative quiet. >>>>>> 3. Consistent behavior with audit enabled and disabled. >>>>>> 4. Inability to easily develop a filter due to the lack of a >>>>>> permissive/complain mode. >>>>> >>>>> I think I dislike this, but I think my dislikes may be fixable with >>>>> minor changes. >>>>> >>>>> What I dislike is that this mixes app-specific built-in configuration >>>>> (seccomp) with global privileged stuff (audit). The result is a >>>>> potentially difficult to use situation in which you need to modify an >>>>> app to make it loggable (using RET_LOG) and then fiddle with >>>>> privileged config (auditctl, etc) to actually see the logs. >>>> >>>> You make a good point about RET_LOG vs log_max_action. I think making >>>> RET_LOG the default value would work for 99% of the cases. >>> >>> Actually, I take this back: making "log" the default means that >>> everything else gets logged too, include "expected" return values like >>> errno, trap, etc. I think that would be extremely noisy as a default >>> (for upstream or Ubuntu). >>> >>> Perhaps RET_LOG should unconditionally log? Or maybe the logged >>> actions should be a bit field instead of a single value? Then the >>> default could be "RET_KILL and RET_LOG", but an admin could switch it >>> to just RET_KILL, or even nothing at all? Hmmm... >> >> Hi Kees - my apologies for going quiet on this topic after we spoke >> about it more in IRC. I needed to tend to other work but now I'm able to >> return to this seccomp logging patch set. >> >> To summarize what we discussed in IRC, the Chrome browser makes >> extensive use of RET_ERRNO, RET_TRACE, etc., to sandbox code that may >> not ever be adjusted to keep from bump into the sandbox walls. >> Therefore, it is unreasonable to enable logging of something like >> RET_ERRNO on a system-wide level where Chrome browser is in use. >> >> In contrast, snapd wants to set up "noisier" sandboxes for applications >> to make it clear to the developers and the users that the sandboxed >> application is bumping into the sandbox walls. Developers will know why >> their code may not be working as intended and users will know that the >> application is doing things that the platform doesn't agree with. These >> sandboxes will end up using RET_ERRNO in the majority of cases. >> >> This means that with the current design of this patch set, Chrome >> browser will either be unintentionally spamming the logs or snapd's >> sandboxes will be helplessly silent when both Chrome and snapd is >> installed at the same time, depending on the admin's preferences. >> >> To bring it back up a level, two applications may have a very different >> outlook on how acceptable a given seccomp action is and they may >> disagree on whether or not the user/administrator should be informed. >> >> I've been giving thought to the idea of providing a way for the >> application setting up the filter to opt into logging of certain >> actions. Here's a high level breakdown: > > At the risk of overcomplicating things, I think this issue may be a > decent argument for doing something more like what I suggested > earlier: let seccomp users emit loggable things and let their parents > (optionally) catch and handle those things. Then we get real scoping > rather than fiddling with bitmasks and hoping we get what we want to > see without generating massive log spam. Hi Andy - I remembered your proposal and considered it when I was writing up mine. I still feel like it is easier to get the logging bitmask right, if you even need to adjust the default bitmask, than to force parent processes to act as a relay for log messages. The logging bitmasks can easily be adjusted in debug builds or when a user specifies a runtime option to enable seccomp logging in a program that sets up filters. Another potential issue with the parent process handling the logging is that it isn't always possible when audit is in use. audit_log_user_message() requires CAP_AUDIT_WRITE (seems like CAP_AUDIT_CONTROL might also be required but I can't remember why) so unprivileged processes would have to divert their log messages elsewhere. Tyler
Attachment:
signature.asc
Description: OpenPGP digital signature
