Worrying AVC messages

[Stephen Smalley]

On Wed, 2007-01-24 at 08:13 -0500, Stephen Smalley wrote:
> On Wed, 2007-01-24 at 10:10 +0000, Anne Wilson wrote:
> > On Tuesday 23 January 2007 19:58, Stephen Smalley wrote:
> > > audit2allow is just a filter that reads avc messages and emits policy
> > > rules that would allow them.  The -a option tells it to check
> > > both /var/log/messages and the audit logs for avc messages (using
> > > ausearch for processing the audit logs).  The -M local option tells it
> > > to generate a loadable policy module named "local".  Upon completion,
> > > you should have the following files in the current directory:
> > > 1) local.te - the policy source generated by audit2allow based on the
> > > avc messages,
> > > 2) local.mod - binary representation of the same, created by
> > > checkmodule,
> > > 3) local.pp - policy package file, containing local.mod and optionally
> > > other policy components (but not in this case), created by
> > > semodule_package.
> > >
> > > The last file is then loadable via semodule -i.
> > > When semodule -i completes, your policy has been updated and loaded into
> > > the kernel.
> > 
> > All done, and those three files are in /root.  Is that the correct place for 
> > them?
> 
> audit2allow just generates files to the current working directory.  Then
> semodule -i local.pp takes that .pp file's contents and feeds it to
> libsemanage, which pushes it into the policy module store
> (under /etc/selinux/targeted/modules) and rebuilds the policy.
> 
> > If I have understood you correctly, by doing that I have told it to 'approve' 
> > the making of rules to deal with all the denials found there.
> 
> Correct.
> 
> >   At the moment 
> > I don't think there is anything dangerous in the log, but I presume that 
> > there are times when you would not want everything added.  What happens about 
> > those situations?
> 
> Some of the denials you listed suggested a problem with device node
> labeling, so those bear investigating.  What you have done is put into
> place a temporary workaround to let your system operate until a correct
> fix is determined.  Ultimately, clean fixes for the underlying issues
> should go into the upstream policy, which is why it is important to
> report such denials to this list or the upstream selinux list.
> 
> audit2allow presently has no intelligence to it, but there is work in
> progress to provide a smarter tool that will help in making decisions.
> There are alternatives to directly allowing the denied access, such as:
> - if the access isn't truly required for operation, you can just
> suppress the audit messages via dontaudit rules instead of allow rules,
> - you can introduce new domains and/or types for the processes and/or
> objects involved, so that you only end up allowing access for the
> specific processes and/or objects rather than everything presently in
> that domain/type.

Also, I should note that certain allow rules will be automatically
rejected due to assertions present in the base policy, so if your
audit2allow output happens to include such allow rules, the semodule -i
local.pp command will fail with a policy assertion failure.  That is one
way to catch unsafe rules, by defining a set of assertions in the base
policy (but the current set of assertions is by no means exhaustive).
There are also hooks in libsemanage to permit other policy
checkers/verifiers to be run whenever a module is inserted, and there is
work on a policy management server that can apply a meta-policy over
policy changes.

-- 
Stephen Smalley
National Security Agency