From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935603AbdADGbP (ORCPT ); Wed, 4 Jan 2017 01:31:15 -0500 Received: from mail-io0-f169.google.com ([209.85.223.169]:33334 "EHLO mail-io0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752638AbdADGbM (ORCPT ); Wed, 4 Jan 2017 01:31:12 -0500 MIME-Version: 1.0 In-Reply-To: <20170104044335.GA20124@madcap2.tricolour.ca> References: <8748cee7-efe3-a603-ef2e-dc9077b6ead4@canonical.com> <3d1890e7-bef4-91e3-5d4c-cc5d4786d472@canonical.com> <20170104044335.GA20124@madcap2.tricolour.ca> From: Kees Cook Date: Tue, 3 Jan 2017 22:31:10 -0800 X-Google-Sender-Auth: c-H0zm7CbxFWcNI7nU1Q3pl6828 Message-ID: Subject: Re: [PATCH 0/2] Begin auditing SECCOMP_RET_ERRNO return actions To: Richard Guy Briggs Cc: Tyler Hicks , Paul Moore , linux-audit@redhat.com, Will Drewry , LKML , Andy Lutomirski Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 3, 2017 at 8:43 PM, Richard Guy Briggs wrote: > On 2017-01-04 08:58, Tyler Hicks wrote: >> On 01/04/2017 04:44 AM, Kees Cook wrote: >> > On Tue, Jan 3, 2017 at 1:31 PM, Paul Moore wrote: >> >> On Tue, Jan 3, 2017 at 4:21 PM, Kees Cook wrote: >> >>> On Tue, Jan 3, 2017 at 1:13 PM, Paul Moore wrote: >> >>>> On Tue, Jan 3, 2017 at 4:03 PM, Kees Cook wrote: >> >>>>> On Tue, Jan 3, 2017 at 12:54 PM, Paul Moore wrote: >> >>>>>> On Tue, Jan 3, 2017 at 3:44 PM, Kees Cook wrote: >> >>>>>>> I still wonder, though, isn't there a way to use auditctl to get all >> >>>>>>> the seccomp messages you need? >> >>>>>> >> >>>>>> Not all of the seccomp actions are currently logged, that's one of the >> >>>>>> problems (and the biggest at the moment). >> >>>>> >> >>>>> Well... sort of. It all gets passed around, but the logic isn't very >> >>>>> obvious (or at least I always have to go look it up). >> >>>> >> >>>> Last time I checked SECCOMP_RET_ALLOW wasn't logged (as well as at >> >>>> least one other action, but I can't remember which off the top of my >> >>>> head)? >> >>> >> >>> Sure, but if you're using audit, you don't need RET_ALLOW to be logged >> >>> because you'll get a full syscall log entry. Logging RET_ALLOW is >> >>> redundant and provides no new information, it seems to me. >> >> >> >> I only bring this up as it might be a way to help solve the >> >> SECCOMP_RET_AUDIT problem that Tyler mentioned. >> > >> > So, I guess I want to understand why something like this doesn't work, >> > with no changes at all to the kernel: >> > >> > Imaginary "seccomp-audit.c": >> > >> > ... >> > pid = fork(); >> > if (pid) { >> > char cmd[80]; >> > >> > sprintf(cmd, "auditctl -a always,exit -S all -F pid=%d", pid); >> > system(cmd); >> > release... >> > } else { >> > wait for release... >> > execv(argv[1], argv + 1); >> > } >> > ... >> > >> > This should dump all syscalls (both RET_ALLOW and RET_ERRNO), as well >> > as all seccomp actions of any kind. (Down side is the need for root to >> > launch auditctl...) >> >> Hey Kees - Thanks for the suggestion! >> >> Here are some of the reasons that it doesn't quite work: >> >> 1) We don't install/run auditd by default and would continue to prefer >> not to in some situations where resources are tight. Strictly speaking, auditd isn't needed for auditctl, IIUC. >> 2) We block a relatively small number of syscalls as compared to what >> are allowed so auditing all syscalls is a really heavyweight solution. >> That could be fixed with a better -S argument, though. Yeah, it seems like there needs to be some kind of improvement there on the audit side (I was thinking a better -F). The all-or-nothing approach is way too big a hammer. >> 3) We sometimes only block certain arguments for a given syscall and >> auditing all instances of the syscall could still be a heavyweight solution. >> >> 4) If the application spawns children processes, that rule doesn't audit >> their syscalls. That can be fixed with ppid=%d but then grandchildren >> pids are a problem. > > This patch that wasn't accepted upstream might be useful: > https://www.redhat.com/archives/linux-audit/2015-August/msg00067.html > https://www.redhat.com/archives/linux-audit/2015-August/msg00068.html I'd like this regardless. It's really difficult to audit trees of processes before they launch. :) > >> 5) Cleanup of the audit rule for an old pid, before the pid is reused, >> could be difficult. >> >> Tyler >> >> > Perhaps an improvement to this could be enabling audit when seccomp >> > syscall is seen? I can't tell if auditctl already has something to do >> > this ("start auditing this process and all children when syscall X is >> > performed"). >> > >> > -Kees > > - RGB > > -- > Richard Guy Briggs > Kernel Security Engineering, Base Operating Systems, Red Hat > Remote, Ottawa, Canada > Voice: +1.647.777.2635, Internal: (81) 32635 -Kees -- Kees Cook Nexus Security