From: Stephen Smalley <sds@tycho.nsa.gov>
To: BMK <bmktuwien@gmail.com>, selinux@vger.kernel.org
Subject: Re: SELinux logging problem
Date: Tue, 4 Dec 2018 11:38:31 -0500 [thread overview]
Message-ID: <01635e21-f143-d940-ceb1-b95079ddf23b@tycho.nsa.gov> (raw)
In-Reply-To: <CAFSQBhHFcRxUivx+wYRLyD4Z=6sZ4-3VsgtjRiG=+9crtOyTXA@mail.gmail.com>
On 12/4/18 11:03 AM, BMK wrote:
> Hello,
>
> I am currently struggling with a strange SELinux problem,
> for which I am not able to find an answer by reading the documentation
> and researching online.
>
> The problem is, that some AVC denial log entries seem to get lost in
> permissive mode,
> in other words, they are not logged...
> I've already deactivated all dont audit rules and I know for sure that
> the denial actually occurs, because I can trace it via strace...
> Although I can't see a corresponding entry in the audit.log.
> By the way, in enforcing mode I can see suddenly the missing denial entry...
> If the permissive mode lacks/drops some denials which we can only see
> in enforcing mode,
> then this would be truly terrible for the policy writers...
> Otherwise I am out of ideas, what other things could cause the loss of
> SELinux denials...
>
> I hope you can point me to right direction with this matter and
> I thank you in advance for your help.
Permissive mode only logs the first instance of a denial by design to
avoid flooding the logs with repeated instances of the same denial. So
if you triggered the denial a while ago and repeat the operation, you
might not see the denial again. To be precise, in permissive mode, upon
the first denial of a permission, the permission is audited and then
added to the AVC entry so that subsequent denials using that cache entry
won't keep producing a denial. You can flush the cache to force denials
to re-appear by reloading policy (load_policy) or by switching back and
forth between permissive and enforcing mode (setenforce 1 && setenforce 0).
If that doesn't explain the behavior you are seeing, then we can't
really help without more information about the problem, e.g. the denial
message you say is visible in enforcing mode but not permissive mode,
your kernel version, possibly the strace output, a reproducer if you
have one, what distro / policy you are using, etc.
There are cases where the audit system could drop records due to OOM
conditions, its ratelimit, or its backlog limit. In those cases, you
should have a audit: message logged indicating that messages were lost.
Check your dmesg or journalctl logs for such messages from the audit
system. Those are audit system issues rather than SELinux. You can
configure the limits via auditctl and/or the audit configuration. But
generally those only apply when the audit system is under heavy load
from many denials (or many other audit messages) and you should see at
least some of them.
next prev parent reply other threads:[~2018-12-04 16:35 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-04 16:03 SELinux logging problem BMK
2018-12-04 16:38 ` Stephen Smalley [this message]
2018-12-04 16:52 ` Stephen Smalley
2018-12-04 18:00 ` BMK
2018-12-04 18:39 ` Stephen Smalley
2018-12-04 19:01 ` BMK
2018-12-04 19:42 ` Stephen Smalley
2018-12-04 19:56 ` BMK
2018-12-04 20:05 ` Stephen Smalley
2018-12-04 20:06 ` BMK
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=01635e21-f143-d940-ceb1-b95079ddf23b@tycho.nsa.gov \
--to=sds@tycho.nsa.gov \
--cc=bmktuwien@gmail.com \
--cc=selinux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).