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 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...
