Description of problem:
FreeIPA allows the user to create a set of SELinux user maps. These are not cached properly, and as a result for a user with a domain joined system such as a laptop, when the system is started without access to the domain network, your SELinux permissions are reduced causing a lack in system functionality until you rejoin the domain network and login / out.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Join a laptop to a freeipa domain.
2. In freeipa, create a default selinux user map with a low label, ie user_u:user_r:user_t:s0. Then for the laptop system create a hbac rule for the user, and the laptop. Then create an selinux map for that hbac rule such as staff_u:staff_r:staff_t:s0:c0.c1023. Ensure that when you login to the laptop on the network, you get the staff role.
3. Disconnect all network devices on the laptop, reboot and login.
id -Z is user_u:user_r:user_t:s0
Since a login has already occured the label of staff_u:staff_r:staff_t:s0:c0.c1023 should be cached, and given to the user.
Given the nature of this bug, where a user may end up mislabelled, either in a higher or lower context depending on the setup of the freeipa selinux defaults, this may pose a security risk.
Thank you for the bug report. I reproduced your problem and I'm working on a fix.
a patch was pushed upstream. Can you check if it solves the problem for you?
Here is a F-20 scratch build:
No, this does not fix the issue. I have applied all the packages that were listed in the scratch build. Were you able to reproduce this or not? Is there a way to flush the sss selinux cache to a black state to ensure the testing is correct. IE flush sss selinux cache, restart on the domain network, login, disconnect from domain network and reboot.
(In reply to William Brown from comment #4)
> No, this does not fix the issue. I have applied all the packages that were
> listed in the scratch build. Were you able to reproduce this or not?
Yes, in my case the offline login errored out with EEXIST as SSSD wrongly attempted to store intermediate results into the cache.
> there a way to flush the sss selinux cache to a black state to ensure the
> testing is correct. IE flush sss selinux cache, restart on the domain
> network, login, disconnect from domain network and reboot.
rm -f /var/lib/sss/db/cache_*.ldb
If the issue still persists, could I see the sssd debug logs and the cache dump? In order to get the cache dump, you'd need to install the ldb-tools package and then run:
ldbsearch -H /var/lib/sss/db/cache_$yourdomain.ldb
sssd-1.11.4-2.fc20 has been submitted as an update for Fedora 20.
btw I submitted sssd-1.11.4-2.fc20 for updates-testing, you can try that one instead if you'd like to keep using Fedora builds:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing sssd-1.11.4-2.fc20'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
I reran this test by:
* Flushing the sssd caches as you recommended
* Starting the system on the domain network
* Logging in an checking the context
* Shutdown the system
* Disconnect from the network
* Start and login
This time it appears to have worked, and I have the correct context. Thanks for this.
Thanks for testing!
Thanks indeed. William - your bug reports and testing in FreeIPA and SSSD projects are always very helpful and beneficial to both projects.
sssd-1.11.4-3.fc20 has been submitted as an update for Fedora 20.
sssd-1.11.4-3.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.