[refpolicy] [ v3 PATCH 6/8] Git shared repository separation and custom shared repository types

[domg472@gmail.com (Dominick Grift)]

On Fri, Aug 26, 2011 at 09:46:01AM -0400, Christopher J. PeBenito wrote:
> On 08/24/11 08:35, Dominick Grift wrote:
> > In my previous commit i promised i would try to explain the use of the git_content attribute.
> > It is a attribute to asign to existing and to be create shared and private repository types.
> > 
> > In this commit we are using this attribute to allow Git system daemon to read and serve any
> > repository content. We do this because the userdom_git_user_template allows use to provides
> > administrators with advanced type enforcement possibility to restrict access to
> > various types of shared repository. In this commit we created the
> > git_shared_content_template.
> > 
> > This template allows for easy creation of new shared repository types.
> > We also created git_manage_spec_shared_content and git_exec_spec_shared_content_files interfaces.
> > This allows us to make a connection between Git user domain and Git shared repository content
> > types. These interfaces and templates allow administrators to create new Git user domains
> > and allow the various Git user domains access to specified Git shared repositories.
> > 
> > This allows administrators to employ Type enforcement for shared repository and Git user separation.
> > We also created a attribute called git_system_content that is assigned to all types derived from the
> > prefix that the git_shared_content_template expects. This might be handy if some one later wants a
> > given Git user domain to have access to any shared repository type and not just the primary
> > git_sys_content_t repository type.
> > 
> > Signed-off-by: Dominick Grift <domg472@gmail.com>
> > ---
> > :100644 100644 83356f2... fb27b32... M	policy/modules/services/git.if
> > :100644 100644 8602887... ba56287... M	policy/modules/services/git.te
> >  policy/modules/services/git.if |   96 ++++++++++++++++++++++++++++++++++++++++
> >  policy/modules/services/git.te |    9 ++--
> >  2 files changed, 101 insertions(+), 4 deletions(-)
> > 
> > diff --git a/policy/modules/services/git.if b/policy/modules/services/git.if
> > index 83356f2..fb27b32 100644
> > --- a/policy/modules/services/git.if
> > +++ b/policy/modules/services/git.if
> > @@ -40,6 +40,102 @@ template(`git_session_role_template',`
> >  
> >  ########################################
> >  ## <summary>
> > +##	Create a set of derived types for
> > +##	Git daemon shared repository content.
> > +## </summary>
> > +## <param name="prefix">
> > +##	<summary>
> > +##	The prefix to be used for deriving type names.
> > +##	</summary>
> > +## </param>
> > +#
> > +template(`git_shared_content_template',`
> > +	gen_require(`
> > +		attribute git_system_content, git_content;
> > +	')
> > +
> > +	type git_$1_content_t, git_system_content, git_content;
> > +	files_type(git_$1_content_t)
> > +')
> 
> I see no need to declare derived types like this.  The caller should
> create a type and call this interface on it, which adds the appropriate
> attribute(s).

Ok i did that before but i thought this would be more appropriate. (like the apache_content_template)
Is there any compelling reason as to why the caller should create a type rather than this template?

I personally like this better because it makes it easier to create new git shared content and it forces the git shared content to be uniformely named (git_*_content_t)

> 
> > +#######################################
> > +## <summary>
> > +##	Execute specified Git daemon
> > +##	shared repository content files.
> > +## </summary>
> > +## <param name="domain">
> > +##	<summary>
> > +##	Domain allowed access.
> > +##	</summary>
> > +## </param>
> > +## <param name="file_type">
> > +##	<summary>
> > +##	Type to allow access to.
> > +##	</summary>
> > +## </param>
> > +#
> > +interface(`git_exec_spec_shared_content_files',`
> > +	gen_require(`
> > +		type $1, $2;
> > +	')
> > +
> > +	exec_files_pattern($1, $2, $2)
> > +	files_search_var_lib($1)
> > +
> > +	tunable_policy(`git_system_use_cifs',`
> > +		fs_exec_cifs_files($1)
> > +	')
> > +
> > +	tunable_policy(`git_system_use_nfs',`
> > +		fs_exec_nfs_files($1)
> > +	')
> > +')
> 
> NAK.  Explicit interface(s) needs to be declared in the module that owns
> the target type.

But the target type does not exist at that point... 

I guess if we cannot implement this we lift the entrance barrier. So ok, then we not add this fine but it will make it a hell of a lot harder for joe admin to employ selinux type enforcement to implement repository seperation...

> 
> > +#######################################
> > +## <summary>
> > +##	Create, read, write, and delete
> > +##	specified Git daemon shared
> > +##	repository content.
> > +## </summary>
> > +## <param name="domain">
> > +##	<summary>
> > +##	Domain allowed access.
> > +##	</summary>
> > +## </param>
> > +## <param name="file_type">
> > +##	<summary>
> > +##	Type to allow access to.
> > +##	</summary>
> > +## </param>
> > +#
> > +interface(`git_manage_spec_shared_content',`
> > +	gen_require(`
> > +		type $1, $2;
> > +	')
> > +
> > +	manage_dirs_pattern($1, $2, $2)
> > +	manage_files_pattern($1, $2, $2)
> > +	files_search_var_lib($1)
> > +
> > +	tunable_policy(`git_system_use_cifs',`
> > +		fs_manage_cifs_dirs($1)
> > +		fs_manage_cifs_files($1)
> > +	',`
> > +		fs_dontaudit_manage_cifs_dirs($1)
> > +		fs_dontaudit_manage_cifs_files($1)
> > +	')
> > +
> > +	tunable_policy(`git_system_use_nfs',`
> > +		fs_manage_nfs_dirs($1)
> > +		fs_manage_nfs_files($1)
> > +	',`
> > +		fs_dontaudit_manage_nfs_dirs($1)
> > +		fs_dontaudit_manage_nfs_files($1)
> > +	')
> > +')
> 
> Same thing as previous interface.
> 
> > +########################################
> > +## <summary>
> >  ##	Read all Git daemon repository
> >  ##	content.
> >  ## </summary>
> > diff --git a/policy/modules/services/git.te b/policy/modules/services/git.te
> > index 8602887..ba56287 100644
> > --- a/policy/modules/services/git.te
> > +++ b/policy/modules/services/git.te
> > @@ -51,12 +51,13 @@ gen_tunable(git_system_use_cifs, false)
> >  ## </desc>
> >  gen_tunable(git_system_use_nfs, false)
> >  
> > +attribute git_system_content;
> > +
> >  type git_system_t, git_daemon;
> >  typealias git_system_t alias gitd_t;
> >  inetd_service_domain(git_system_t, gitd_exec_t)
> >  
> > -type git_sys_content_t, git_content;
> > -files_type(git_sys_content_t)
> > +git_shared_content_template(sys)
> >  
> >  ########################################
> >  #
> > @@ -118,8 +119,8 @@ tunable_policy(`use_samba_home_dirs',`
> >  # Git system daemon policy
> >  #
> >  
> > -list_dirs_pattern(git_system_t, { git_user_content_t git_sys_content_t }, { git_user_content_t git_sys_content_t })
> > -read_files_pattern(git_system_t, { git_user_content_t git_sys_content_t }, { git_user_content_t git_sys_content_t })
> > +list_dirs_pattern(git_system_t, git_content, git_content)
> > +read_files_pattern(git_system_t, git_content, git_content)
> >  files_search_var_lib(git_system_t)
> >  
> >  tunable_policy(`git_system_enable_homedirs',`
> 
> 
> -- 
> 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/20110826/a92fa661/attachment-0001.bin