Sepolgen has long not recovered from parsing errors, leading to
a blacklist of none bad modules in the source. I finally tracked
down the problem (lexer state) and this patch fixes the problem
by causing the lexer to be rebuilt on error.
Acked-by: Joshua Brindle <jbrindle@tresys.com>
On 03/08/2010 11:11 AM, Karl MacMillan wrote:
> Accidentally sent this straight to Josh.
>
> Karl
>
> On Thu, Mar 4, 2010 at 4:46 PM, Karl MacMillan<karlwmacmillan@gmail.com> wrote:
>
>> I meant this - I don't want to pass around a boolean flag when we have
>> a flag for rule type. This allows cleanly adding support for, say,
>> generating both allow rules and auditallow rules at the same time.
>>
>>
<snip>
Ok this one only adds a flag to the policygenerator to tell it to
generate dontaudit rules.
No passing of args.
Acked-by: Karl MacMillan <karlwmacmillan@gmail.com>
On Mon, 2009-08-24 at 23:37 +1000, Russell Coker wrote:
> On Mon, 24 Aug 2009, Daniel J Walsh <dwalsh@redhat.com> wrote:
> > >>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503252
> > >>
> > >> audit2allow -l is looking for the load_policy message which does not go
> > >> to the dmesg, /var/log/messages. Therefore the tool has no idea when
> > >> policy was last loaded.
> > >
> > > That would be a kernel bug then.
> >
> > Well I believe the messages that are intercepted by the audit.log do not go
> > into dmesg, by design. Although Steve, James or Eric could probably say for
> > sure.
>
> When auditd is not running on a Debian system with CentOS kernel
> 2.6.18-92.1.13.el5xen or Debian/Lenny kernel 2.6.26-2-xen-686 then nothing
> goes to the kernel message log which is interpreted by audit2allow as a
> candidate for the "-l" functionality.
>
> It's OK if all the AVC messages go to the audit log and "dmesg|audit2allow -l"
> gives no output. But if all AVC messages other than the load_policy message
> go to the kernel message log then it's a bug.
Originally audit2allow used the avc: allowed message generated by
auditallow statement for load_policy to identify policy reloads. Later
it was switched to use the MAC_POLICY_LOAD events generated by the audit
framework. Those events should still get logged via printk if auditd is
not running, but it appears that the code (audit_printk_skb) will then
log the type= field as an integer rather than a string, and
audit2allow/sepolgen only looks for the string MAC_POLICY_LOAD.
So I suspect that this would be resolved by modifying sepolgen/audit.py
to also match on type=1403 for load messages. Try this:
Signed-off-by: Joshua Brindle <method@manicmethod.com>
Add support to sepolgen for new Xen ocontext identifiers.
Signed-off-by: Paul Nuzzi <pjnuzzi@tycho.ncsc.mil>
Signed-off-by: Joshua Brindle <method@manicmethod.com>
Commit b3b3f8186e attempted to fix a bug,
but didn't. The following patch should do it.
Marshall Miller
Signed-off-by: Chad Sellers <csellers@tresys.com>
Email: dwalsh@redhat.com
Subject: Problem in sepolgen
Date: Mon, 01 Dec 2008 11:51:19 -0500
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
self.roles does not exist, need to return length of dictionary.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkk0FgYACgkQrlYvE4MpobP5HwCeNgjPTSPoqBQTXa14ZA9Jc0ww
yycAoNWJhg78BXm4L5Vg9cNAdNa7ggfD
=Uz8t
-----END PGP SIGNATURE-----
Signed-off-by: Joshua Brindle <method@manicmethod.com>
Email: dwalsh@redhat.com
Subject: Only call gen_requires once.
Date: Thu, 11 Sep 2008 09:35:54 -0400
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Currently audit2allow/sepolgen will create two identical gen_requires
block if you have allow rules and a role statement.
This patch fixes this problem.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkjJHroACgkQrlYvE4MpobPgMQCghgAMBtaQO0BeZX+ug6IwsWB8
bNEAoMkRo4cZa0iJhGoGMmCvy5ncGpj8
=gMFg
-----END PGP SIGNATURE-----
Signed-off-by: Joshua Brindle <method@manicmethod.com>
