From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tyler Hicks Subject: Re: [PATCH] userspace: audit: ausearch doesn't return entries for AppArmor events that exist in the log Date: Fri, 30 May 2014 22:16:44 +0200 Message-ID: <20140530201644.GA22335@boyd> References: <53866422.5010709@suse.de> <31153503.SQnCbJNRtA@x2> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1328140513247869401==" Return-path: In-Reply-To: <31153503.SQnCbJNRtA@x2> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb Cc: wpreston@suse.com, seth.arnold@canonical.com, linux-audit@redhat.com List-Id: linux-audit@redhat.com --===============1328140513247869401== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="UlVJffcvxoiEqYs2" Content-Disposition: inline --UlVJffcvxoiEqYs2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 expects to= see > > an SELinux tclass field. This patch doesn't address the lack of support= for > > AppArmor in "aureport --avc". Talking to Seth Arnold, Canonical appare= ntly > > has patches for this; if this is true perhaps they can post for inclusi= on. > >=20 > > Based-on-work-by: William Preston > > Signed-off-by: Tony Jones >=20 > I was looking at this patch and was wondering something. Does AppArmor pr= oduce=20 > AUDIT_AVC events? It does. Here's an odd ball that I picked out of my audit log: type=3DAVC msg=3Daudit(1400295012.391:11143): apparmor=3D"DENIED" operation= =3D"mount" info=3D"failed type match" profile=3D"lxc-container-default" nam= e=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=20 > there another part of the patch missing in the switch statement that dire= ct=20 > AUDIT_APPARMOR_* events into parse_avc? As you can see above, they already flow through parse_avc(). 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. It worked well with ausearch and aureport during some quick manual testing. I'd like to do some more testing next week and, hopefully, add some automated tests before I send it to the list. Tyler >=20 > -Steve >=20 > > --- a/src/ausearch-parse.c 2014-05-21 14:45:22.000000000 +0200 > > +++ b/src/ausearch-parse.c 2014-05-21 14:53:55.000000000 +0200 > > @@ -1735,17 +1735,15 @@ static int parse_avc(const lnode *n, sea > >=20 > > // Now get the class...its at the end, so we do things different > > str =3D strstr(term, "tclass=3D"); > > - if (str =3D=3D NULL) { > > - rc =3D 9; > > - goto err; > > + if (str) { > > + str +=3D 7; > > + term =3D strchr(str, ' '); > > + if (term) > > + *term =3D 0; > > + an.avc_class =3D strdup(str); > > + if (term) > > + *term =3D ' '; > > } > > - str +=3D 7; > > - term =3D strchr(str, ' '); > > - if (term) > > - *term =3D 0; > > - an.avc_class =3D strdup(str); > > - if (term) > > - *term =3D ' '; > >=20 > > if (audit_avc_init(s) =3D=3D 0) { > > alist_append(s->avc, &an); >=20 > -- > Linux-audit mailing list > Linux-audit@redhat.com > https://www.redhat.com/mailman/listinfo/linux-audit --UlVJffcvxoiEqYs2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCgAGBQJTiOcsAAoJENaSAD2qAscKoCQQAI/pOEgTerubLqPQkp2YvzlY q5yNoA1CP5MhUt07BUCVjwwZoTaDLvLb6JzxVPsGolE/yd5eIcDs1bQafMSub23O yJq3VPiGOFCLOQ9qfNsVKv8HZKNDC7+d8n2tyFkEn+HSQwo7XF5rWrmzyjpISC9d VmNKOt2LlZ0A1q4gEoPIVYZt8iwrHT+h+XCfJI93AZBwoWybaFP2GHlzkyhqztuo DnWq+6fvgh7Bi4zAPGo871WSCIj2Nr+oemcV3SY1O/R3P7Ia5VQ7tJ/gZXiYqL4k JkwrypYmIPcrE96Sv+ZQNWwziMnFsbNm4+i3KvwgFJHLQ6Z84+E/nGZwtEMC25Y7 wWfnY9tS22J/8CK7l4RiW+rEcblutgNO1KJblizh8RjbjiV5mm+IAb3+xa5M+KNV pLDvnnsZUaLIep18rhKXPleAQGbu9OzXe8kHUBjAEbQx7leCviBMGxnAoSVPUJJ0 lss0PRTpJ0XiugHHB2OnO2fkDTAkZQQbNGd2Y2UOsfWW6jqbseUxL0yUjsq+kZsp pFhlN5vTzuP37QFUvmA9fy0kH/wKudo7RlKdbKnpL/74jrXH9FoMkT4XmH49IAn0 Bfy7VmadmZH8RplRY0SokAm5ya8VT5rAeW+g3jhNaQ8HPutEFwM66kmUAgjdZa+A NR1abVqFejFUXc/gflgB =KMUB -----END PGP SIGNATURE----- --UlVJffcvxoiEqYs2-- --===============1328140513247869401== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============1328140513247869401==--