[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fedora-selinux-list
Subject:    Re: Gitweb and SELinux
From:       Dominick Grift <domg472 () gmail ! com>
Date:       2010-02-10 17:33:33
Message-ID: 4B72EDED.1090303 () gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On 02/10/2010 06:04 PM, Michael Cronenworth wrote:
> Dominick Grift wrote:
>> No this does not make sense at all httpd has zero relation to git
>> content in user home. It looks like your policy has not be modified yet
>> to relect something sane for public_git (although in your case it
>> happens to work out well since your gitweb script has access to it)
> 
> I believe you mean that you want all git repos to have a context of 
> git_data_t (or similar) to finely tune git access, correct? I'm happy 
> enough allowing httpd access to my git repo only and using SSH access 
> for git repos, so for right now allowing httpd/perl with httpd contexts 
> are OK with me. I can see the need to strictly allow only git-daemon a 
> context of git_data_t, but there needs to be more fine tuning of the 
> policy to allow git_script_exec_t type contexts to access ~/public_git 
> directories.

Yes we could add a patch to allow gitwebapp access to personal and share
repositories.

But most important is that those repositories are properly labelled. If
that is true than one can simply use audit2allow to permit the access.

>> This is a bug in my view.
>>
>> httpd_enable_homedirs boolean should probably be modified to reflect this.
>>
>> i.e. if httpd enable homedirs boolean is set to true , then all httpd
>> domains should be able to access it.
>>
>>
> 
> Yes, it appears to be a bug. I had to use httpd_sys_content_t on my 
> /srv/git links and assign httpd_sys_script_exec_t to gitweb.cgi. Now I 
> have a working git web, working SSH git access, and SELinux is still 
> enabled.

Well webapplication that run in their own domain also need to be able to
search user home directories to find (http) user content ( like personal
git repositories, or personal web pages etc )

But again, if the files are labelled properly than audit2allow can be
used to permit this access easily. (but still we should find a more
elegant way)

> I don't know what to write up in a bug report though. Are ~/public_git 
> and /var/lib/git the only two known and respectable places that should 
> contain git repos?

/var/lib/git is the default shared repository location ( this is defined
in /etc/xinetd.d/git) and ~/public_git is the default personal
repository location. (also defined in /etc/xinetd.d/git)

I think from a SELinux perspective /srv/git can also be used (SELinux
has a file context specification stating that /srv/git is a git shared
repository root.

With regard to ~/public_git it is a bit more complicated. In theory any
directory in ~ can be defined a git personal repository root. This since
users have permission to change contexts (chcon) from and to
git_user_content_t.

However in a GUI environment we have restorecond -u running, and it will
reset any contexts changed using chcon that are not defined system wide.
This is why i also would like to see the type for git personal
repositories to be a customizable type. That way restorecond -u does not
try to change it.

But to be honest, currently there are more pressing issues.

For a users to use a custom location for personal git repositories he
would have to run git_daemon as a unpriv user. Fedora currently does not
have SELinux policy enabled for git daemon user sessions.

Git daemon system sessions are managed by root, and root has all
permission required to define a system wide file context specification
for git personal repositories. Which are not reset by restorecond -u.


> --
> selinux mailing list
> selinux@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/selinux



["signature.asc" (application/pgp-signature)]

--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux

[prev in list] [next in list] [prev in thread] [next in thread]