From mboxrd@z Thu Jan  1 00:00:00 1970
From: Tony Jones <tonyj@suse.de>
Subject: Re: seccomp and audit_enabled
Date: Tue, 13 Oct 2015 12:46:47 -0700
Message-ID: <561D5FA7.9040202@suse.de>
References: <56188AE9.4030306@suse.de> <9092019.92r82W6k9o@sifl>
	<4636418.ofTBd0bpCf@sifl> <561BF39B.5050209@suse.de>
	<CAGXu5jKogSW-Qo+CabVHgZ7tx-1WE=MAJd+Khu5M2AMxwTS_vA@mail.gmail.com>
	<CAHC9VhSVOe53Mp64_kG7NeGEPsXei2EfGJUg4GtYqvyoX8oKxg@mail.gmail.com>
	<561D3D03.30300@suse.de>
	<CAHC9VhQgDJAW0RrORwzRT0T1BaV7BbqCQvNmW7F6n2v6_=0K6A@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <linux-audit-bounces@redhat.com>
Received: from mx1.redhat.com (ext-mx05.extmail.prod.ext.phx2.redhat.com
	[10.5.110.29])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id t9DJrj1d012616
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256
	verify=NO)
	for <linux-audit@redhat.com>; Tue, 13 Oct 2015 15:53:45 -0400
Received: from mx2.suse.de (mx2.suse.de [195.135.220.15])
	by mx1.redhat.com (Postfix) with ESMTPS id 3A0C1461D5
	for <linux-audit@redhat.com>; Tue, 13 Oct 2015 19:53:44 +0000 (UTC)
In-Reply-To: <CAHC9VhQgDJAW0RrORwzRT0T1BaV7BbqCQvNmW7F6n2v6_=0K6A@mail.gmail.com>
List-Unsubscribe: <https://www.redhat.com/mailman/options/linux-audit>,
	<mailto:linux-audit-request@redhat.com?subject=unsubscribe>
List-Archive: <https://www.redhat.com/archives/linux-audit>
List-Post: <mailto:linux-audit@redhat.com>
List-Help: <mailto:linux-audit-request@redhat.com?subject=help>
List-Subscribe: <https://www.redhat.com/mailman/listinfo/linux-audit>,
	<mailto:linux-audit-request@redhat.com?subject=subscribe>
Sender: linux-audit-bounces@redhat.com
Errors-To: linux-audit-bounces@redhat.com
To: Paul Moore <paul@paul-moore.com>
Cc: linux-security-module <linux-security-module@vger.kernel.org>, linux-audit@redhat.com
List-Id: linux-audit@redhat.com

On 10/13/2015 12:19 PM, Paul Moore wrote:

>> No, it's the default audit.rules (-D, -b320).   No actual rules loaded.
>> Let me add some instrumentation and figure out what's going on.  auditd
>> is masked (via systemd) but systemd-journal seems to set audit_enabled=1
>> during startup (at least on our systems).
> 
> Yes, if systemd is involved it enables audit; we've had some
> discussions with the systemd folks about fixing that, but they haven't
> gone very far.  I'm still a little curious as to why
> audit_dummy_context() is false in this case, but I haven't looked at
> how systemd/auditctl start/config the system too closely.

I'll debug what's going on (easy) on the test system and report back.  I'm curious
too.  Have a bad cold today so I'm moving slower than normal.

> I don't really care if it is audit or not (although we will need to
> output something via audit if it is enabled to keep the CC crowd
> happy); if you feel strongly that it isn't audit, we can just make it
> a printk, that would work well with Kees' goals.  To me the important
> point here is that we send a message when seccomp alters the behavior
> of the syscall (action != ALLOW).

Yes, if audit is enabled, you should totally be able to use it. Rest sounds good also.

thanks!

Tony