Log in

No account? Create an account

Previous Entry Share Next Entry
How come somethings get blocked by SELinux in permissive mode?
SELinux can be setup to run in three modes.

* Enforcing (My favorite)
* Permissive
* Disabled

Often permissive is described as the same as enforcing except everything is allowed and logged.

For the most part this is true, except when their are bugs or a "Access Control Manager" does not respect the permissive flag.

Most of SELinux is written where the kernel control's access, and it would be very strange for the kernel to block an access in permissive mode. 

But there are several situations where we want to check access outside the kernel.  For example.

  • Can an application connect to a particular dbus daemon?

  • Can a service start a particular systemd daemon?

  • Can a root process change the password of something?

  • Will sshd allow dwalsh to login as unconfined_t?

All of these checks are not seen by the kernel.  We implement SELinux checks in places like dbus daemon, systemd, X Server, sshd, passwd ...  When one of these services denies access you will see a USER_AVC generated rather then an AVC.  If these SELinux checks are not written correctly to check the permissive flag when an access is denied, you could get a real denial in permissive mode.

Usually we see these as bugs, but in certain situations the upstream does not want to accept patches to check the permissive flag.

If you know of a situation where this happens, open a bugzilla on it and we can work with the packager to fix the problem.

When you see an AVC or USER_AVC that is generated in permissive mode, you should see a flag that states "success=yes" in the AVC record, this indicates that the AVC was generated but still allowed.  If it says "success=no" in permissive mode then that should be considered a bug.