Bug 1071578 - SSSD Does not cache SELinux map from FreeIPA correctly
Summary: SSSD Does not cache SELinux map from FreeIPA correctly
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: sssd
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Jakub Hrozek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1072067
TreeView+ depends on / blocked
 
Reported: 2014-03-01 22:01 UTC by William Brown
Modified: 2020-05-02 17:39 UTC (History)
8 users (show)

Fixed In Version: sssd-1.11.4-3.fc20
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1072067 (view as bug list)
Environment:
Last Closed: 2014-04-09 00:55:04 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github SSSD sssd issues 3307 0 None None None 2020-05-02 17:39:01 UTC

Description William Brown 2014-03-01 22:01:09 UTC
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):
1.11.4-1

How reproducible:
Always

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.

Actual results:
id -Z is user_u:user_r:user_t:s0

Expected results:
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.

Additional info:
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.

Comment 1 Jakub Hrozek 2014-03-03 16:29:14 UTC
Thank you for the bug report. I reproduced your problem and I'm working on a fix.

Comment 2 Martin Kosek 2014-03-04 15:56:33 UTC
Upstream ticket:
https://fedorahosted.org/sssd/ticket/2265

Comment 3 Jakub Hrozek 2014-03-05 11:33:10 UTC
Hi,

a patch was pushed upstream. Can you check if it solves the problem for you?

Here is a F-20 scratch build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=6599567

Comment 4 William Brown 2014-03-12 04:02:12 UTC
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.

Comment 5 Jakub Hrozek 2014-03-12 07:15:29 UTC
(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.

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

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

Comment 6 Fedora Update System 2014-03-12 07:18:17 UTC
sssd-1.11.4-2.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/sssd-1.11.4-2.fc20

Comment 7 Jakub Hrozek 2014-03-12 07:19:03 UTC
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:
https://admin.fedoraproject.org/updates/sssd-1.11.4-2.fc20

Comment 8 Fedora Update System 2014-03-13 05:05:17 UTC
Package sssd-1.11.4-2.fc20:
* 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:
https://admin.fedoraproject.org/updates/FEDORA-2014-3794/sssd-1.11.4-2.fc20
then log in and leave karma (feedback).

Comment 9 William Brown 2014-03-13 21:52:01 UTC
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.

Comment 10 Jakub Hrozek 2014-03-14 07:56:01 UTC
Thanks for testing!

Comment 11 Martin Kosek 2014-03-14 08:21:25 UTC
Thanks indeed. William - your bug reports and testing in FreeIPA and SSSD projects are always very helpful and beneficial to both projects.

Comment 12 Fedora Update System 2014-03-14 08:29:43 UTC
sssd-1.11.4-3.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/sssd-1.11.4-3.fc20

Comment 13 Fedora Update System 2014-04-09 00:55:04 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.