From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Tue, 30 Aug 2011 09:37:17 -0400
Subject: [refpolicy] [ v3 PATCH 2/8] Git personal repositories
In-Reply-To: <20110826133000.GA2140@localhost.localdomain>
References: <1314189346-10866-1-git-send-email-domg472@gmail.com>
	<1314189346-10866-3-git-send-email-domg472@gmail.com>
	<4E579D29.3060607@tresys.com>
	<20110826133000.GA2140@localhost.localdomain>
Message-ID: <4E5CE78D.2030103@tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On 08/26/11 09:30, Dominick Grift wrote:
> On Fri, Aug 26, 2011 at 09:18:33AM -0400, Christopher J. PeBenito wrote:
>> On 08/24/11 08:35, Dominick Grift wrote:
>>> Git inetd service domain can also be configured to read and serve Git personal repositories in the user home directories.
>>> We would not want Git inetd service domain to be able to read and serve generic or heavens forbid all
>>> user home content, and therefore a new type for Git personal repositories is declared.
>>>
>>> By default Git inetd service domain expects these personal repositories to be in dgrift/public_git.
>>> It is kind of like apaches userdirs functionality. Git inetd service domain, does not have to be configured to
>>> read and serve personal repositories, and so we make the policy for this functionality tunable.
>>>
>>> We also allow administrators to tune the policy to allow Git inetd service domain to read and serve personal
>>> repositories on NFS and/or CIFS shares. We added a file context that specifies that public_git
>>> directories in any user home directory should be labeled with the personal repository file type.
>>> That means that all login users should be allowed to relabel and manage the git_user_content_t personal
>>> repository type. Did you know that users might also need to execute some of the Git personal
>>> repository content. It is not obvious but in some cases users need to be able to execute the Git
>>> hooks scripts in their personal repositories. For example the might have a script that runs after the user
>>> commits/pushes for example via ssh (git push ssh://joe at localhost/public_git/joes_personal_repository.git. So we
>>> also allow all login users to execute Git shared repository files.

>>> diff --git a/policy/modules/system/userdomain.if b/policy/modules/system/userdomain.if
>>> index c6d3cc8..2dc8697 100644
>>> --- a/policy/modules/system/userdomain.if
>>> +++ b/policy/modules/system/userdomain.if
>>> @@ -188,6 +188,10 @@ interface(`userdom_ro_home_role',`
>>>  		fs_dontaudit_list_cifs($2)
>>>  		fs_dontaudit_read_cifs_files($2)
>>>  	')
>>> +
>>> +	optional_policy(`
>>> +		git_read_user_content($2)
>>> +	')
>>>  ')
>>>  
>>>  #######################################
>>> @@ -267,6 +271,11 @@ interface(`userdom_manage_home_role',`
>>>  		fs_dontaudit_manage_cifs_dirs($2)
>>>  		fs_dontaudit_manage_cifs_files($2)
>>>  	')
>>> +
>>> +	optional_policy(`
>>> +		git_manage_user_content($2)
>>> +		git_relabel_user_content($2)
>>> +	')
>>>  ')
>>>  
>>>  #######################################
>>> @@ -789,6 +798,10 @@ template(`userdom_login_user_template', `
>>>  	')
>>>  
>>>  	optional_policy(`
>>> +		git_exec_user_content_files($1_t)
>>> +	')
>>> +
>>> +	optional_policy(`
>>>  		kerberos_use($1_t)
>>>  	')
>>
>> All of these content rules seem like it should be in a git_role()
>> interface, which would be invoked from the various role.te files.
> 
> Why do you think that?
> 
> i will explain why i think not:
> 
> 1. the file context spec. labels all ~/pubic_git type git_user_content_t, whether the user calls git_role_template or not.
> 2. sysadm can decide to allow git system daemon to host personal repositories of users that arent allowed to run the git session daemon in the git session domain.

For the first two, they absolutely do not belong there.  Those interfaces are
providing general user home directory access.  For the last, it makes more sense
for that access to go with the other git rules for users.  If you're saying that
users should have git content types w/o any other git policy, I'd say thats
overengineered.  MCS would seem more appropriate in that case.

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