From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Wed, 31 Aug 2011 10:48:20 -0400
Subject: [refpolicy] [ v3 PATCH 5/8] Gitweb,
 cgit and the git_content attribute
In-Reply-To: <20110830171530.GB6861@localhost.localdomain>
References: <1314189346-10866-1-git-send-email-domg472@gmail.com>
	<1314189346-10866-6-git-send-email-domg472@gmail.com>
	<4E57A131.3070703@tresys.com>
	<20110826161402.GE8869@localhost.localdomain>
	<4E5CE467.10902@tresys.com>
	<20110830171530.GB6861@localhost.localdomain>
Message-ID: <4E5E49B4.5010009@tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On 08/30/11 13:15, Dominick Grift wrote:
> On Tue, Aug 30, 2011 at 09:23:51AM -0400, Christopher J. PeBenito wrote:
>> On 08/26/11 12:14, Dominick Grift wrote:
>>> On Fri, Aug 26, 2011 at 09:35:45AM -0400, Christopher J. PeBenito wrote:
>>>> On 08/24/11 08:35, Dominick Grift wrote:
>>>>> Cgit and gitweb are both cgi web applications that run in the httpd_git_script_t apache CGI domain.
>>>>> The policy in this commit was taken from Fedora. It is well tested i believe.
>>>>> These web applications display Git repositories. And they Should be able to read any Git
>>>>> repository whether shared or personal. We implemented another attribute for it called git_content.
>>>>
>>>> Really all repos?  It seems like access to user repos should be tunable.
>>>
>>> I guess it could be tunable but is it really worth that? i mean these git webapps are made to read git content. thats their sole purpose. We could
>>> +implement a tunable for access to git_user_content_t but it seems a bit overdone.
>>
>> I understand what you're saying, I'm just thinking that there could be a server
>> that has several "system" repos, but have personal user dev repos that shouldn't
>> be exported.
> 
> Ok if you want it that way i can do that to. I can't say i agree. I would call this over engineering. You can configure git to specify which repositories to export and we also have good old dac.

I might agree that it was overengineering except that system and user repos have different trust and integrity levels, otherwise they'd be the same type.  So if you don't trust your users, you might want to enforce that the system daemon can't touch user repos nor risk mixing of system and user repos.  Alternatively, you could argue that user repos are more sensitive than system repos, and you might not want to allow them to be exported.

>>> But if you want it tunable it will be my please to submit a follow up patch to fix this or a replacement.
>>>
>>> By the way i already mentioned this but this httpd cgi domains should be in httpd.te. because it makes for example the git module dependent on the
>>> +apache module whilst, git can work fine without httpd.
>>
>> You could put that all in an optional.
> 
> You cannot make a file context specification optional.
> 
> if you make an apache content template call optional, for example:
> 
> optional_policy(`
> apache_content_template(git)
> ')
> 
> /var/www/cgi-bin/git\.pl -- gen_context(system_u:object_r:httpd_git_script_exec_t,s0)
> 
> Than it is effectively not optional, because if you decide to disable or de-install the apache module, then the git module will blow up due to the type used in the file context file specification (httpd_git_script_exec_t)
> 
> it should be in the apache module instead.

A valid point.  I guess you have to make it unconditional.  Or move it into a separate module.  I can live with that.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com