Re: SELinux logging problem

[BMK <bmktuwien@gmail.com>]

On Tue, Dec 4, 2018 at 5:50 PM Stephen Smalley <sds@tycho.nsa.gov> wrote:
>
> On 12/4/18 11:38 AM, Stephen Smalley wrote:
> > 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).
>
> NB Any semodule operation will also trigger a policy reload (unless you
> specify -n or are acting on a policy other than the active one), so
> semodule -DB would also have flushed the cache for you when it removed
> all dontaudit rules.
>
> >
> > 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.
>

Thank you for your quick reply!

Let me give you a little bit more details about my setup.
I am working on debian 9.4 release with kernel version 4.9.0-6-amd64.
I have my own custom policy based on the refpolicy version
RELEASE 2 20161023. (it is pretty old but I have to work with that
specific version).
I am currently building a monolithic policy with dontaudit rules disabled.

Now here are the steps to reproduce the logging problem I described above.
Let say, I have a test domain foo_t, which is defined roughly as follows:

type foo_t;
domain_type(foo_t)
corecmd_exec_bin(foo_t)

Then I login as unconfined_u user and run the following command:

runcon -u system_u -r object_r -t foo_t -l s0 mkdir foobar

Note that unconfined_t and foo_t actually need little bit more rules to execute
the runcon command above, but they are irrelevant for my case...

The mkdir binary is selinux aware by which I mean that it loads
the libselinux.so shared library.
The libselinux library executes upon loading the following syscall:
(see https://github.com/SELinuxProject/selinux/blob/master/libselinux/src/init.c#L156)

access(SELINUXCONFIG, F_OK)

This call would need a search dir permission for selinux_config_t and since
the domain foo_t doesn't have the permission I was expecting a denial log entry.
But the AVC denial never shows up in the logs in permissive mode.
I also tried to empty the logging cache by executing
setenforce 1 && setenforce 0, which didn't help.
However in enforcing mode the denial is logged as expected.

Hope this helps to clarify my question a bit further...