New fedora cgit packages could use some policy updates

[Todd Zullinger]

Greetings,

I added a cgit package to Fedora yesterday.  It's only in rawhide at
the moment.  cgit is a cgi used to provide a web interface for viewing
git repositories (similar to gitweb¹).

Is the preferred method to add policy to the selinux-policy package or
are package policy modules the way to go?  I thought the former was
preferred, but I can't find anything on the wiki other than
http://fedoraproject.org/wiki/PackagingDrafts/SELinux, which seems
like it might have been a stalled attempt.

The cgit requirements are fairly minimal, AFAICT.  It needs:

    * write access to its cache dir, /var/cache/cgit
    
    * read access to git repositories, which default to /var/lib/git,
      but are likely to be changed by admins (/srv/git is one popular
      choice).  For the moment, I created a README.SELinux file in the
      package that details how to set generic contexts to allow the
      package to work².

That README suggests httpd_sys_content_rw_t for the cache and
httpd_sys_content_t (or public_content_t) for the git repos.  It's
quite likely that we'd want a more specific type for the cache dir
especially.

Additionally, the cgi itself needs to be httpd_sys_script_exec_t,
which happens automagically by virtue of installing it in
/var/www/cgi-bin/cgit.

Any help or suggestions would be most welcome.  I'd like to get these
things worked out before I build the package for F-9, F-10, and EL-5.
If crafting a policy requires moving anything around, I'd like to do
that before many users install the package and modify their configs.

¹ gitweb has some SELinux issues on F-10 itself, I filed this as
  https://bugzilla.redhat.com/479613 the other day.

² http://cvs.fedoraproject.org/viewvc/rpms/cgit/devel/README.SELinux?view=co

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Well at first I was skeptical but then I thought I could be like
Hillary Clinton, just without the penis.
    -- Lois Griffin, The Family Guy

[Jerry James]

On Wed, Jan 14, 2009 at 9:45 AM, Todd Zullinger <tmz(a)pobox.com&gt; wrote:
>  Is the preferred method to add policy to the selinux-policy package
> or
>  are package policy modules the way to go?  I thought the former was
>  preferred, but I can't find anything on the wiki other than
>  http://fedoraproject.org/wiki/PackagingDrafts/SELinux, which seems
>  like it might have been a stalled attempt. 
That page addresses a question I have with GCL: where should the
policy file be stored?  It suggests /usr/share/selinux/packages.  I
see that BackupPC stores its policy file there.  But that directory is
not owned by any package.  Should it be owned by selinux-policy?
-- 
Jerry James
http://loganjerry.googlepages.com/

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jerry James wrote:
>  On Wed, Jan 14, 2009 at 9:45 AM, Todd Zullinger <tmz(a)pobox.com&gt;
> wrote:
> > Is the preferred method to add policy to the selinux-policy package or
> > are package policy modules the way to go?  I thought the former was
> > preferred, but I can't find anything on the wiki other than
> > http://fedoraproject.org/wiki/PackagingDrafts/SELinux, which seems
> > like it might have been a stalled attempt.
>  
>  That page addresses a question I have with GCL: where should the
>  policy file be stored?  It suggests /usr/share/selinux/packages.  I
>  see that BackupPC stores its policy file there.  But that directory is
>  not owned by any package.  Should it be owned by selinux-policy? 
I will add this to
rawhide selinux-policy package.

Miroslav can you add it to F10 policy package?


> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iEYEARECAAYFAklvh4sACgkQrlYvE4MpobPDHgCcCTVsMnLJqKtSx2oh+TFK2w4w
> Ns4AoOUwP0M/gv1eGlmLli9kLxubeog2
> =JdUa
> -----END PGP SIGNATURE-----

[Miroslav Grepl]

Daniel J Walsh wrote:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>
>  Jerry James wrote:
>    
> > On Wed, Jan 14, 2009 at 9:45 AM, Todd Zullinger <tmz(a)pobox.com&gt; wrote:
> >     
> >> Is the preferred method to add policy to the selinux-policy package or
> >> are package policy modules the way to go?  I thought the former was
> >> preferred, but I can't find anything on the wiki other than
> >> http://fedoraproject.org/wiki/PackagingDrafts/SELinux, which seems
> >> like it might have been a stalled attempt.
> >>       
> > That page addresses a question I have with GCL: where should the
> > policy file be stored?  It suggests /usr/share/selinux/packages.  I
> > see that BackupPC stores its policy file there.  But that directory is
> > not owned by any package.  Should it be owned by selinux-policy?
> >     
>  I will add this to rawhide selinux-policy package.
>
>  Miroslav can you add it to F10 policy package?
>
>
> >  -----BEGIN PGP SIGNATURE-----
> >  Version: GnuPG v1.4.9 (GNU/Linux)
> >  Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> >
> >  iEYEARECAAYFAklvh4sACgkQrlYvE4MpobPDHgCcCTVsMnLJqKtSx2oh+TFK2w4w
> >  Ns4AoOUwP0M/gv1eGlmLli9kLxubeog2
> >  =JdUa
> >  -----END PGP SIGNATURE----- 
>     
I will do it.

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Todd Zullinger wrote:
>  Greetings,
>  
>  I added a cgit package to Fedora yesterday.  It's only in rawhide at
>  the moment.  cgit is a cgi used to provide a web interface for viewing
>  git repositories (similar to gitweb¹).
>  
>  Is the preferred method to add policy to the selinux-policy package or
>  are package policy modules the way to go?  I thought the former was
>  preferred, but I can't find anything on the wiki other than
>  http://fedoraproject.org/wiki/PackagingDrafts/SELinux, which seems
>  like it might have been a stalled attempt.
>  
>  The cgit requirements are fairly minimal, AFAICT.  It needs:
>  
>      * write access to its cache dir, /var/cache/cgit
>      
>      * read access to git repositories, which default to /var/lib/git,
>        but are likely to be changed by admins (/srv/git is one popular
>        choice).  For the moment, I created a README.SELinux file in the
>        package that details how to set generic contexts to allow the
>        package to work².
>  
>  That README suggests httpd_sys_content_rw_t for the cache and
>  httpd_sys_content_t (or public_content_t) for the git repos.  It's
>  quite likely that we'd want a more specific type for the cache dir
>  especially.
>  
>  Additionally, the cgi itself needs to be httpd_sys_script_exec_t,
>  which happens automagically by virtue of installing it in
>  /var/www/cgi-bin/cgit.
>  
>  Any help or suggestions would be most welcome.  I'd like to get these
>  things worked out before I build the package for F-9, F-10, and EL-5.
>  If crafting a policy requires moving anything around, I'd like to do
>  that before many users install the package and modify their configs.
>  
>  ¹ gitweb has some SELinux issues on F-10 itself, I filed this as
>    https://bugzilla.redhat.com/479613 the other day.
>  
>  ² http://cvs.fedoraproject.org/viewvc/rpms/cgit/devel/README.SELinux?view=co
>  
>  
>  
>  ------------------------------------------------------------------------
>  
>  --
>  fedora-selinux-list mailing list
>  fedora-selinux-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list 
What do you think of this simple policy package.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iEYEARECAAYFAklviAgACgkQrlYvE4MpobPlygCgitezimX9aRbvp5pe4rmGCWTS
> 0EIAoN65uLSE7iwUPXf3AKDdGt50t10A
> =vxF5
> -----END PGP SIGNATURE-----

[Todd Zullinger]

Daniel J Walsh wrote:
>  What do you think of this simple policy package. 
That looks nice and simple to start with.  Thanks.

Thinking ahead a bit, would we want to name it git or cgit?  There are
several packages/daemons that should eventually become confined by
stricter policy:

    git-daemon - provides the git:// protocol support
    gitweb - provides a CGI in perl for viewing git repos via http[s]
    cgit - provides a CGI in C for viewing git repos via http[s]

For example, gitweb would have no need to access the cgit cache, but
may have other areas that it needs to write to, which would mean
httpd_git_content_rw_t might need to encompass more than needed if it
includes both gitweb and cgit.

There have been a few recent security bugs with gitweb¹, serious
enough to allow remote code execution.  This is definitely the sort of
thing a nice policy could help mitigate. :)

Do you have some links handy for how I'd go about creating a confined
policy for either cgit or gitweb?  That way I could test and add to
the policy to allow it to be as limited as is reasonable.  I'd be
happy to try and help beat something into shape for these git tools.
But I've really not spent a lot of time reading up on creating policy
from scratch.  I've perused your excellent blog, but not enough to be
able to do this yet.

¹ https://bugzilla.redhat.com/show_bug.cgi?id=477523
  https://bugzilla.redhat.com/show_bug.cgi?id=479715

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A vacuum is a hell of a lot better than some of the stuff that nature
replaces it with.
    -- Tennessee Williams

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Todd Zullinger wrote:
>  Daniel J Walsh wrote:
> > What do you think of this simple policy package.
>  
>  That looks nice and simple to start with.  Thanks.
>  
>  Thinking ahead a bit, would we want to name it git or cgit?  There are
>  several packages/daemons that should eventually become confined by
>  stricter policy:
>  
>      git-daemon - provides the git:// protocol support
>      gitweb - provides a CGI in perl for viewing git repos via http[s]
>      cgit - provides a CGI in C for viewing git repos via http[s]
>  
>  For example, gitweb would have no need to access the cgit cache, but
>  may have other areas that it needs to write to, which would mean
>  httpd_git_content_rw_t might need to encompass more than needed if it
>  includes both gitweb and cgit.
>  
>  There have been a few recent security bugs with gitweb¹, serious
>  enough to allow remote code execution.  This is definitely the sort of
>  thing a nice policy could help mitigate. :)
>  
>  Do you have some links handy for how I'd go about creating a confined
>  policy for either cgit or gitweb?  That way I could test and add to
>  the policy to allow it to be as limited as is reasonable.  I'd be
>  happy to try and help beat something into shape for these git tools.
>  But I've really not spent a lot of time reading up on creating policy
>  from scratch.  I've perused your excellent blog, but not enough to be
>  able to do this yet.
>  
>  ¹ https://bugzilla.redhat.com/show_bug.cgi?id=477523
>    https://bugzilla.redhat.com/show_bug.cgi?id=479715
>  
>   
Sorry about this, I seem to have lost this email.

THe following might help you with writing policy.

http://magazine.redhat.com/2007/08/21/a-step-by-step-guide-to-building-a-...

>      git-daemon - provides the git:// protocol support
>      gitweb - provides a CGI in perl for viewing git repos via http[s]
>      cgit - provides a CGI in C for viewing git repos via http[s]
>  
I would combine gitweb and cgit into the same policy since there is
really very little different between the two, it really does not matter
what you call them, unless one is readonly?

I have added git policy to the base package for rawhide.

selinux-policy-3.6.5-2.fc11

If you could install this policy out with gitweb and cgit, that would be
helpful.

I made the httpd_git_script_t permissive and have added file context for
gitweb as well as cgit.

Extract the tgz file.
execute

make -f /usr/share/selinux/devel/Makefile
semodule -i git.pp
restorecon -R -v /var/cache/cgit /var/www/cgi-bin/cgit
/var/www/git/gitweb.cgi  /var/lib/git

Run git and cgit.

Use

audit2allow -R >> git.te

to add
make -f /usr/share/selinux/devel/Makefile
semodule -i git.ppnew rules

Test again, to make sure there are no avc's.

Then if you send me the new policy and the audit.log, I can update
fedora policy.
>  
>  ------------------------------------------------------------------------
>  
>  --
>  fedora-selinux-list mailing list
>  fedora-selinux-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkmRZsQACgkQrlYvE4MpobMnHgCgzsabAv8/QD7RJS1SX7LQUuG0
> ZsUAoKumZBFJnrrWvl5q3KY4zp/qNgw3
> =WPT7
> -----END PGP SIGNATURE-----

[Todd Zullinger]

Daniel J Walsh wrote:
>  Sorry about this, I seem to have lost this email. 
No worries. :)

>  THe following might help you with writing policy.
>
>
> http://magazine.redhat.com/2007/08/21/a-step-by-step-guide-to-building-a-...
Indeed it will.  Thank you.

>  I would combine gitweb and cgit into the same policy since there is
>  really very little different between the two, it really does not matter
>  what you call them, unless one is readonly? 
Well, only cgit needs write access to /var/cache/cgit.  I don't know
where, or if, gitweb writes any temp files.  If it does, I don't see
the policy you attached denying them.

>  I have added git policy to the base package for rawhide.
>
>  selinux-policy-3.6.5-2.fc11
>
>  If you could install this policy out with gitweb and cgit, that would be
>  helpful.
>
>  I made the httpd_git_script_t permissive and have added file context for
>  gitweb as well as cgit. 
Is there a corresponding strict mode?  For this:

permissive httpd_git_script_t;

If so, I could test it that way and maybe tighten up the policy
further.

>  Extract the tgz file.
>  execute
>
>  make -f /usr/share/selinux/devel/Makefile
>  semodule -i git.pp
>  restorecon -R -v /var/cache/cgit /var/www/cgi-bin/cgit
>  /var/www/git/gitweb.cgi  /var/lib/git
>
>  Run git and cgit.
>
>  Use
>
>  audit2allow -R>> git.te
>
>  to add
>  make -f /usr/share/selinux/devel/Makefile
>  semodule -i git.ppnew rules
>
>  Test again, to make sure there are no avc's.
>
>  Then if you send me the new policy and the audit.log, I can update
>  fedora policy. 
Done.  There weren't many additional AVCs in my testing (which I'm
sure could miss some odd use case that someone else will find).
Attached is an updated git.te and the raw audit messages (broken down
by which tool caused the AVC).

Is the search on var_lib_t something that we would want to limit?  I
don't think cgit, git-daemon, or gitweb should need more than
/var/lib/git (and /var/cache/cgit in cgit's case).  It _seemed_ that
they ran fine even when this was denied, but perhaps I just didn't
notice some subtle breakage.

Thanks for all the help.

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
He may look like an idiot and talk like an idiot but don't let that
fool you. He really is an idiot.
    -- Groucho Marx

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Todd Zullinger wrote:
>  Daniel J Walsh wrote:
> > Sorry about this, I seem to have lost this email.
>  
>  No worries. :)
>  
> > THe following might help you with writing policy.
> >
> >
> http://magazine.redhat.com/2007/08/21/a-step-by-step-guide-to-building-a-...
>  
>  Indeed it will.  Thank you.
>  
> > I would combine gitweb and cgit into the same policy since there is
> > really very little different between the two, it really does not matter
> > what you call them, unless one is readonly?
>  
>  Well, only cgit needs write access to /var/cache/cgit.  I don't know
>  where, or if, gitweb writes any temp files.  If it does, I don't see
>  the policy you attached denying them. 
>  
> > I have added git policy to the base package for rawhide.
> >
> > selinux-policy-3.6.5-2.fc11
> >
> > If you could install this policy out with gitweb and cgit, that would be
> > helpful.
> >
> > I made the httpd_git_script_t permissive and have added file context for
> > gitweb as well as cgit.
>  
>  Is there a corresponding strict mode?  For this:
>  
>  permissive httpd_git_script_t;
>   
Removing the line makes it strict.
>  If so, I could test it that way and maybe tighten up the policy
>  further.
>  
> > Extract the tgz file.
> > execute
> >
> > make -f /usr/share/selinux/devel/Makefile
> > semodule -i git.pp
> > restorecon -R -v /var/cache/cgit /var/www/cgi-bin/cgit
> > /var/www/git/gitweb.cgi  /var/lib/git
> >
> > Run git and cgit.
> >
> > Use
> >
> > audit2allow -R>> git.te
> >
> > to add
> > make -f /usr/share/selinux/devel/Makefile
> > semodule -i git.ppnew rules
> >
> > Test again, to make sure there are no avc's.
> >
> > Then if you send me the new policy and the audit.log, I can update
> > fedora policy.
>  
>  Done.  There weren't many additional AVCs in my testing (which I'm
>  sure could miss some odd use case that someone else will find).
>  Attached is an updated git.te and the raw audit messages (broken down
>  by which tool caused the AVC).
>  
>  Is the search on var_lib_t something that we would want to limit?   
no
I
>  don't think cgit, git-daemon, or gitweb should need more than
>  /var/lib/git (and /var/cache/cgit in cgit's case).  It _seemed_ that
>  they ran fine even when this was denied, but perhaps I just didn't
>  notice some subtle breakage.
>  
>  Thanks for all the help.
>  
>   
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkma+C4ACgkQrlYvE4MpobM+xQCePczBb4m5srneZ7EIUsxP0pGI
> v3QAoLWFUgz5JuuUgHJFOXdXlXHhQ9n0
> =D4SA
> -----END PGP SIGNATURE-----