Bug 119572 - SELinux FAQ - permission denial is silent
SELinux FAQ - permission denial is silent
Status: CLOSED CURRENTRELEASE
Product: Fedora Documentation
Classification: Fedora
Component: selinux-faq (Show other bugs)
devel
All Linux
medium Severity medium
: ---
: ---
Assigned To: Karsten Wade
Tammy Fox
http://people.redhat.com/kwade/fedora...
:
Depends On:
Blocks: 118757
  Show dependency treegraph
 
Reported: 2004-03-31 09:17 EST by Stephen Smalley
Modified: 2007-04-18 13:05 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-04-02 14:34:22 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Stephen Smalley 2004-03-31 09:17:40 EST
Description of change/FAQ addition.  If a change, include the original
text first, then the changed text:

I'd suggest adding an entry along the following lines:
Q.  I'm encountering a permission denial only when SELinux
is in enforcing mode, but I see no audit messages.  How can
I identify the cause of the permission denial?
A. The most common reason for silent denials is that the policy
contains an explicit dontaudit rule to suppress the audit message
because the denial occurs frequently and is viewed as benign, and we
don't want to  fill the audit logs with noise.  To re-enable all
auditing, a user can cd /etc/security/selinux/src/policy && make
enableaudit && make load.  Note that this can produce a _lot_ of audit
information, much of which may be irrelevant to your specific denial,
so only do it if you are specifically looking for an audit message for
a denial that seems to occur silently.  Then, when you want to go back
to a policy with dontaudit rules, you can cd
/etc/security/selinux/src/policy && make clean && make load.

A second case where a silent denial can occur is on an exec when a
domain transition would normally occur, but the new domain is not
authorized for the current role.  At present, such errors are only
logged when SELinux is permissive.  This has been fixed in the
upstream kernel so that it will log an audit message, but the current
Fedora kernel does not yet include this change.


Version-Release of FAQ (found on
http://people.redhat.com/kwade/fedora-docs/selinux-faq-en/ln-legalnotice.html):

 for example selinux-faq-1.0 (2004-03-29-T16:20-0800)
Comment 1 Karsten Wade 2004-04-01 19:08:55 EST
Please review the following write up for the FAQ:

(thanks for the entry submission)

## begin FAQ entry

Q: I get a specific permission denial only when SELinux is in enforcing
mode, but I don't see any audit messages in /var/log/messages. How can
I identify the cause of the permission denials?

A: There are two reasons you may be getting silent denials.

The most common reason is the policy contains an explicit dontaudit
rule to suppress audit messages. The dontaudit rule is often used like
this when a frequent benign denial is filling the audit logs.

To look for your particular denial, you will need to enable all auditing:


cd /etc/security/selinux/src/policy
make enableaudit
make load

[Caution] Caution

Enabling auditing will likely produce a large amount of audit
information, most of which is irrelevant to your denial.

Use this technique only if you are specifically looking for an audit
message for a denial that seems to occur silently. You will likely
want to turn off auditing as soon as possible.

To turn auditing off, do the following:


cd /etc/security/selinux/src/policy
make clean
make load

Another reason for getting silent denails is on an exec when a domain
transition would normally occur, but the new domain is not authorized
for the current role.

At present, these errors are only logged when SELinux is running in
permissive mode. This has been fixed in the upstream Linux kernel so
that it will log an audit message. The current Fedora Core test kernel
does not yet include this change.

## 30
Comment 2 Stephen Smalley 2004-04-02 07:46:55 EST
Just a minor suggestion:  rather than saying "To turn auditing off",
say "To re-enable dontaudit rules" or "To suppress benign audit
messages".  You aren't truly disabling all auditing, just the audit
that would normally be suppressed by dontaudit rules.
Comment 3 Karsten Wade 2004-04-02 14:34:22 EST
Thanks; I understand the concept but was having some difficulty
finding the exact wording to convey this without sounding as if I were
using double-negatives, i.e., "to re-engage the dontengage rules". 
Substituting 're-enable' works to keep the meaning simple and clear.

Here is a sample of the new wording; the rest I will post today with
other new questions:

## sample

Caution

Enabling auditing of all dontaudit rules will likely produce a large
amount of audit information, most of which is irrelevant to your denial.

Use this technique only if you are specifically looking for an audit
message for a denial that seems to occur silently. You will likely
want to re-enable dontaudit rules as soon as possible.

To re-enable dontaudit rules, do the following: 

## 30

Note You need to log in before you can comment on or make changes to this bug.