linux-kernel - Re: Should audit_seccomp check audit

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 23 Oct 2015 16:51:34 -0400
From:	Steve Grubb <sgrubb@...hat.com>
To:	Paul Moore <paul@...l-moore.com>
Cc:	Kees Cook <keescook@...omium.org>,
	Andy Lutomirski <luto@...capital.net>,
	Richard Guy Briggs <rgb@...hat.com>, linux-audit@...hat.com,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Should audit_seccomp check audit_enabled?

On Friday, October 23, 2015 03:38:05 PM Paul Moore wrote:
> On Fri, Oct 23, 2015 at 1:01 PM, Kees Cook <keescook@...omium.org> wrote:
> > On Fri, Oct 23, 2015 at 9:19 AM, Andy Lutomirski <luto@...capital.net> 
wrote:
> >> I would argue that, if auditing is off, audit_seccomp shouldn't do
> >> anything.  After all, unlike e.g. selinux, seccomp is not a systemwide
> >> policy, and seccomp signals might be ordinary behavior that's internal
> >> to the seccomp-using application.  IOW, for people with audit compiled
> >> in and subscribed by journald but switched off, I think that the
> >> records shouldn't be emitted.
> >> 
> >> If you agree, I can send the two-line patch.
> > 
> > I think signr==0 states (which I would identify as "intended
> > behavior") don't need to be reported under any situation, but audit
> > folks wanted to keep it around.
> 
> Wearing my libseccomp hat, I would like some logging when the seccomp
> filter triggers a result other than allow.  I don't care if this is
> via audit or printk(), I just want some notification.  If we go the
> printk route and people really don't want to see anything in their
> logs, I suppose we could always add a sysctl knob to turn off the
> message completely (we would still need to do whatever audit records
> are required, see below).
> 
> Wearing my audit hat, I want to make sure we tick off all the right
> boxes for the various certifications that people care about.  Steve
> Grubb has commented on what he needs in the past, although I'm not
> sure it was on-list, so I'll ask him to repeat it here.

I went back and reviewed my notes since this came up in the current Common 
Criteria evaluation. What we decided to do is treat syscall failures which 
failed due to seccomp the same as syscall failures caused by dropping 
capabilities. Both are opt-in DAC policies. That means we don't care. Do 
whatever you like. :-)

-Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/