Bug 119572 - SELinux FAQ - permission denial is silent
Summary: SELinux FAQ - permission denial is silent
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora Documentation
Classification: Fedora
Component: selinux-faq   
(Show other bugs)
Version: devel
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Karsten Wade
QA Contact: Tammy Fox
URL: http://people.redhat.com/kwade/fedora...
Whiteboard:
Keywords:
Depends On:
Blocks: 118757
TreeView+ depends on / blocked
 
Reported: 2004-03-31 14:17 UTC by Stephen Smalley
Modified: 2007-04-18 17:05 UTC (History)
2 users (show)

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


Attachments (Terms of Use)

Description Stephen Smalley 2004-03-31 14:17:40 UTC
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-02 00:08:55 UTC
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 12:46:55 UTC
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 19:34:22 UTC
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.