Worrying AVC messages

[Stephen Smalley]

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.

-- 
Stephen Smalley
National Security Agency