Bug 470514 - gitosis prohibited from authenticating users ssh keys.
gitosis prohibited from authenticating users ssh keys.
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
10
All Linux
medium Severity medium
: ---
: ---
Assigned To: Miroslav Grepl
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-07 09:20 EST by David Nalley
Modified: 2009-11-18 04:40 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-11-18 04:40:33 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Audit log during a gitosis session. (20.06 KB, text/plain)
2009-06-29 11:46 EDT, john5342
no flags Details

  None (edit)
Description David Nalley 2008-11-07 09:20:21 EST
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.
Comment 1 Daniel Walsh 2008-11-07 09:31:28 EST
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.
Comment 2 Bug Zapper 2008-11-25 23:58:47 EST
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
Comment 3 Miroslav Grepl 2009-03-20 11:44:21 EDT
Fixed in  selinux-policy-3.5.13-50.fc10 and selinux-policy-3.3.1-128.fc9
Comment 4 john5342 2009-06-19 18:44:09 EDT
(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
Comment 5 Daniel Walsh 2009-06-20 07:21:39 EDT
Added in selinux-policy-3.6.12-56.fc11
Comment 6 john5342 2009-06-25 08:51:57 EDT
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)
Comment 7 Miroslav Grepl 2009-06-25 09:21:05 EDT
What is your version of selinux-policy-targeted ?

# rpm -q selinux-policy-targeted

Is the same as the version of selinux-policy ?
Comment 8 john5342 2009-06-25 09:30:47 EDT
$ rpm -qa | grep selinux-policy
selinux-policy-3.6.12-59.fc11.noarch
selinux-policy-targeted-3.6.12-59.fc11.noarch
Comment 9 Miroslav Grepl 2009-06-25 10:08:25 EDT
Try to use matchpathcon 

# matchpathcon /var/lib/gitosis
Comment 10 john5342 2009-06-25 10:18:02 EDT
# matchpathcon /var/lib/gitosis
/var/lib/gitosis        system_u:object_r:var_lib_t:s0
Comment 11 Miroslav Grepl 2009-06-26 04:41:52 EDT
Could you try to re-install selinux-policy packages using 

rpm -Uvh --force
Comment 12 john5342 2009-06-26 13:47:21 EDT
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.
Comment 13 Daniel Walsh 2009-06-26 14:24:32 EDT
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.
Comment 14 john5342 2009-06-26 15:02:21 EDT
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?
Comment 15 Daniel Walsh 2009-06-26 15:39:41 EDT
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.
Comment 16 john5342 2009-06-26 16:11:41 EDT
(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?
Comment 17 Daniel Walsh 2009-06-26 16:19:45 EDT
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.
Comment 18 john5342 2009-06-26 16:48:14 EDT
(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
Comment 19 john5342 2009-06-26 18:59:13 EDT
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)
Comment 20 Daniel Walsh 2009-06-29 11:05:57 EDT
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
Comment 21 john5342 2009-06-29 11:46:14 EDT
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
Comment 22 Daniel Walsh 2009-06-29 12:23:24 EDT
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)
Comment 23 Daniel Walsh 2009-06-29 12:25:08 EDT
Miroslav, the interfaces both need files_search_var_lib($1) added to them.
Comment 24 john5342 2009-06-29 16:06:33 EDT
(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.
Comment 25 Daniel Walsh 2009-06-29 16:29:06 EDT
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.
Comment 26 Miroslav Grepl 2009-06-29 17:14:24 EDT
Fixed in selinux-policy-3.6.12-62.fc11
Comment 27 john5342 2009-06-29 19:04:23 EDT
(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.
Comment 28 Bug Zapper 2009-11-18 03:47:20 EST
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

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