Bug 470514
| Summary: | gitosis prohibited from authenticating users ssh keys. | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | David Nalley <david> | ||||
| Component: | selinux-policy-targeted | Assignee: | Miroslav Grepl <mgrepl> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Ben Levenson <benl> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 10 | CC: | dwalsh, ivaxer, john5342 | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2009-11-18 09:40:33 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
gitosis should have a policy written for it. It is fairly easy to label /var/lib/gitosis correctly and the .ssh subdirectory, but we should probably have a general purpose policy for it. This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Fixed in selinux-policy-3.5.13-50.fc10 and selinux-policy-3.3.1-128.fc9 (In reply to comment #3) > Fixed in selinux-policy-3.5.13-50.fc10 and selinux-policy-3.3.1-128.fc9 Is there any chance of this getting fixed in F11 too? Getting the exact same denial using: selinux-policy-targeted-3.6.12-45.fc11 Added in selinux-policy-3.6.12-56.fc11 Using selinux-policy-3.6.12-59.fc11 but still no luck. Relabelled the entire file system just to be sure but still no joy. Labels and denial after following full relabel. # ls -aZ /var/lib/gitosis drwxr-xr-x. gitosis gitosis system_u:object_r:var_lib_t:s0 . drwxr-xr-x. root root system_u:object_r:var_lib_t:s0 .. drwxr-xr-x. gitosis gitosis system_u:object_r:var_lib_t:s0 gitosis lrwxrwxrwx. gitosis gitosis system_u:object_r:var_lib_t:s0 .gitosis.conf -> /var/lib/gitosis/repositories/gitosis-admin.git/gitosis.conf drwxr-xr-x. gitosis gitosis system_u:object_r:var_lib_t:s0 repositories drwx------. gitosis gitosis system_u:object_r:var_lib_t:s0 .ssh Summary: SELinux is preventing sshd (sshd_t) "read" var_lib_t. Detailed Description: SELinux denied access requested by sshd. It is not expected that this access is required by sshd and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 Target Context system_u:object_r:var_lib_t:s0 Target Objects authorized_keys [ file ] Source sshd Source Path /usr/sbin/sshd Port <Unknown> Host localhost.localdomain Source RPM Packages openssh-server-5.2p1-2.fc11 Target RPM Packages Policy RPM selinux-policy-3.6.12-59.fc11 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall Host Name localhost.localdomain Platform Linux localhost.localdomain 2.6.29.4-167.fc11.x86_64 #1 SMP Wed May 27 17:27:08 EDT 2009 x86_64 x86_64 Alert Count 2 First Seen Thu 25 Jun 2009 01:21:16 PM BST Last Seen Thu 25 Jun 2009 01:45:01 PM BST Local ID ffe0fdad-96c9-492c-b1cc-bd58ac0f39d9 Line Numbers Raw Audit Messages node=localhost.localdomain type=AVC msg=audit(1245933901.764:31): avc: denied { read } for pid=3037 comm="sshd" name="authorized_keys" dev=sda3 ino=123635 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_lib_t:s0 tclass=file node=localhost.localdomain type=SYSCALL msg=audit(1245933901.764:31): arch=c000003e syscall=2 success=no exit=-13 a0=7ff88e13b010 a1=800 a2=1 a3=7ff88becf7b0 items=0 ppid=2742 pid=3037 auid=500 uid=0 gid=0 euid=489 suid=0 fsuid=489 egid=480 sgid=0 fsgid=480 tty=(none) ses=1 comm="sshd" exe="/usr/sbin/sshd" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) What is your version of selinux-policy-targeted ? # rpm -q selinux-policy-targeted Is the same as the version of selinux-policy ? $ rpm -qa | grep selinux-policy selinux-policy-3.6.12-59.fc11.noarch selinux-policy-targeted-3.6.12-59.fc11.noarch Try to use matchpathcon # matchpathcon /var/lib/gitosis # matchpathcon /var/lib/gitosis /var/lib/gitosis system_u:object_r:var_lib_t:s0 Could you try to re-install selinux-policy packages using rpm -Uvh --force Here is something new. Dont know if this is a seperate bug or related but here is the output. # rpm -Uvh --force selinux-policy-3.6.12-59.fc11.noarch.rpm selinux-policy-targeted-3.6.12-59.fc11.noarch.rpm Preparing... ########################################### [100%] 1:selinux-policy ########################################### [ 50%] 2:selinux-policy-targeted########################################### [100%] libsemanage.validate_handler: selinux user unconfined_u does not exist libsemanage.validate_handler: seuser mapping [root -> (unconfined_u, s0-s0:c0.c1023)] is invalid libsemanage.dbase_llist_iterate: could not iterate over records semodule: Failed! Output of matchpathcon /var/lib/gitosis is unchanged from previous comment. You seem to not have the unconfineduser.pp package installed? # semodule -i /usr/share/selinux/targeted/unconfineduser.pp.bz2 Looks like you might have had an update problem. Then try to install the package again. And the problems go on. # semodule -i /usr/share/selinux/targeted/unconfineduser.pp.bz2 libsemanage.semanage_link_sandbox: Could not access sandbox base file /etc/selinux/targeted/modules/tmp/base.pp. (No such file or directory). semodule: Failed! Not knowing how selinux works i dont know what further to try but although it might get cleaned up after use /etc/selinux/targeted/modules/tmp directory does not exist. In case of that file coming from another file i checked and confirmed /usr/share/selinux/targeted/base.pp.bz2 exists. Tested both unconfineduser.pp.bz2 and base.pp.bz2 using bzip2 -tv and they both checked out fine. Should i start a new bug for this problem or is it related to the original bug report? I have no idea how you got this machine screwed up, Probably an upgrade failure. Do the following: # setenforce 0 # rm -rf /etc/selinux/targeted # yum reinstall selinux-policy-targeted # restorecon -R -v /etc You might want to execute #touch /.autorelabel; reboot TO make sure all of the labeling is correct. Then you can get back to the original bug in gitosis. (In reply to comment #15) > I have no idea how you got this machine screwed up, Probably an upgrade > failure. Not an upgrade. Just a fresh install plus standard updates plus the selinux-policy and selinux-policy-targeted mentioned earlier in the bug report. > Do the following: > > # setenforce 0 > # rm -rf /etc/selinux/targeted > # yum reinstall selinux-policy-targeted > # restorecon -R -v /etc > > You might want to execute > #touch /.autorelabel; reboot Did this and now selinux is comprehensively messed up. I can just about log in as root from a terminal (Alt+F2) with many denials and then cant even run reboot without yet more denials. Supplying enforcing=0 as a kernel parameter got me in again but no idea where to go from here. Any further ideas? In permissive mode execute # yum -y upgrade policycoreutils --enablerepo=updates-testing # fixfiles restore This should take some time? You still have to have a labeling problem. BTW What file system are you using. (In reply to comment #17) > In permissive mode execute > > # yum -y upgrade policycoreutils --enablerepo=updates-testing > # fixfiles restore # fixfiles restore ***********************************************************/sbin/setfiles: unable to stat file /home/john/.gvfs: Permission denied /sbin/setfiles: error while labeling /: Permission denied /sbin/setfiles: error while labeling /boot: Permission denied > This should take some time? > > > You still have to have a labeling problem. BTW What file system are you using. Using ext4 Despite the above error running fixfiles i did an autorelabel which this time ran properly and system seems perfectly usable without any denials in enforcing mode. Upgraded selinux-policy and selinux-policy-targeted to version 3.6.12-56.fc11 this time just in case it was 3.6.12-59.fc11 that caused the trouble. Update seemd to go fine and output of matchpathcon now looks more correct: # matchpathcon /var/lib/gitosis /var/lib/gitosis system_u:object_r:gitosis_var_lib_t:s0 However git clone gitosis@localhost:gitosis-admin.git now gives me a new denial: Summary: SELinux is preventing sshd (sshd_t) "search" gitosis_var_lib_t. Detailed Description: SELinux denied access requested by sshd. It is not expected that this access is required by sshd and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 Target Context system_u:object_r:gitosis_var_lib_t:s0 Target Objects /var/lib/gitosis [ dir ] Source sshd Source Path /usr/sbin/sshd Port <Unknown> Host localhost.localdomain Source RPM Packages openssh-server-5.2p1-2.fc11 Target RPM Packages gitosis-0.2-8.20080825git.fc11 Policy RPM selinux-policy-3.6.12-56.fc11 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall Host Name localhost.localdomain Platform Linux localhost.localdomain 2.6.29.5-191.fc11.x86_64 #1 SMP Tue Jun 16 23:23:21 EDT 2009 x86_64 x86_64 Alert Count 2 First Seen Fri 26 Jun 2009 11:40:29 PM BST Last Seen Fri 26 Jun 2009 11:40:29 PM BST Local ID 13e6fbf9-f44e-4308-a8ad-b129e96ff57d Line Numbers Raw Audit Messages node=localhost.localdomain type=AVC msg=audit(1246056029.144:31): avc: denied { search } for pid=3014 comm="sshd" name="gitosis" dev=sda3 ino=123581 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:gitosis_var_lib_t:s0 tclass=dir node=localhost.localdomain type=SYSCALL msg=audit(1246056029.144:31): arch=c000003e syscall=2 success=no exit=-13 a0=7f5a20893010 a1=800 a2=1 a3=7f5a1e9f97b0 items=0 ppid=3010 pid=3014 auid=500 uid=0 gid=0 euid=489 suid=0 fsuid=489 egid=480 sgid=0 fsgid=480 tty=(none) ses=1 comm="sshd" exe="/usr/sbin/sshd" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) Seems legitimate. Can you get all of the access required for sshd_t by running it in permissive mode? # semanage permissive -a sshd_t Run you git stuff. #semanage permissive -d sshd_t Then grab all of the avc's generated and attach to this bug report. # ausearch -m AVC -su sshd_t > /tmp/audit.log Created attachment 349802 [details]
Audit log during a gitosis session.
Due to this bug i havent yet put gitosis into production use yet so there might be other usage not covered in this basic session. Covers setting up, creating a new repo and pushing to it.
Please note that all entries before 29 Jun in the attatched log were either before the new selinux policy or with corrupt file labels. Log entries on 29 Jun were using selinux-policy(-targeted)-3.6.12-56.fc11
John, does it need to write if you push gitcontent back up? I would imagine we need to add either gitosis_read_var_lib(sshd_t) or gitosis_manage_var_lib(sshd_t) Miroslav, the interfaces both need files_search_var_lib($1) added to them. (In reply to comment #22) > John, does it need to write if you push gitcontent back up? All git content pushed up is stored in /var/lib/gitosis/repositories/<name_of_repo> All gitosis management tasks are done by doing a standard git push to /var/lib/gitosis/repositories/gitosis-admin.git/ which automatically (through git hooks) modifies the various configuration files and authorized_keys to enforce the appropriate policies. Hope that answers your question. > I would imagine we need to add either > > gitosis_read_var_lib(sshd_t) > > or > > > gitosis_manage_var_lib(sshd_t) I have no idea how selinux works. I assume this was aimed at somebody else or otherwise i don't have a clue. John, yes. The function calls were aimed at the bug owner.
Miroslav, you need to add
optional_policy(`
gitosis_manage_var_lib(sshd_t)
')
And add files_search_var_lib($1) to all gitosis.*var_lib interfaces.
Fixed in selinux-policy-3.6.12-62.fc11 (In reply to comment #26) > Fixed in selinux-policy-3.6.12-62.fc11 This update appears to fix all gitosis denials for me. Thank you Miroslav and Daniel for your speedy responses, help and fixes. This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping |
Description of problem: gitosis creates a user gitosis with a homedir of /var/lib/gitosis. Upon initializing gitosis, it creates a .ssh folder in that homedir with one or more public keys residing in authorized_keys. Unfortunately because it lives in /var/lib it has the file context of var_lib_t and of course sshd can't touch that file. Version-Release number of selected component (if applicable): selinux-policy-targeted-3.5.13-11.fc10.noarch How reproducible: Everytime Steps to Reproduce: 1. Initialize gitosis with selinux enforced. 2. Attempt to clone gitosis-admin from a remote machine via git+ssh 3. Fail Actual results: Nov 6 23:50:57 git kernel: type=1400 audit(1226033457.670:4): avc: denied { read } for pid=15252 comm="sshd" name="authorized_keys" dev=dm-0 ino=35297 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file Nov 6 23:58:19 git kernel: type=1400 audit(1226033899.632:5): avc: denied { read } for pid=15288 comm="sshd" name="authorized_keys" dev=dm-0 ino=35297 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file Expected results: Success in cloning gitosis-admin repo. Additional info: from /var/lib/gitosis: -sh-3.2$ ls -aZ drwxr-xr-x gitosis gitosis system_u:object_r:var_lib_t:s0 . drwxr-xr-x root root system_u:object_r:var_lib_t:s0 .. -rw------- gitosis gitosis unconfined_u:object_r:var_lib_t:s0 .bash_history drwxr-xr-x gitosis gitosis unconfined_u:object_r:var_lib_t:s0 gitosis lrwxrwxrwx gitosis gitosis unconfined_u:object_r:var_lib_t:s0 .gitosis.conf -> /var/lib/gitosis/repositories/gitosis-admin.git/gitosis.conf drwxr-xr-x gitosis gitosis unconfined_u:object_r:var_lib_t:s0 repositories drwx------ gitosis gitosis unconfined_u:object_r:var_lib_t:s0 .ssh -sh-3.2$ cd .ssh/ -sh-3.2$ ls -aZ drwx------ gitosis gitosis unconfined_u:object_r:var_lib_t:s0 . drwxr-xr-x gitosis gitosis system_u:object_r:var_lib_t:s0 .. -rw------- gitosis gitosis unconfined_u:object_r:var_lib_t:s0 authorized_keys -sh-3.2$ One can of course change the file context, but shouldn't have to.