From mboxrd@z Thu Jan 1 00:00:00 1970 From: Richard Guy Briggs Subject: Re: [PATCH 0/2] Begin auditing SECCOMP_RET_ERRNO return actions Date: Tue, 3 Jan 2017 23:43:35 -0500 Message-ID: <20170104044335.GA20124@madcap2.tricolour.ca> References: <8748cee7-efe3-a603-ef2e-dc9077b6ead4@canonical.com> <3d1890e7-bef4-91e3-5d4c-cc5d4786d472@canonical.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <3d1890e7-bef4-91e3-5d4c-cc5d4786d472@canonical.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Tyler Hicks Cc: Will Drewry , LKML , Andy Lutomirski , linux-audit@redhat.com List-Id: linux-audit@redhat.com 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. > > 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. > > 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 > 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