Re: SELinux logging problem

[BMK <bmktuwien@gmail.com>]

On Tue, Dec 4, 2018 at 8:40 PM Stephen Smalley <sds@tycho.nsa.gov> wrote:
>
> On 12/4/18 2:01 PM, BMK wrote:
> > On Tue, Dec 4, 2018 at 7:37 PM Stephen Smalley <sds@tycho.nsa.gov> wrote:
> >>
> >> On 12/4/18 1:00 PM, BMK wrote:
> >>> 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
> >>
> >> object_r is only for objects (e.g. files) not for processes, so you
> >> should never pass it to runcon.  system_r would make sense for a daemon,
> >> or unconfined_r for a user program launched by an unconfined_u user.
> >>
> >
> > Thank you for the tip, but I think it doesn't make difference for my
> > actual problem.
> >
> >>>
> >>> 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...
> >>
> >> Hmm...this access would be covered by a dontaudit rule normally since
> >> many programs that link with libselinux don't actually need to access
> >> /etc/selinux/config.  And in your example above mkdir will work just
> >> fine without ever using /etc/selinux/config, so it truly isn't needed.
> >> Thus, silencing the denial is the right thing to do.
> >>
> >
> > Yes, I am aware that mkdir still works but I chose it simply as an easily
> > reproducible example where a search permission denial gets dropped
> > in permissive mode...
> >
> >> I suspect that you aren't actually stripping dontaudit rules, or you
> >> aren't loading the policy you built but instead are loading the one that
> >> still has the dontaudit rules in place.
> >>
> >> sesearch will show you whether there is a dontaudit rule, e.g. sesearch
> >> --dontaudit -s foo_t -t selinux_config_t.
> >>
> > Yes, I double checked it and then I even deleted the corresponding
> > dontaudit rules
> > manually from the refpolicy but unfortunately it didn't help.
> > And as I said, the denial *shows up* in enforcing mode, so I think
> > dontaudit rule isn't here
> > the problem...
> >
> > As next step, I could try this out on other distros...
>
> Oh, I think I understand the cause.  The pathname resolution code was
> split into two cases, a non-blocking rcu walk and a potentially blocking
> ref walk.  In the rcu walk case, we cannot block, so slow_avc_audit()
> bails out with ECHILD and the caller falls back to a refwalk where we
> can safely block.  But we've already updated the cache entry with the
> permission in the permissive case, so on the retry we don't audit it at
> all.  That's a bug.  Interesting that no one has noticed it until now...
>
> To resolve, we need to propagate MAY_NOT_BLOCK down through
> avc_has_perm_noaudit() -> avc_denied() and skip the avc_update_node()
> call if it is set.  Then we'll never modify the cache entry under RCU
> walk and see the denial on the ref walk.  I think.
>

Ah, I see...
Yeah, if it is a bug, then interesting, that no one noticed it until now...
Do you think there is any workaround I could try
to solve my problem?
Can i somehow disable the caching in permissive mode?