Bug 736623 - cgit does not work with default selinux policy
Summary: cgit does not work with default selinux policy
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: selinux-policy
Version: 6.1
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: 6.1
Assignee: Miroslav Grepl
QA Contact: Milos Malik
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-09-08 09:38 UTC by Sander Hoentjen
Modified: 2012-12-06 14:19 UTC (History)
5 users (show)

Fixed In Version: selinux-policy-3.7.19-112.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-12-06 10:18:32 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:1511 normal SHIPPED_LIVE selinux-policy bug fix and enhancement update 2011-12-06 00:39:17 UTC

Description Sander Hoentjen 2011-09-08 09:38:14 UTC
Description of problem:
When running selinux in enforcing mode, gitolite does not show the list of projects

Version-Release number of selected component (if applicable):
cgit-0.9.0.2-2.el6.x86_64

How reproducible:
always

Steps to Reproduce:
1. install cgit
2. install lighttpd
3. put some git projects in place
4. show cgit webinterface
  
Actual results:
list is empty

Expected results:
list shows all defined projects

Additional info:
audit log (selinux in permissive) shows:
type=AVC msg=audit(1315471457.034:650168): avc:  denied  { search } for  pid=32165 comm="cgit" name="gitolite" dev=dm-0 ino=6384 scontext=unconfined_u:system_r:httpd_git_script_t:s0 tcontext=system_u:object_r:gitosis_var_lib_t:s0 tclass=dir
type=AVC msg=audit(1315471457.034:650168): avc:  denied  { read } for  pid=32165 comm="cgit" name="projects.list" dev=dm-0 ino=3704 scontext=unconfined_u:system_r:httpd_git_script_t:s0 tcontext=unconfined_u:object_r:gitosis_var_lib_t:s0 tclass=file
type=AVC msg=audit(1315471457.034:650168): avc:  denied  { open } for  pid=32165 comm="cgit" name="projects.list" dev=dm-0 ino=3704 scontext=unconfined_u:system_r:httpd_git_script_t:s0 tcontext=unconfined_u:object_r:gitosis_var_lib_t:s0 tclass=file
type=AVC msg=audit(1315471457.034:650169): avc:  denied  { getattr } for  pid=32165 comm="cgit" path="/var/lib/gitolite/projects.list" dev=dm-0 ino=3704 scontext=unconfined_u:system_r:httpd_git_script_t:s0 tcontext=unconfined_u:object_r:gitosis_var_lib_t:s0 tclass=file
type=AVC msg=audit(1315471457.034:650170): avc:  denied  { search } for  pid=32165 comm="cgit" name="repositories" dev=dm-0 ino=6340 scontext=unconfined_u:system_r:httpd_git_script_t:s0 tcontext=unconfined_u:object_r:gitosis_var_lib_t:s0 tclass=dir
type=AVC msg=audit(1315471457.034:650170): avc:  denied  { read } for  pid=32165 comm="cgit" name="aanmaning.git" dev=dm-0 ino=138354 scontext=unconfined_u:system_r:httpd_git_script_t:s0 tcontext=unconfined_u:object_r:gitosis_var_lib_t:s0 tclass=dir
type=AVC msg=audit(1315471457.034:650170): avc:  denied  { open } for  pid=32165 comm="cgit" name="aanmaning.git" dev=dm-0 ino=138354 scontext=unconfined_u:system_r:httpd_git_script_t:s0 tcontext=unconfined_u:object_r:gitosis_var_lib_t:s0 tclass=dir
type=AVC msg=audit(1315471457.034:650171): avc:  denied  { getattr } for  pid=32165 comm="cgit" path="/var/lib/gitolite/repositories/dev/project.git/objects" dev=dm-0 ino=138386 scontext=unconfined_u:system_r:httpd_git_script_t:s0 tcontext=unconfined_u:object_r:gitosis_var_lib_t:s0 tclass=dir

audit2allow tells me:
#============= httpd_git_script_t ==============
allow httpd_git_script_t gitosis_var_lib_t:dir { read search open getattr };
allow httpd_git_script_t gitosis_var_lib_t:file { read getattr open };

Comment 1 Todd Zullinger 2011-09-08 13:52:11 UTC
This looks to be trouble between using gitolite and cgit.  The README.SELinux file shipped with cgit says that if you have repos in a non-default location (with /var/lib/git being the default location), you should run:

    semanage fcontext -a -t httpd_sys_content_t "/srv/git(/.*)?"

Whether that's possible or advisable when using gitolite, which seems to have it's own policy and labels is a question for the good folks that manage the selinux-policy.  I'll try to move the product/component to RHEL6/selinux-policy.

Comment 3 Miroslav Grepl 2011-09-09 07:44:25 UTC
I have no problem with allowing this.

Comment 4 Milos Malik 2011-09-14 08:15:10 UTC
I'm not familiar with cgit, gitolite etc. Could you be more specific in following steps:

3. put some git projects in place
4. show cgit web interface

Comment 5 Miroslav Grepl 2011-09-14 08:28:59 UTC
Milos,
you need just create a git repo in

/var/lib/gitolite/repositories

and setup cgit to show this repo in your web browser.

Comment 6 Dominick Grift 2011-09-14 08:39:05 UTC
The issue described above is:

1. Git repositories are not in the usual Git location ( /var/lib/git or
/srv/git ), but rather in gitolites usual location ( /var/lib/gitolite/.* )

2. cgit ( the httpd_git_script_t domain ) currently only supports git
repositories in /var/lib/git or /srv/git. It is currently not allowed to read
Git repositories in /var/lib/gitolite. (at least last time i checked)

So the solution would be to:

Support Cgit/Gitweb hosting Git repositories in /var/lib/gitolite. ( allow
httpd_git_script_t to read gitolite_var_lib_t directories and files )

This would need to be added to policy. ( that is the simple solution )

We might however need to consider what other contents gitolite stores in
/var/lib/gitolite. If it is sensitive stuff like login credentials then we may
want to implement a named file transition to a git content type when Git
repositories are created in Gitolites var lib directories as opposed to Gits
var lib directory.

The easiest solution would be to store your Git repository content in the
correct place ( /var/lib/git or /srv/git ) and tell gitolite to look for it/
manage it there.

Comment 7 Ewoud Kohl van Wijngaarden 2011-09-14 09:28:08 UTC
(In reply to comment #6)
> Support Cgit/Gitweb hosting Git repositories in /var/lib/gitolite. ( allow
> httpd_git_script_t to read gitolite_var_lib_t directories and files )
Note that gitolite uses gitosis_var_lib_t.

Comment 8 Dominick Grift 2011-09-14 09:37:37 UTC
(In reply to comment #7)
> (In reply to comment #6)
> > Support Cgit/Gitweb hosting Git repositories in /var/lib/gitolite. ( allow
> > httpd_git_script_t to read gitolite_var_lib_t directories and files )
> Note that gitolite uses gitosis_var_lib_t.

Right , that is because gitolite is the new gitosis ( so i meant gitosis_var_lib_t )

Comment 9 Miroslav Grepl 2011-09-14 09:47:05 UTC
I believe we can allow it since we have

/var/lib/gitolite/\.ssh(/.*)?       gen_context(system_u:object_r:ssh_home_t,s0)

We don't have file name transition in RHEL6.

Comment 10 Dominick Grift 2011-09-14 10:54:12 UTC
Please consider adding a file context spec for /var/lib/gitolite/repositories(/.*)? with type git_system_content_t, and then allow git_system_t, git_shell_t, and httpd_git_script_t to search gitosis_var_lib_t.

This solution seem better to me. Because just allowing cgit to read gitosis_var_lib_t content breaks stuff since git_system_t still cannot host/read it, and git_shell_t wont be able to manage/execute git repositories there.

Comment 11 Dominick Grift 2011-09-14 11:00:28 UTC
In that case also make sure that gitolite can interact with any git shared repository content type. (probably should already?)

Comment 12 Miroslav Grepl 2011-09-14 11:07:50 UTC
The problem with this is "/var/lib/gitolite/repositories" is not owned by gitolite package. 

Also it looks like a lot of changes in RHEL6 in this phase. 


Sander,
if you execute

# grep gitosis /var/log/audit/audit.log |audit2allow -M mygitosis
# semodule -i mygitosis.pp


Does it work then?

Comment 13 Ewoud Kohl van Wijngaarden 2011-09-14 11:29:03 UTC
(In reply to comment #12)
> Sander,
> if you execute
> 
> # grep gitosis /var/log/audit/audit.log |audit2allow -M mygitosis
> # semodule -i mygitosis.pp
> 
> 
> Does it work then?
As Sanders colleague I can tell that we've already done so on our production machine and it works.

Comment 14 Dominick Grift 2011-09-14 11:37:29 UTC
Now i get it i think: This is some exotic user configuration? (in other words a misconfiguration or atleast a configration not supported.)

I was already surprised that gitosis/cgit/gitweb would not work in EL6.1, but this explains it.

Git repositories belong in /var/lib/git or /srv/git, and not in /var/lib/gitolite/repositories.

Comment 15 Ewoud Kohl van Wijngaarden 2011-09-14 12:31:29 UTC
Since it's the default gitolite behavior to place it there we assumed it's a bug, especially since it worked before we updated cgit from 0.9-1 to 0.9.0.2-2.

Your solution would be to move the repositories instead of changing the policy?

Comment 16 Dominick Grift 2011-09-14 12:53:25 UTC
To be quite frank with you, i have no experience with gitolite since i get the
impression that it does not add any additional functionality and only overhead
( i do not like overhead )

To the point:

I thought Miroslav said that gitolite does not own
/var/lib/gitolite/repositories. If that is true, then what owns it?

If gitolite created /var/lib/gitolite/repositories, then i would probably ask
the gitolite maintainers whether there is a possibility to install that
location, so that it can be labelled properly.

What puzzles me even more is, how come, if this is default behaviour it has not
been dealt with in Fedora already? I am wondering how gitolite in Fedora works
or is supposed to work compared to gitolite shipped with EL6.1

If this is, as you say, default configuration then it is a bug indeed. (in my
view a probably a bug in gitolites default configuration and possibly git
selinux policy)

I would, if possible, indeed move my repositories to /var/lib/git and tell
gitolite to go look for it there, but i would not be surprised if that exposes
other policy issues. ( again i have no experience with gitolite but i did
design much of the git selinux policy shipped with EL6.1, so i feel kind of
responsible in a sense)

Nonetheless, i personally do not feel comfortable with allowing cgit to read
gitosis_var_lib_t, If my memory serves me correct, there was a vulnerability in
cgit not long ago, and i wouldnt want cgit to be able to interact with only
what is strictly needed (git repositories, not gitolite var lib content in
general).

Comment 17 Miroslav Grepl 2011-09-14 13:06:27 UTC
Ewoud, 
what does on your RHEL6

# rpm -qf /var/lib/gitolite/repositories


Maybe a new boolean for this would be a "solution". I get back my comment #3 and I agree with Dominick to not allow it (by default).

I will play with this issue together with Milos more.

Comment 18 Ewoud Kohl van Wijngaarden 2011-09-14 14:05:00 UTC
(In reply to comment #17)
> Ewoud, 
> what does on your RHEL6
> 
> # rpm -qf /var/lib/gitolite/repositories
>
[root@git ~]# rpm -qf /var/lib/gitolite/repositories
file /var/lib/gitolite/repositories is not owned by any package

Typically you install gitolite as the gitolite user with gl-setup. This performs a few steps

1. Copy /usr/share/gitolite/conf/example.gitolite.rc to ~gitolite/.gitolite.rc
2. Call $EDITOR ~gitolite/.gitolite.rc
3. Run the rest of the install

Step 3 will will (amongst other actions) ensure the repository directory exists. The default directory is ~gitolite/repositories, but you can modify this in step 2.

One solution would be to ensure the default is /var/lib/git. That should be fairly simple given step 1. However, it would require the user to ensure /var/lib/git exists with the proper permissions (i.e. writable for the gitolite user). On a VM this works for me.

Comment 19 Miroslav Grepl 2011-09-15 13:57:33 UTC
I will add 

"git_cgit_read_gitolite_content" 

boolean and users can choose if they want to allow cgit to read gitolite content or not.

Comment 20 Ewoud Kohl van Wijngaarden 2011-09-15 14:01:46 UTC
To stay consistent you might want to make it to "git_cgit_read_gitosis_content".

Comment 21 Miroslav Grepl 2011-09-15 14:05:01 UTC
(In reply to comment #20)
> To stay consistent you might want to make it to
> "git_cgit_read_gitosis_content".

Yes, you are right.

Comment 25 errata-xmlrpc 2011-12-06 10:18:32 UTC
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-2011-1511.html


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