Gitweb and SELinux

[Michael Cronenworth]

I am attempting to use gitweb to display git repos that live in /home 
directories. The developers use ssh to push changes to their home 
directory. It seems every Fedora release gitweb and SELinux have 
changes. With Fedora 12, I cannot get SELinux to be happy about 
accessing the git repos.

Gitweb is pointing to:
/srv/git/
Inside of that directory live symlinks to the git repos that live in
/home/user1/git
/home/user2/git
etc.

I've attached the sealert output about the denial. I tried to assign a 
context of httpd_git_content_ra_t to my git repo, but that did not allow 
access. I realize this may not be "100%" secure, but this setup was 
functioning in Fedoras 11 and under. I'd create a bug, but I'm not sure 
if this setup would be considered a bug of SELinux.

Additional info:
$ ls -Z /var/www/git/
-rw-r--r--. root root system_u:object_r:httpd_git_content_t:s0 
git-favicon.png
-rw-r--r--. root root system_u:object_r:httpd_git_content_t:s0 git-logo.png
-rwxr-xr-x. root root system_u:object_r:httpd_git_script_exec_t:s0 
gitweb.cgi
-rw-r--r--. root root system_u:object_r:httpd_git_content_t:s0 
gitweb_config.perl
-rw-r--r--. root root system_u:object_r:httpd_git_content_t:s0 gitweb.css

Any ideas to allow access?

Thanks,
Michael

[Dominick Grift]

On 02/05/2010 04:53 PM, Michael Cronenworth wrote:
> I am attempting to use gitweb to display git repos that live in /home
> directories. The developers use ssh to push changes to their home
> directory. It seems every Fedora release gitweb and SELinux have
> changes. With Fedora 12, I cannot get SELinux to be happy about
> accessing the git repos.
>
> Gitweb is pointing to:
> /srv/git/
> Inside of that directory live symlinks to the git repos that live in
> /home/user1/git
> /home/user2/git
> etc.
>
> I've attached the sealert output about the denial. I tried to assign a
> context of httpd_git_content_ra_t to my git repo, but that did not allow
> access. I realize this may not be "100%" secure, but this setup was
> functioning in Fedoras 11 and under. I'd create a bug, but I'm not sure
> if this setup would be considered a bug of SELinux.

Not really a bug but this access could be added. Although a revisited
git policy is in rawhide (i do not know if it will also be pushed to f12)

You can use audit2allow to permit this access. or manually write a module:

cat mygitweb.te

policy_module(mygitweb, 1.0.0)
optional_policy(`
gen_require(`
type git_data_t, httpd_git_script_t;
')

read_lnk_files_pattern(httpd_git_script_t, git_data_t, git_data_t)
read_files_pattern(httpd_git_script_t, git_data_t, git_data_t)
read_dirs_pattern(httpd_git_script_t, git_data_t, git_data_t)
')

(build the module)

make -f /usr/share/selinux/devel/Makefile mygitweb.pp

(install the module)

sudo semodule -i mygitweb.pp
> Additional info:
> $ ls -Z /var/www/git/
> -rw-r--r--. root root system_u:object_r:httpd_git_content_t:s0
> git-favicon.png
> -rw-r--r--. root root system_u:object_r:httpd_git_content_t:s0 git-logo.png
> -rwxr-xr-x. root root system_u:object_r:httpd_git_script_exec_t:s0
> gitweb.cgi
> -rw-r--r--. root root system_u:object_r:httpd_git_content_t:s0
> gitweb_config.perl
> -rw-r--r--. root root system_u:object_r:httpd_git_content_t:s0 gitweb.css
>
> Any ideas to allow access?
>
> Thanks,
> Michael
>
> --
> selinux mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/selinux

[Michael Cronenworth]

Dominick Grift wrote:
> (build the module)
>
> make -f /usr/share/selinux/devel/Makefile mygitweb.pp

$ make -f /usr/share/selinux/devel/Makefile mygitweb.pp
Compiling targeted mygitweb module
/usr/bin/checkmodule:  loading policy configuration from tmp/mygitweb.tmp
mygitweb.te":2:ERROR 'syntax error' at token 'read_dirs_pattern' on line 
3241:
#line 2
read_dirs_pattern(httpd_git_script_t, git_data_t, git_data_t)
/usr/bin/checkmodule:  error(s) encountered while parsing configuration
make: *** [tmp/mygitweb.mod] Error 1

I don't see anything wrong with your module, but I'm far from an SELinux 
expert.

[Dominick Grift]

On 02/05/2010 05:21 PM, Michael Cronenworth wrote:
> Dominick Grift wrote:
> > (build the module)
> >
> > make -f /usr/share/selinux/devel/Makefile mygitweb.pp
>
> $ make -f /usr/share/selinux/devel/Makefile mygitweb.pp
> Compiling targeted mygitweb module
> /usr/bin/checkmodule:  loading policy configuration from tmp/mygitweb.tmp
> mygitweb.te":2:ERROR 'syntax error' at token 'read_dirs_pattern' on line 
> 3241:
> #line 2
> read_dirs_pattern(httpd_git_script_t, git_data_t, git_data_t)
> /usr/bin/checkmodule:  error(s) encountered while parsing configuration
> make: *** [tmp/mygitweb.mod] Error 1
>
> I don't see anything wrong with your module, but I'm far from an SELinux

replace read_dirs_pattern by list_dirs_pattern

than try again

see if that works
> expert.
>
> selinux mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/selinux

[Michael Cronenworth]

Dominick Grift wrote:
> replace read_dirs_pattern by list_dirs_pattern
>
> than try again
>
> see if that works

Thanks, that works.

I also had to set my /home/michael directory to git_data_t to allow access.

[Dominick Grift]

On 02/05/2010 05:39 PM, Michael Cronenworth wrote:
> Dominick Grift wrote:
> > replace read_dirs_pattern by list_dirs_pattern
> >
> > than try again
> >
> > see if that works
>
> Thanks, that works.
>
> I also had to set my /home/michael directory to git_data_t to allow access.

There is probably a better way to configure this. The problem is that
git-daemon is currently a bit messy.

Could you post your /etc/xinetd.d/git?
> --
> selinux mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/selinux

[Michael Cronenworth]

Dominick Grift wrote:
> There is probably a better way to configure this. The problem is that
> git-daemon is currently a bit messy.

I'd hope so, as now I cannot get access to my own home directory with 
that git context set.
> Could you post your /etc/xinetd.d/git?

I'm not using git-daemon for file access on this particular machine. 
Just SSH. On a Fedora 11 git server, that is using the same directory 
setup, I'm using the following:

$ cat /etc/xinetd.d/git
# default: off
# description: The git dæmon allows git repositories to be exported using \
#	the git:// protocol.

service git
{
         disable		= no
         socket_type     = stream
         wait            = no
         user            = nobody
         server          = /usr/bin/git
         server_args     = daemon --base-path=/srv/git --export-all 
--user-path=public_git --syslog --inetd --verbose
         log_on_failure  += USERID
# xinetd doesn't do this by default. bug #195265
         flags		= IPv6
}

[Dominick Grift]

On 02/05/2010 05:51 PM, Michael Cronenworth wrote:
> Dominick Grift wrote:
> > There is probably a better way to configure this. The problem is that
> > git-daemon is currently a bit messy.
>
> I'd hope so, as now I cannot get access to my own home directory with 
> that git context set.
> > Could you post your /etc/xinetd.d/git?
>
> I'm not using git-daemon for file access on this particular machine. 
> Just SSH. On a Fedora 11 git server, that is using the same directory 
> setup, I'm using the following:

Alright well by default personal git repositories are expected in
~/public_git.

That directory and its content is labelled git_personal_t in F12 (if i
am correct).

I would probably use that for personal git repositories and give your
gitweb app access to git_personal_t instead of git_data_t (which is a
type for system wide shared git repositories in /var/lib/git)

Can gitweb not be configured to point to the different personal
repositories? Instead of using symlinks in /srv/git?
> $ cat /etc/xinetd.d/git
> # default: off
> # description: The git dæmon allows git repositories to be exported using \
> #	the git:// protocol.
>
> service git
> {
>          disable		= no
>          socket_type     = stream
>          wait            = no
>          user            = nobody
>          server          = /usr/bin/git
>          server_args     = daemon --base-path=/srv/git --export-all 
> --user-path=public_git --syslog --inetd --verbose
>          log_on_failure  += USERID
> # xinetd doesn't do this by default. bug #195265
>          flags		= IPv6
> }
> --
> selinux mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/selinux

[Michael Cronenworth]

Dominick Grift wrote:
> Alright well by default personal git repositories are expected in
> ~/public_git.
>
> That directory and its content is labelled git_personal_t in F12 (if i
> am correct).
>
> I would probably use that for personal git repositories and give your
> gitweb app access to git_personal_t instead of git_data_t (which is a
> type for system wide shared git repositories in /var/lib/git)

Done. The default context seems to be 
unconfined_u:object_r:httpd_user_content_t:s0, which makes more sense, 
but SELinux still complains about allowing access to my root home 
directory (/home/michael) when I reset that back to default. I have the 
boolean enabled to allow httpd access to home and user directories.
> Can gitweb not be configured to point to the different personal
> repositories? Instead of using symlinks in /srv/git?

Not that I know of, but I may be missing something. The 
gitweb_config.perl file only allows one $projectroot.

Any more good ideas? :D

[Dominick Grift]

On 02/05/2010 06:16 PM, Michael Cronenworth wrote:
> Dominick Grift wrote:
> > Alright well by default personal git repositories are expected in
> > ~/public_git.
> >
> > That directory and its content is labelled git_personal_t in F12 (if i
> > am correct).
> >
> > I would probably use that for personal git repositories and give your
> > gitweb app access to git_personal_t instead of git_data_t (which is a
> > type for system wide shared git repositories in /var/lib/git)
>
> Done. The default context seems to be 
> unconfined_u:object_r:httpd_user_content_t:s0, which makes more sense,

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)
> but SELinux still complains about allowing access to my root home 
> directory (/home/michael) when I reset that back to default. I have the

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.
> boolean enabled to allow httpd access to home and user directories.
> > Can gitweb not be configured to point to the different personal
> > repositories? Instead of using symlinks in /srv/git?
>
> Not that I know of, but I may be missing something. The 
> gitweb_config.perl file only allows one $projectroot.
>
> Any more good ideas? :D

I have plenty ideas but i dont know if they are any good. if it works,
it works
> --
> selinux mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/selinux

[Daniel J Walsh]

On 02/05/2010 12:30 PM, Dominick Grift wrote:
> On 02/05/2010 06:16 PM, Michael Cronenworth wrote:
> > Dominick Grift wrote:
> > > Alright well by default personal git repositories are expected in
> > > ~/public_git.
> > >
> > > That directory and its content is labelled git_personal_t in F12 (if i
> > > am correct).
> > >
> > > I would probably use that for personal git repositories and give your
> > > gitweb app access to git_personal_t instead of git_data_t (which is a
> > > type for system wide shared git repositories in /var/lib/git)
> >
> > Done. The default context seems to be 
> > unconfined_u:object_r:httpd_user_content_t:s0, which makes more sense,
>
> 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)
> > but SELinux still complains about allowing access to my root home 
> > directory (/home/michael) when I reset that back to default. I have the
>
> 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.

You want to allow apache cgi scripts to search home_root_t, user_home_dir_t, and user_home_t only.
No list no read.
> > boolean enabled to allow httpd access to home and user directories.
> > > Can gitweb not be configured to point to the different personal
> > > repositories? Instead of using symlinks in /srv/git?
> >
> > Not that I know of, but I may be missing something. The 
> > gitweb_config.perl file only allows one $projectroot.
> >
> > Any more good ideas? :D
>
> I have plenty ideas but i dont know if they are any good. if it works,
> it works
> > --
> > selinux mailing list
> > [e-mail]
> > https://admin.fedoraproject.org/mailman/listinfo/selinux
>
> --
> selinux mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/selinux

[Michael Cronenworth]

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.
> 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.

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?

[Dominick Grift]

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
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/selinux