From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Wed, 31 Aug 2011 10:36:58 -0400
Subject: [refpolicy] [ v3 PATCH 4/8] Git session daemon
In-Reply-To: <20110830172016.GC6861@localhost.localdomain>
References: <1314189346-10866-1-git-send-email-domg472@gmail.com>
	<1314189346-10866-5-git-send-email-domg472@gmail.com>
	<4E57A0C2.7010407@tresys.com>
	<20110826153009.GA8869@localhost.localdomain>
	<4E5CEAB8.2010802@tresys.com>
	<20110830172016.GC6861@localhost.localdomain>
Message-ID: <4E5E470A.5010609@tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On 08/30/11 13:20, Dominick Grift wrote:
> On Tue, Aug 30, 2011 at 09:50:48AM -0400, Christopher J. PeBenito wrote:
>> On 08/26/11 11:30, Dominick Grift wrote:
>>> On Fri, Aug 26, 2011 at 09:33:54AM -0400, Christopher J. PeBenito wrote:
>>>> On 08/24/11 08:35, Dominick Grift wrote:
>>>>> Wait! Theres more. Besides running Git daemon as a inetd service domain, unprivileged users can also
>>>>> run Git daemon by executing /usr/libexec/git-core/git-daemon from a shell to allow it to
>>>>> read and serve their Git personal repositories in ~/public_git. It in large parts does the same
>>>>> as Git daemon run by inetd but there are some differences. Most notably is the network access
>>>>> that the Git session daemon requires to listen on the Git port for service.
>>>>>
>>>>> The Git system daemon does not need this because inetd takes care of the network for it.
>>>>> Another difference is that Git session daemon can only read and serve users Git personal
>>>>> repositories, where Git system daemon can, if configured, read and serve both shared as well
>>>>> as personal repositories. Since much of the policy is common to both session and
>>>>> system, we declared a git_daemon attribute and assigned that to both the Git system and
>>>>> session daemons. This allows use to write policy that both daemon have in common once.
>>>>> Leaving the policy as compact as possible. So now we have two Git daemon domains, one
>>>>> session domain started by unprivileged users and one system domain started by inetd.
>>>>>
>>>>> Fix: since we renamed gitd_t to git_system_t, add alias.
>>>>> Change back gitd_use_nfs, gitd_use_cifs to git_system_use_nfs and git_system_use_cifs respectively
>>>>
>>>> Perhaps I missed something, but how did it make sense to separate out
>>>> the content types from this patch?
>>>
>>> The git_user_content_t has no relation to git session per se. 
>>>
>>> in the git.fc file there is a context spec for HOME_DIR/\public_git(/.*)? ...
>>> this means all login users will get content at ~/public_git labeled git_user_content_t, whether they call git_session_role_template or not.
>>> So they need to be able to manage that. what if a user creates ~/pubic_git, and administrator runs filefiles relabel or restorecon -R -v /home? then ~/public_git will get relabeled to git_user_content_t and that user can no longer interact with it.
>>>
>>> By splitting the git_user_content_t type from the git session t policy we make it more flexible.
>>>
>>> administrator may want to allow git system domain to read and service ~/public_git even though the user owning it is not allowed to run git session in the git session domain.
>>>
>>> in short git_user_content_t and git_session_t arent strictly related. I was hoping the descriptions accompanying the patches would make that clear
>>
>> NAK.  See my other email about this.  To summarize, I think its overengineered
>> to have the content w/o session.
> 
> Really? apache module has httpd_user_content_t with out a user session (yes you can run httpd_t as a session daemon)

This gets into a slippery slope.  You can pretty much argue that just about a user could run just about any service out of their home directory.  Its infeasible to constrain all services like this, especially in a general way.  This makes me think that the session git might not be necessary.

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