[refpolicy] [ v3 PATCH 2/8] Git personal repositories

[domg472@gmail.com (Dominick Grift)]

On Tue, Aug 30, 2011 at 09:37:17AM -0400, Christopher J. PeBenito wrote:
> 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.

I can't say that i agree, since apache also have httpd user content types without a httpd session domain, but ok

I can rebase my patch set with the requested changes as soon as we have figured out a way to deal with git_shell user domains and custom shared repository types, see my latest RFC email about that.

We could also do it the easy way and not support Type enforcement shared repository isolation and not support user domain tailored to git shell users.

Instead opt to just settle for using guest_t for git shell and using mcs to limit what guest_t domain can access what git shared repository.

Not my prefered solution but it would make the policy much simpler ( yet harder for admins to grasp )

> 
> -- 
> Chris PeBenito
> Tresys Technology, LLC
> www.tresys.com | oss.tresys.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110830/d18e20b7/attachment.bin