Yes when i designed policy i did not take this into consideration (httpd_t reading system repositories) Mainly because cgit and gitweb are common used webapps used for this and those two webapps run in their own cgi-domains, which in turn are allowed access to read all git repositories (system and session)

Can you not transition whatever webapp you are using to a cgi-domain instead of running it in the httpd_t domain?

I guess that if your configuration is "legitimate", that we (and or you) could allow httpd_t access to read system and/or personal repositories (preferably by implementing a boolean because i would not want to allow httpd_t access by default)

Would look something like this:

policy_module(myhttpd, 1.0.0)

gen_require(`
    type httpd_t;
')

## <desc>
##	<p>
##	Allow httpd to read all Git repositories.
##	</p>
## </desc>
gen_tunable(httpd_can_read_git_repositories, false)

tunable_policy(`httpd_can_read_git_repositories',`
	git_read_all_content_files(httpd_t)
')

... problem is that this breaks httpd_enable_userdirs boolean since git_read_all_content_files allows the caller to search user home directories to get to personal repositories in ~/public_git, so that would need some tweaking i guess.

Maybe a boolean is not needed at all since httpd can also be used for dumb git repository hosting and httpd reading git content does not do any harm.

in that case a simple:

policy_module(myhttpd, 1.0.0)

gen_require(`
 type httpd_t;
 attribute git_content;
')

read_files_pattern(httpd_t, git_content, git_content)

...should suffice.

dwalsh:

I guess we should allow httpd_t unconditionally access to git_content, if only for dumb git repository hosting.

We would need to implement a separate git_read_all_git_content interface though because the one we currently use allows the caller to search var_t, home_root_t and user_home_dir_t.

We do not want that for httpd_t, since that would break httpd_enable_homedirs functionality.

read_files_pattern($1, git_content, git_content)

(In reply to comment #1)
> Yes when i designed policy i did not take this into consideration (httpd_t
> reading system repositories) Mainly because cgit and gitweb are common used
> webapps used for this and those two webapps run in their own cgi-domains, which
> in turn are allowed access to read all git repositories (system and session)
> 
> Can you not transition whatever webapp you are using to a cgi-domain instead of
> running it in the httpd_t domain?
> 
> I guess that if your configuration is "legitimate", that we (and or you) could
> allow httpd_t access to read system and/or personal repositories (preferably by
> implementing a boolean because i would not want to allow httpd_t access by
> default)

Since Trac and mod_python don't work in F14 (Python-2.7), I switched to mod_wsgi.

How might I enable a different context for those *.wsgi files to allow them to "transition"?

You could test to see if it works for wsgi at all by labelling the webapp executable files httpd_sys_script_exec_t, then httpd_t domain transitions to the httpd_sys_script_t domain if possible.

Then you would see avc denials like the ones you enclosed above but instead of httpd_t, httpd_sys_script_t would be denied access. 

That would tell us that the webapp can be (further) confined.

But regardless, we should allow httpd_t access to read git content for dumb git content hosting (git clone http://domain.tld/git/myrepo.git)

I did not implement it because for me its overkill but i guess we should allow it because others might not agree with me.

I don't see any change after changing the *.wsgi files to httpd_sys_script_exec_t.  I am using httpd_unified, so I am not sure if that will make a difference.

Also of note, I am not serving git content via httpd, only via the git-daemon (git_system_content_t is the default type for /var/lib/git).  I just want Trac (trac.edgewall.org) to display things from the /var/lib/git repositories.

Something like:

allow_httpd_git_system_content_r_t (or if there is a better way, I'm good with that too.

I can also move the content to somewhere else under httpd_git_content_t, but then git-daemon can't read it.

I've considered gitosis or gitlite, but those are a bit complicated for my needs at this time.

I know Fedora uses Trac as well.  How is this accomplished there?

FYI, here are the contents of one of the *.wsgi files (Python):

import os
os.environ['PYTHON_EGG_CACHE'] = '/tmp'
import trac.web.main
def application(environ, start_response):
  environ['trac.env_path'] = '/var/www/trac' 
  return trac.web.main.dispatch_request(environ, start_response)

For reference:
http://trac.edgewall.org/wiki/TracModWSGI
http://trac-hacks.org/wiki/GitPlugin

If you gentlemen have a "better way" to set up the system, I am open to suggestions.  I try as much as possible to use programs provided by Fedora, like git-daemon, httpd, Trac, etc.

I certainly don't need you to create changes in SELinux if there is a better, or more recommended solution.

I have looked into gitolite a bit more, but it still seems much more than I need and doesn't provide any support for Kerberos/sshd.

Right now, my git repos are viewable using Trac/httpd, but accessible by git-daemon for cloning and by sshd/Kerberos for writing.


Thanks again.

Allowing httpd to read git content (at least system content) is something that should be done anyways,

I am not sure how Fedora infrastructure dealt with this in their environment.

It may be that httpd_uunified prevented httpd from transitioning to the httpd system script domain or it may be that .wsgi can not be used to domain transition (like .php), i am not sure,

Again, we should probably allow httpd to read git content anyway, i do not see any harm there.

I am a minimalist and in my own environment i only use git-daemon for both fetching and pushing. This preference has influenced the policy that is in Fedora today.

By the way, as far as i knoe Fedora uses gitweb:

http://git.fedorahosted.org/git/?p=selinux-policy.git;a=summary

Which should work fine without the need to modify anything.

I'm not sure what the Fedora proposed solution is, but I have the following working well for now:

module fixhttpdgitcontent 1.0;

require {
        type httpd_t;
        type git_system_content_t;
        class dir { read search open getattr };
        class file { read getattr open };
}

#============= httpd_t ==============
allow httpd_t git_system_content_t:dir { read search open getattr };
allow httpd_t git_system_content_t:file { read getattr open };

Miroslav, lets add these rules.

Fixed in selinux-policy-3.9.7-14.fc14

selinux-policy-3.9.7-14.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/selinux-policy-3.9.7-14.fc14

selinux-policy-3.9.7-14.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update selinux-policy'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/selinux-policy-3.9.7-14.fc14

selinux-policy-3.9.7-14.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.