On Tue, Dec 4, 2018 at 7:37 PM Stephen Smalley <sds@xxxxxxxxxxxxx> wrote: > > On 12/4/18 1:00 PM, BMK wrote: > > On Tue, Dec 4, 2018 at 5:50 PM Stephen Smalley <sds@xxxxxxxxxxxxx> 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...
