From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tyler Hicks Subject: Re: [PATCH v3 0/4] Improved seccomp logging Date: Thu, 16 Feb 2017 13:37:18 -0600 Message-ID: <18b3f82e-c1a8-8110-6b45-0067da8ca87e@canonical.com> References: <1487043928-5982-1-git-send-email-tyhicks@canonical.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FEN2uKHgKv0kdio7EJ20VOK4PFtXQRtgE" Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Andy Lutomirski Cc: Paul Moore , Eric Paris , Kees Cook , Will Drewry , linux-audit@redhat.com, "linux-kernel@vger.kernel.org" , John Crispin List-Id: linux-audit@redhat.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FEN2uKHgKv0kdio7EJ20VOK4PFtXQRtgE Content-Type: multipart/mixed; boundary="cMEWcfeqMh0SS8jESuwVJTuF6F0IpXrTA"; protected-headers="v1" From: Tyler Hicks To: Andy Lutomirski Cc: Paul Moore , Eric Paris , Kees Cook , Will Drewry , linux-audit@redhat.com, "linux-kernel@vger.kernel.org" , John Crispin Message-ID: <18b3f82e-c1a8-8110-6b45-0067da8ca87e@canonical.com> Subject: Re: [PATCH v3 0/4] Improved seccomp logging References: <1487043928-5982-1-git-send-email-tyhicks@canonical.com> In-Reply-To: --cMEWcfeqMh0SS8jESuwVJTuF6F0IpXrTA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02/15/2017 09:24 PM, Andy Lutomirski wrote: > On Mon, Feb 13, 2017 at 7:45 PM, Tyler Hicks wr= ote: >> 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= @canonical.com >> v1: http://lkml.kernel.org/r/1483377999-15019-2-git-send-email-tyhicks= @canonical.com >> >> v2: http://lkml.kernel.org/r/1486100262-32391-1-git-send-email-tyhicks= @canonical.com >> >> The patch set aims to address some known deficiencies in seccomp's cur= rent >> logging capabilities: >> >> 1. Inability to log all filter actions. >> 2. Inability to selectively enable filtering; e.g. devs want noisy l= ogging, >> 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. >=20 > I think I dislike this, but I think my dislikes may be fixable with > minor changes. >=20 > 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. There's no need to fiddle with audictl. You would only need to write "log" to /proc/sys/kernel/seccomp/log_max_action. I wouldn't think that would be an issue considering that this will typically be be done on a developer's system. Additionally, I plan to make "log" the default for log_max_action in Ubuntu so there'd be nothing to change to get RET_LOG working. If auditd is running, the messages will go to the audit.log. If auditd is not running, the messages will go to the syslog. What if we make "log" the default for log_max_action in this patch set? Would that address your concerns? > What if, instead of logging straight to the audit log, SECCOMP_RET_LOG > [1] merely meant "tell our parent about this syscall"? (Ideally we'd > also figure out a way to express "log this and allow", "log this and > do ERRNO", etc.) Then we could have another mechanism that installs a > layer in the seccomp stack that, instead of catching syscalls, catches > log events and sticks them in a ring buffer (or audit). >=20 > Concretely, it might work like this. If a filter returns > SECCOMP_RET_LOG, then we "log" and keep processing. SECCOMP_RET_LOG > is otherwise treated literally like SECCOMP_RET_ALLOW and has no > effect on return value. If you want log-and-kill, you install two > filters. >=20 > There's a new seccomp(2) action that returns an fd. That fd > references a new thing in the seccomp stack that is a BPF program that > is called whenever SECCOMP_RET_LOG is returned from lower down. The > output of this filter determines whether the log event is ignored, > stuck in the ring buffer, or passed up the stack for further > processing. You read(2) the fd to access the ring buffer. >=20 > Using this mechanism, you could write a simple seccomptrace tool that > needs no privilege and dumps SECCOMP_RET_LOG events from the target > program to stderr. >=20 > Thoughts? IMHO, this sounds like yet another logging daemon. It is also more complex than what's needed for my use case of SECCOMP_RET_LOG. I only need a seccomp learning mode, to accompany the learning modes implemented in the various LSMs, that allows for everything marked with RET_LOG to hit the syslog (or audit log). Having to wedge seccomptrace tool between my application launcher, which handles sandboxing, and the application being launched is less than ideal. The application launcher could reimplement what seccomptrace is doing but it'd be nice if that was left up to auditd/rsyslogd/journald/et= c. Tyler >=20 > [1] If we went this route, it might want to be renamed. >=20 > P.S. We ought to be able to write a BPF verifier pass that makes sure > that filters don't return unsupported return values if we cared to do > so. >=20 --cMEWcfeqMh0SS8jESuwVJTuF6F0IpXrTA-- --FEN2uKHgKv0kdio7EJ20VOK4PFtXQRtgE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYpf9uAAoJENaSAD2qAscKl1UQAJoVWDQzUXWbj9hiNqHQkmoB UG/HGR4lAP4JoAwwiNMobMpyCDCxfQWHxhrvfjUbd5C5NseSY+Vg8P7x1CmeuIWr YXavE/CeeFeOK6QqPDAIoNlvGNx4WQpTlHY8lUXdjJtThbMzgT6zqcxayscdQXcO m7uOAeyuyfEKxbSOE+fVQ1j2R9xxLb1MYqB3rs0k9jswZyxnhvYXP7PscLKInKWN ypOF6q3qK9R0CmaujWztJwza7+BRcydRT9Z9zR7KWJ5CwGQ0Ez8IWICDV4mC+9X3 oiwxk1N0h1mVLJFSbkt2UJS6nPSXNJiOF+45MDcrSKg4JRfhRPOvZlSudw5DTCWz JU64Jjthmo87Hzt83U5NVNu7HGaKXjsZ1xX9WSXitf14PskK9huSk5udReUXVPqo jWS2DMPLR4AHTE6d+wWgsNeraDyI7jbtX8aiHf8w55pES+UpiLrFcxh/RVv1fiOp cLcLBIqRoA98zmzhJ3ZgqqAhcAclqGlB0Mina8PqCOkQTrEOS7U+p8zap99Gj4PO wtzlTWIGcEkhMS2SZpxq/URCbUF4+WF0W9bFPC7TxQ+yv50A4E18IjZze7eJwiYc mCPiXNlxa8N6uYX9NBmH/xEGk+pzNJxqFrkDLqwtYoEc/NutdlZPjvmgzBI4YmqM FwOTzTnIQwRn2oV7FPKK =OZ4S -----END PGP SIGNATURE----- --FEN2uKHgKv0kdio7EJ20VOK4PFtXQRtgE--