From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: [PATCH] userspace: audit: ausearch doesn't return entries for AppArmor events that exist in the log Date: Fri, 30 May 2014 17:00:04 -0400 Message-ID: <9810096.ghxOlbMYMG@x2> References: <53866422.5010709@suse.de> <31153503.SQnCbJNRtA@x2> <20140530201644.GA22335@boyd> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7211923000952887784==" Return-path: In-Reply-To: <20140530201644.GA22335@boyd> 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: wpreston@suse.com, seth.arnold@canonical.com, linux-audit@redhat.com List-Id: linux-audit@redhat.com --===============7211923000952887784== Content-Type: multipart/signed; boundary="nextPart2699499.VhBxDoZ519"; micalg="pgp-sha1"; protocol="application/pgp-signature" --nextPart2699499.VhBxDoZ519 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" On Friday, May 30, 2014 10:16:44 PM Tyler Hicks wrote: > On 2014-05-30 15:53:49, Steve Grubb wrote: > > On Wednesday, May 28, 2014 03:33:06 PM Tony Jones wrote: > > > This patch came from our L3 department. AppArmor LSM is logging = using > > > the > > > common_lsm_audit() call but the audit userspace parsing code expe= cts to > > > see > > > an SELinux tclass field. This patch doesn't address the lack of s= upport > > > for > > > AppArmor in "aureport --avc". Talking to Seth Arnold, Canonical > > > apparently > > > has patches for this; if this is true perhaps they can post for > > > inclusion. > > >=20 > > > Based-on-work-by: William Preston > > > Signed-off-by: Tony Jones > >=20 > > I was looking at this patch and was wondering something. Does AppAr= mor > > produce AUDIT_AVC events? >=20 > It does. Here's an odd ball that I picked out of my audit log: Uh-oh. I gave out the 1500 - 1599 block of events to App Armor so that = this=20 problem would never happen. libaudit.h: #define AUDIT_FIRST_SELINUX 1400 #define AUDIT_LAST_SELINUX 1499 #define AUDIT_FIRST_APPARMOR 1500 #define AUDIT_LAST_APPARMOR 1599 When you have an event of the same number, it has to have the same fiel= ds in=20 the same order with same value representation. As you can see the repor= ting=20 tools is sensitive to this because they are optimized to handle huge lo= g files.=20 Hmmm.... > type=3DAVC msg=3Daudit(1400295012.391:11143): apparmor=3D"DENIED" > operation=3D"mount" info=3D"failed type match" profile=3D"lxc-contain= er-default" > name=3D"/sys/fs/cgroup/systemd/" pid=3D15761 comm=3D"mount" fstype=3D= "cgroup" > srcname=3D"systemd" flags=3D"rw, nosuid, nodev, noexec" > > If not, how does the code even get into parse_avc? IOW, is > > there another part of the patch missing in the switch statement tha= t > > direct AUDIT_APPARMOR_* events into parse_avc? >=20 > As you can see above, they already flow through parse_avc(). This is a big mistake, IMHO. In theory, this is what should have happen= ed: An access decisionl event should have been named in the 1500 block. It= would=20 then be free to include the field it needs in the order it needs. The a= usearch=20 would get a function parse_aa_decision. That function would stuff a str= uct=20 specially tuned for AA usage. Aureport would gain a new report. > I spent a little time today getting a patch together to parse the > 'apparmor=3D"DENIED" operation=3D"mount"' portion parsed to fill > an.avc_result and an.avc_perm. >=20 > It worked well with ausearch and aureport during some quick manual > testing. I'd like to do some more testing next week and, hopefully, a= dd > some automated tests before I send it to the list. Well...I wished it had been clear a long time ago that the 1500 block w= as free=20 to do anything with for AA's needs so we don't overload the usage. Not = sure=20 what to do about this. =2DSteve --nextPart2699499.VhBxDoZ519 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEABECAAYFAlOI8VsACgkQCfgKaXAKiuabLwCcD0vRSiKSC/q9Da/esrW49qI5 ym8AoIBrv/s6VLtkQ2dY/GzW3wxu+Gt5 =Zzic -----END PGP SIGNATURE----- --nextPart2699499.VhBxDoZ519-- --===============7211923000952887784== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============7211923000952887784==--