lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 16 Feb 2017 15:29:19 -0800 From: Kees Cook <keescook@...omium.org> To: Andy Lutomirski <luto@...capital.net> Cc: Tyler Hicks <tyhicks@...onical.com>, Paul Moore <paul@...l-moore.com>, Eric Paris <eparis@...hat.com>, Will Drewry <wad@...omium.org>, linux-audit@...hat.com, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, John Crispin <john@...ozen.org>, linux-api@....kernel.org Subject: Re: [PATCH v3 0/4] Improved seccomp logging On Wed, Feb 15, 2017 at 7:24 PM, Andy Lutomirski <luto@...capital.net> wrote: > On Mon, Feb 13, 2017 at 7:45 PM, Tyler Hicks <tyhicks@...onical.com> 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@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 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. > 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). So, I really don't like this because it's yet another logging system. We already have a security event logger: audit. This continues to use that subsystem without changing semantics very much. > 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. > > 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. > > 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. If someone was going to do this, they could just as well set up a tracer to use RET_TRAP. (And this is what things like minijail does already, IIRC.) The reality of the situation is that this is way too much overhead for the common case. We need a generalized logging system that uses the existing logging mechanisms. > Thoughts? > > [1] If we went this route, it might want to be renamed. > > 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. Can we? I thought the BPF_RET used the BPF registers, and validating that might be less-than-easy? -Kees -- Kees Cook Pixel Security
Powered by blists - more mailing lists