Auditd & Strict Policy 1.19

[George J. Jahchan]

Stephen,

Followed your instructions, adding 'audit write & audit_control' at the end of
the capability section in the policy/flask/access_vectors elicits the following
error message when making the policy:

... too many permissions to fit in an access vector.

It will accept any two of the three in the capability section of access_vectors,
at which time it complains as follows:

... 'permission [omitted permission from the above] is not defined for class
capability' ...

Bearing in mind that the machines are live production hosts, how do you
recommend we address this (from the available choices below)?

1) For a limited period of time (until FC4 is released), we can live with having
to switch to permissive mode in order to start the audit daemon, and revert back
to enforcing mode after it starts. The hosts are not taken down that often.

2) We can upgrade to FC4 strict policy, with no assurance that it will work or
not cause other problems.

3) We can upgrade to pre-release FC4, again with no assurance that it will work
or will not introduce new weaknesses.

Thank you for your help.

-----Original Message-----
From: Stephen Smalley [mailto:sds at tycho.nsa.gov]
Sent: Friday, May 20, 2005 3:09 PM
To: George J. Jahchan
Cc: Fedora SE Linux List
Subject: Re: Auditd & Strict Policy 1.19


On Fri, 2005-05-20 at 10:12 +0300, George J. Jahchan wrote:
> On a Bastilled FC3 latest kernel and with the strict SE Linux policy (1.19),
if
> not in permissive mode, the auditd daemon refuses to start with the following
> error messages in /var/log/messages:
>
> ... Unable to set audit pid, exiting.
> ... Error sending failure mode request (Operation not permitted).
>
> Once the daemon starts in permissive mode, it is not a problem to revert SE
> Linux back to enforcing mode, the daemon stays up (and performs as expected).
>
> Have started Fedora with audit=1 kernel option and enabled the noisy events in
> SE Linux (make enableaudit & make load in the strict policy source directory),
> auditd-related denials have all been explicitly allowed in our custom.te
policy
> under domains/misc. Auditd daemon still fails to start in enforcing mode, and
no
> selinux denials are generated when we try to start it.
>
> Using the above method, we have been able to get the system to boot in
enforcing
> mode and run all the programs & daemons we needed to run (with no selinux
> denials, except attempts to access shadow_t which is protected by an assertion
> in the strict policy), except for auditd.
>
> Any hints on how to resolve this issue?

With regard to the denial, I suspect it is due to recently introduced
(as of 2.6.11) new capability checks performed in the receive-side
kernel audit code, which unfortunately cannot generate audit messages
presently.  This will hopefully be resolved as part of some ongoing
work.  Hence, you likely need:
	allow auditd_t self:capability { audit_write audit_control };
in policy/domains/program/auditd.te, and you likely need to add those
permission definitions to policy/flask/access_vectors at the end of the
class capability definition as the FC3 policy would not have included
them.

BTW, when using strict policy, it is always advisable to use the latest
rawhide policy (in this case, FC4/devel) in order to pick up the latest
fixes.  Also, there has been a lot of work done in FC4/devel on the
kernel audit framework, auditd, auditctl, and other userspace support
for auditing in order to prepare it for CAPP evaluation, so if you truly
want to use auditing in general (beyond just the SELinux auditing), you
may want to move to FC4.

--
Stephen Smalley
National Security Agency