Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752529AbdDJTWt (ORCPT ); Mon, 10 Apr 2017 15:22:49 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:51234 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752046AbdDJTWr (ORCPT ); Mon, 10 Apr 2017 15:22:47 -0400 Subject: Re: [PATCH v3 0/4] Improved seccomp logging To: Andy Lutomirski References: <1487043928-5982-1-git-send-email-tyhicks@canonical.com> Cc: Kees Cook , Paul Moore , Eric Paris , Will Drewry , linux-audit@redhat.com, "linux-kernel@vger.kernel.org" , John Crispin , Linux API From: Tyler Hicks Message-ID: <087fa5ee-ce6d-456d-610f-2a0855cdd50b@canonical.com> Date: Mon, 10 Apr 2017 14:22:28 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="IBw2d1gRR4jdqfbLSqNKelqb83oP6qUS0" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 7662 Lines: 175 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IBw2d1gRR4jdqfbLSqNKelqb83oP6qUS0 Content-Type: multipart/mixed; boundary="RU86GLwT9mELkRKPq40mi5o3Ube5Jprfe"; protected-headers="v1" From: Tyler Hicks To: Andy Lutomirski Cc: Kees Cook , Paul Moore , Eric Paris , Will Drewry , linux-audit@redhat.com, "linux-kernel@vger.kernel.org" , John Crispin , Linux API Message-ID: <087fa5ee-ce6d-456d-610f-2a0855cdd50b@canonical.com> Subject: Re: [PATCH v3 0/4] Improved seccomp logging References: <1487043928-5982-1-git-send-email-tyhicks@canonical.com> In-Reply-To: --RU86GLwT9mELkRKPq40mi5o3Ube5Jprfe Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 04/10/2017 10:57 AM, Andy Lutomirski wrote: > On Fri, Apr 7, 2017 at 3:16 PM, Tyler Hicks wro= te: >> On 02/22/2017 12:46 PM, Kees Cook wrote: >>> On Thu, Feb 16, 2017 at 3:29 PM, Kees Cook wr= ote: >>>> On Wed, Feb 15, 2017 at 7:24 PM, Andy Lutomirski wrote: >>>>> On Mon, Feb 13, 2017 at 7:45 PM, Tyler Hicks wrote: >>>>>> This patch set is the third revision of the following two previous= ly >>>>>> submitted patch sets: >>>>>> >>>>>> v1: http://lkml.kernel.org/r/1483375990-14948-1-git-send-email-tyh= icks@canonical.com >>>>>> v1: http://lkml.kernel.org/r/1483377999-15019-2-git-send-email-tyh= icks@canonical.com >>>>>> >>>>>> v2: http://lkml.kernel.org/r/1486100262-32391-1-git-send-email-tyh= icks@canonical.com >>>>>> >>>>>> 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 noi= sy 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 configurati= on >>>>> (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 makin= g >>>> 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 lik= e >>> 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 application= s >> to make it clear to the developers and the users that the sandboxed >> application is bumping into the sandbox walls. Developers will know wh= y >> 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. Thes= e >> 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 differen= t >> 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: >=20 > 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 --RU86GLwT9mELkRKPq40mi5o3Ube5Jprfe-- --IBw2d1gRR4jdqfbLSqNKelqb83oP6qUS0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJY69t8AAoJENaSAD2qAscKXucQAMVP2VwnRaE1uKnrbQg2HHV4 9231wr7VmujMfC3slDuzJVoj19i9ZIKbzDIujc9YbWC17pJlTeooLQM5UnRJjDPW TGU7WRmmzUI+o7igw5afMMlr6riLDjlJPp2ZIzvaCjwzwLvwxh2pJXsYIbesLcW7 ESlq/3PavChZChSB1M1WLUavJX6EtNSVYuAHwmuqZVXhyyzWDE9Vy9HbaCyTDG7l mPZSPmBaZ2aPX9SfY8nnAV+y5EHT84S4oAV3wOqZ7W9d1RvPwlOabPYFvQNTfmE7 E10fKgXNerwSsmjULPHoSldrjKLmFZi4MZJA+n3cc7wbICOD3yGk2C1y4O6omNsT ur/hpuBOr4dTCBGNKZtBlSC289Y6m1xuc7VMwIL7JFigMoD6OAWmM4A+NMjMlQMS xLYsaxx9rJkgSefjoNAnRCuUwfThcUUooIqq7um7zUcVRcGgEc8JXwlD7aYecNnN /cNeKckubd0GxMY2OygOz31KVPOHkah8f4o1QD/lCbm8EsNj/QkjmUDCG28fcZXu dB3eYir898UATV/ZNGRbYBWOkdpyTAqlcV/9je7R1MimgRXQoJviCLcYHMjzGOaK bJ3DqtbIMp10+aVR2VdCmLbBSgzSV8H5eOcDp+sjRYy52NW2h9A4Fst7+foxLdqV OlDxrUQHzbr800nM3UNR =lIWm -----END PGP SIGNATURE----- --IBw2d1gRR4jdqfbLSqNKelqb83oP6qUS0--