Above describes two issues:

1. "SELinux is preventing /bin/bash from execute_no_trans access on the file /usr/libexec/git-core/git-shell."

The actual AVC denial of this event is not enclosed. Without that it is hard to tell what triggered this event.

However i do not believe /bin/bash should run git-shell. Instead sshd should run git-shell i believe

2. "Could not chdir to home directory /home/git: Permission denied
/usr/libexec/git-core/git-shell: Permission denied"

git_shell_t is not allowed to access user home directories. It is only allowed to access properly labeled git repositories. These are expected in /var/lib/git or /srv/git

Two suggestions i can give with the (little) information currently available:

Is the users shell set to /usr/libexec/git-core/git-shell?

Is the repository properly labeled and is it in either /var/lib/git or /srv/git/?

I made two youtube videos touching on all the functionality that the git and git-shell policy provides. The video is of bad quality and it is far from professional but it does showcase most if not all of the features:

Git and git shell in RHEL6 part 1

https://www.youtube.com/watch?v=vgm89P5nbBQ 

Git and git shell in RHEL6 part 2

https://www.youtube.com/watch?v=XHEPj80217o

Dominick,
thank you for your comment here.

You're welcome

I designed policy for git-shell for environments where integrity of the various shared repository is very important.

It is a optional feature that is not configured to be the default.

By default users are mapped to the unconfined_u SELinux identity, which has unrestricted access.

to use the Git shell policy you really need to set the user shell to the git-shell. If you set it to /bin/bash or any other shell, you will encounter AVC denials. Because /bin/bash does things that git-shell does not and should not be able to do.

These AVC denials indicate/signal misconfiguration and that is also why i decided to not hide them from the administrator.

git_shell_t is very minimalistic all it can do is search directories of var_t and var_lib_t (/srv, /var and /var/lib) to be able to traverse to git system repository roots and it can manage generic git shared repositories (repositories labeled with the git_system_content_t type.

if you try something like

git+ssh://user

or

git+ssh://user/home/user

It will be denied access and you will encounter AVC denials. Again these AVC denials indicate misconfiguration and this will help the administrator troubleshoot any issues.

A proper way would be:

git+ssh://user/var/lib/git/repository.git

Not a perfect test, I'm on the road. The box I reported this for is off and only accessible to me on Thursday late evening. I'll recheck there and report back.

But, for now, from my notebook I have with me (x60) that has a checkout from a while ago. (no VPN to home so can not check 100%)

(In reply to comment #6)

[...]
> Is the users shell set to /usr/libexec/git-core/git-shell?

yes. [root@hp-microserver ~]# grep git /etc/passwd
git:x:501:502::/home/git:/usr/libexec/git-core/git-shell

> Is the repository properly labeled and is it in either /var/lib/git or
> /srv/git/?

labels might be the issue, some are 
  system_u:object_r:git_system_content_t:s0
others are
  unconfined_u:object_r:git_system_content_t:s0

Do I presume correctly that the first is what I want? (restorecon -rv /var/lib/git made no changes)

The location is as it should be though:
[pcfe@x60 .git]$ grep url config 
	url = git+ssh://git.pcfe.net/var/lib/git/documents-pcfe-repo.git



As said, I'll look again when I'm near the box on the week-end. I'll set NEEDINFO on me until then.

The labels are both fine it is only about the type field in the security context. The identity field is not applicable in Red Hat distributions most of the time.


All seems fine from the above and i believe it *should* work with these settings

Let us know whether you can reproduce please

(In reply to comment #6)
[...]
> Git and git shell in RHEL6 part 1
> 
> https://www.youtube.com/watch?v=vgm89P5nbBQ 
> 
> Git and git shell in RHEL6 part 2
> 
> https://www.youtube.com/watch?v=XHEPj80217o

Ah, 90 minutes of video on youtube, that's a bit hard for me to watch. Currently I spend most of my time on the road with a machine where I have no flash player (by choice).

Is this information available
- in text format (that would be preferred)?
- in non-flash video format? Not my preferred way but I could at least transcode it and watch it while waiting for yet another plane
?

I've used up this wek-end's spare cycles, sorry, once I have the info in an easier to handle format I'll get back to this bug.

(In reply to comment #10)
[...]
> All seems fine from the above and i believe it *should* work with these
> settings

Damn. And theer I was hoping I just hade made a silly error that's easy to fix. Really wondering why this broke at some point.

> Let us know whether you can reproduce please

Here's the info from the home machine
(host machine accessing)
[pcfe@morn .git]$ grep url config 
	url = git+ssh://git.pcfe.net/var/lib/git/Signatures-repo.git

(on the server. Should this really be user_home_dir_t or is that what I got wrong, git's $home in a place where it ends up with a wrong label after a restorecon of /home or an .autorelabel ?)
[root@hp-microserver ~]# ls -laZ /home/git/
drwxr-xr-x. git  git  git_shell_u:object_r:user_home_dir_t:s0 .
drwxr-xr-x. root root system_u:object_r:home_root_t:s0 ..
drwx------. git  git  git_shell_u:object_r:ssh_home_t:s0 .ssh
-rw-------. git  git  git_shell_u:object_r:xauth_home_t:s0 .Xauthority


(server's audit log, all messages printed when trying to git pull. Sorry I still do not grok SELinux enough to pinpoint what's wrong)
type=CRYPTO_KEY_USER msg=audit(1350728094.489:32766): user pid=10114 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=destroy kind=server fp=6c:65:30:79:df:55:52:58:13:80:68:d1:d0:89:4c:ea direction=? spid=10114 suid=0  exe="/usr/sbin/sshd" hostname=? addr=192.168.50.7 terminal=? res=success'
type=CRYPTO_KEY_USER msg=audit(1350728094.489:32767): user pid=10114 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=destroy kind=server fp=b6:c2:bd:71:c7:54:24:62:ae:92:9a:5a:e8:73:f0:6a direction=? spid=10114 suid=0  exe="/usr/sbin/sshd" hostname=? addr=192.168.50.7 terminal=? res=success'
type=CRYPTO_SESSION msg=audit(1350728094.493:32768): user pid=10113 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=start direction=from-client cipher=aes128-ctr ksize=128 spid=10114 suid=74 rport=47986 laddr=192.168.50.250 lport=22  exe="/usr/sbin/sshd" hostname=? addr=192.168.50.7 terminal=? res=success'
type=CRYPTO_SESSION msg=audit(1350728094.494:32769): user pid=10113 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=start direction=from-server cipher=aes128-ctr ksize=128 spid=10114 suid=74 rport=47986 laddr=192.168.50.250 lport=22  exe="/usr/sbin/sshd" hostname=? addr=192.168.50.7 terminal=? res=success'
type=USER_AUTH msg=audit(1350728094.592:32770): user pid=10113 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=pubkey_auth rport=47986 acct="git" exe="/usr/sbin/sshd" hostname=? addr=192.168.50.7 terminal=? res=success'
type=USER_AUTH msg=audit(1350728094.592:32771): user pid=10113 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=key algo=ssh-rsa size=4096 fp=49:bc:6a:9c:60:eb:38:be:4c:20:76:19:65:82:d3:58 rport=47986 acct="git" exe="/usr/sbin/sshd" hostname=? addr=192.168.50.7 terminal=? res=success'
type=USER_ACCT msg=audit(1350728094.603:32772): user pid=10113 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=PAM:accounting acct="git" exe="/usr/sbin/sshd" hostname=morn.internal.pcfe.net addr=192.168.50.7 terminal=ssh res=success'
type=CRYPTO_KEY_USER msg=audit(1350728094.603:32773): user pid=10113 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=destroy kind=session fp=? direction=both spid=10114 suid=74 rport=47986 laddr=192.168.50.250 lport=22  exe="/usr/sbin/sshd" hostname=? addr=192.168.50.7 terminal=? res=success'
type=USER_AUTH msg=audit(1350728094.604:32774): user pid=10113 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=success acct="git" exe="/usr/sbin/sshd" hostname=? addr=192.168.50.7 terminal=ssh res=success'
type=CRED_ACQ msg=audit(1350728094.606:32775): user pid=10113 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=PAM:setcred acct="git" exe="/usr/sbin/sshd" hostname=morn.internal.pcfe.net addr=192.168.50.7 terminal=ssh res=success'
type=LOGIN msg=audit(1350728094.606:32776): pid=10113 uid=0 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 old auid=4294967295 new auid=501 old ses=4294967295 new ses=5329
type=USER_ROLE_CHANGE msg=audit(1350728094.610:32777): user pid=10113 uid=0 auid=501 ses=5329 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='pam: default-context=git_shell_u:git_shell_r:git_shell_t:s0 selected-context=git_shell_u:git_shell_r:git_shell_t:s0 exe="/usr/sbin/sshd" hostname=morn.internal.pcfe.net addr=192.168.50.7 terminal=ssh res=success'
type=USER_START msg=audit(1350728094.612:32778): user pid=10113 uid=0 auid=501 ses=5329 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=PAM:session_open acct="git" exe="/usr/sbin/sshd" hostname=morn.internal.pcfe.net addr=192.168.50.7 terminal=ssh res=success'
type=CRYPTO_KEY_USER msg=audit(1350728094.613:32779): user pid=10113 uid=0 auid=501 ses=5329 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=destroy kind=session fp=? direction=both spid=10113 suid=0 rport=47986 laddr=192.168.50.250 lport=22  exe="/usr/sbin/sshd" hostname=? addr=192.168.50.7 terminal=? res=success'
type=CRYPTO_KEY_USER msg=audit(1350728094.614:32780): user pid=10116 uid=0 auid=501 ses=5329 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=destroy kind=server fp=6c:65:30:79:df:55:52:58:13:80:68:d1:d0:89:4c:ea direction=? spid=10116 suid=0  exe="/usr/sbin/sshd" hostname=? addr=192.168.50.7 terminal=? res=success'
type=CRYPTO_KEY_USER msg=audit(1350728094.614:32781): user pid=10116 uid=0 auid=501 ses=5329 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=destroy kind=server fp=b6:c2:bd:71:c7:54:24:62:ae:92:9a:5a:e8:73:f0:6a direction=? spid=10116 suid=0  exe="/usr/sbin/sshd" hostname=? addr=192.168.50.7 terminal=? res=success'
type=CRED_ACQ msg=audit(1350728094.617:32782): user pid=10116 uid=0 auid=501 ses=5329 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=PAM:setcred acct="git" exe="/usr/sbin/sshd" hostname=morn.internal.pcfe.net addr=192.168.50.7 terminal=ssh res=success'
type=AVC msg=audit(1350728094.625:32783): avc:  denied  { getattr } for  pid=10116 comm="sshd" path="/usr/bin/xauth" dev=dm-0 ino=159112 scontext=git_shell_u:git_shell_r:git_shell_t:s0 tcontext=system_u:object_r:xauth_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1350728094.625:32783): arch=c000003e syscall=4 success=no exit=-13 a0=7f2800115db9 a1=7fffb5e12120 a2=7fffb5e12120 a3=21 items=0 ppid=10113 pid=10116 auid=501 uid=501 gid=502 euid=501 suid=501 fsuid=501 egid=502 sgid=502 fsgid=502 tty=(none) ses=5329 comm="sshd" exe="/usr/sbin/sshd" subj=git_shell_u:git_shell_r:git_shell_t:s0 key=(null)
type=USER_LOGIN msg=audit(1350728094.631:32784): user pid=10113 uid=0 auid=501 ses=5329 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login id=501 exe="/usr/sbin/sshd" hostname=morn.internal.pcfe.net addr=192.168.50.7 terminal=ssh res=success'
type=USER_START msg=audit(1350728094.632:32785): user pid=10113 uid=0 auid=501 ses=5329 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login id=501 exe="/usr/sbin/sshd" hostname=morn.internal.pcfe.net addr=192.168.50.7 terminal=ssh res=success'
type=AVC msg=audit(1350728094.636:32786): avc:  denied  { execute_no_trans } for  pid=10119 comm="sshd" path="/usr/libexec/git-core/git-shell" dev=dm-0 ino=173598 scontext=git_shell_u:git_shell_r:git_shell_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1350728094.636:32786): arch=c000003e syscall=59 success=no exit=-13 a0=7f2801482010 a1=7fffb5e12100 a2=7f280148b880 a3=0 items=0 ppid=10116 pid=10119 auid=501 uid=501 gid=502 euid=501 suid=501 fsuid=501 egid=502 sgid=502 fsgid=502 tty=(none) ses=5329 comm="sshd" exe="/usr/sbin/sshd" subj=git_shell_u:git_shell_r:git_shell_t:s0 key=(null)
type=AVC msg=audit(1350728094.641:32787): avc:  denied  { create } for  pid=10116 comm="sshd" scontext=git_shell_u:git_shell_r:git_shell_t:s0 tcontext=git_shell_u:git_shell_r:git_shell_t:s0 tclass=unix_dgram_socket
type=SYSCALL msg=audit(1350728094.641:32787): arch=c000003e syscall=41 success=no exit=-13 a0=1 a1=80002 a2=0 a3=1 items=0 ppid=10113 pid=10116 auid=501 uid=501 gid=502 euid=501 suid=501 fsuid=501 egid=502 sgid=502 fsgid=502 tty=(none) ses=5329 comm="sshd" exe="/usr/sbin/sshd" subj=git_shell_u:git_shell_r:git_shell_t:s0 key=(null)
type=CRYPTO_KEY_USER msg=audit(1350728094.642:32788): user pid=10113 uid=0 auid=501 ses=5329 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=destroy kind=session fp=? direction=both spid=10116 suid=501 rport=47986 laddr=192.168.50.250 lport=22  exe="/usr/sbin/sshd" hostname=? addr=192.168.50.7 terminal=? res=success'
type=USER_END msg=audit(1350728094.645:32789): user pid=10113 uid=0 auid=501 ses=5329 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=PAM:session_close acct="git" exe="/usr/sbin/sshd" hostname=morn.internal.pcfe.net addr=192.168.50.7 terminal=ssh res=success'
type=CRED_DISP msg=audit(1350728094.646:32790): user pid=10113 uid=0 auid=501 ses=5329 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=PAM:setcred acct="git" exe="/usr/sbin/sshd" hostname=morn.internal.pcfe.net addr=192.168.50.7 terminal=ssh res=success'
type=USER_END msg=audit(1350728094.647:32791): user pid=10113 uid=0 auid=501 ses=5329 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login id=501 exe="/usr/sbin/sshd" hostname=morn.internal.pcfe.net addr=192.168.50.7 terminal=ssh res=success'
type=USER_LOGOUT msg=audit(1350728094.648:32792): user pid=10113 uid=0 auid=501 ses=5329 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login id=501 exe="/usr/sbin/sshd" hostname=morn.internal.pcfe.net addr=192.168.50.7 terminal=ssh res=success'
type=CRYPTO_KEY_USER msg=audit(1350728094.648:32793): user pid=10113 uid=0 auid=501 ses=5329 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=destroy kind=server fp=6c:65:30:79:df:55:52:58:13:80:68:d1:d0:89:4c:ea direction=? spid=10113 suid=0  exe="/usr/sbin/sshd" hostname=? addr=192.168.50.7 terminal=? res=success'
type=CRYPTO_KEY_USER msg=audit(1350728094.648:32794): user pid=10113 uid=0 auid=501 ses=5329 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=destroy kind=server fp=b6:c2:bd:71:c7:54:24:62:ae:92:9a:5a:e8:73:f0:6a direction=? spid=10113 suid=0  exe="/usr/sbin/sshd" hostname=? addr=192.168.50.7 terminal=? res=success'

Miroslav, did anything change in ssh with regard to SELinux in el6.5? I suspect it has.

I guess we may need to allow this

Well, we have the privsep patch as we have it in Fedora.

Looks like
sshd_t did a setcon(git_shell_t)?

I back port git policy from Fedora.

The latest policy does not define any git_shell_t type anymore. Was the type removed completely or just renamed?

# rpm -qa selinux-policy\*
selinux-policy-mls-3.7.19-227.el6.noarch
selinux-policy-doc-3.7.19-227.el6.noarch
selinux-policy-3.7.19-227.el6.noarch
selinux-policy-minimum-3.7.19-227.el6.noarch
selinux-policy-targeted-3.7.19-227.el6.noarch
# sestatus 
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   enforcing
Mode from config file:          enforcing
Policy version:                 24
Policy from config file:        targeted
# seinfo -t | grep git_shell_t
# seinfo -tgit_shell_t -x
ERROR: could not find datum for type git_shell_t
#

Yes, it was the bad direction with git_shell_t so it has been removed. A user should not end up with this type.

Whether git_shell_t, or sshd doing a setcon was/is a bad direction is debatable

I do not know of any compelling reason why sshd cannot just transition to user domains upon running a shell, and why it is now doing a setcon instead. ( i am in favor of keeping selinux transparant to as many processes on the system as possible, and as much as possible. Therefore i am favor the old way over the setcon way)

More over i do not understand why this change had to happen in RHEL6 as i do not see changing this as being a critical fix.

git_shell_t was a nice feature, but was unfortunately pretty much unused, and misunderstood. People that want/need to get the most out of SELinux are expected to be able to use the framework themselves in ways to achieve solutions like git_shell_t.

(In reply to Dominick Grift from comment #25)
> Whether git_shell_t, or sshd doing a setcon was/is a bad direction is
> debatable
> 
> I do not know of any compelling reason why sshd cannot just transition to
> user domains upon running a shell, and why it is now doing a setcon instead.
> ( i am in favor of keeping selinux transparant to as many processes on the
> system as possible, and as much as possible. Therefore i am favor the old
> way over the setcon way)
> 
> More over i do not understand why this change had to happen in RHEL6 as i do
> not see changing this as being a critical fix.
> 

See previous comments.

Which comments are you referring to in particular?

I am aware of the previous comments, and i agreed that git_shell_t would be better off removed, but for different reasons.

That is not my point though.

I am just stating here for the record that i question the "sshd does a setcon" developments, and functionality.

I am also stating here for the record the git_shell_t is a nice example of how SELinux can add value, I just admit that it probably should not have been implemented by default in enterprise Linux.

Let me just get this straight here:

RHEL6 initially shipped with an SSHd that did not do setcon. git_shell_t worked fine then (so did chroot_user_t). Then somewhere around 6.3, 6.4 all of a sudden SSHd was changed to do a setcon, and this had broken git_shell_t, and so did chroot_user_t)

Now, due to this SSHd setcon change we extended the guest_t domain to conditionally allow it setuid/setgid just to get it to work with SSHd chroots

Basically, the way i see it, this setcon change should not have been implemented in RHEL6 because its not a critical fix.

Things worked fine in 6.0, now not so much (i am referring to the chroot_user_t versus guest_t with setuid/setgid debacle)

(In reply to Dominick Grift from comment #28)
> Let me just get this straight here:
> 
> RHEL6 initially shipped with an SSHd that did not do setcon. git_shell_t
> worked fine then (so did chroot_user_t). Then somewhere around 6.3, 6.4 all
> of a sudden SSHd was changed to do a setcon, and this had broken
> git_shell_t, and so did chroot_user_t)
> 
> Now, due to this SSHd setcon change we extended the guest_t domain to
> conditionally allow it setuid/setgid just to get it to work with SSHd chroots
> 
> Basically, the way i see it, this setcon change should not have been
> implemented in RHEL6 because its not a critical fix.

Dominick,
this is not true. Yes, it causes some problems in RHEL6 but AFAIK we have been talking about that.

> 
> Things worked fine in 6.0, now not so much (i am referring to the
> chroot_user_t versus guest_t with setuid/setgid debacle)

What exactly is not true? That it is not a critical fix?

(In reply to Dominick Grift from comment #30)
> What exactly is not true? That it is not a critical fix?

Yes. I would not generalise it how you wrote

"this setcon change should not have been implemented in RHEL6 because its not a critical fix."

RHEL6 is not just about a critical fixes.

Alright, thanks for clarifying this

I guess that might be RHEL6 policy change then. I seem to recall that in the past usually only critical fixes were applied in service packs rather than implementing new features.

Maybe that is just a misconception on my side

Sorry about the inconvenience caused by this noise

(In reply to Dominick Grift from comment #32)
> Alright, thanks for clarifying this
> 
> I guess that might be RHEL6 policy change then. I seem to recall that in the
> past usually only critical fixes were applied in service packs rather than
> implementing new features.
> 
> Maybe that is just a misconception on my side
> 
> Sorry about the inconvenience caused by this noise

No problem. Thank you for your help.

Dominic lets have a conversation on IRC on this with Miroslav on Monday.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-1598.html