From: domg472@gmail.com (Dominick Grift) Date: Fri, 26 Aug 2011 19:26:50 +0200 Subject: [refpolicy] [ v3 PATCH 3/8] Git shell users In-Reply-To: <4E579F86.9090209@tresys.com> References: <1314189346-10866-1-git-send-email-domg472@gmail.com> <1314189346-10866-4-git-send-email-domg472@gmail.com> <20110825090755.GA11966@localhost.localdomain> <4E579F86.9090209@tresys.com> Message-ID: <20110826172649.GF8869@localhost.localdomain> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On Fri, Aug 26, 2011 at 09:28:38AM -0400, Christopher J. PeBenito wrote: > On 08/25/11 05:07, Dominick Grift wrote: > > On Wed, Aug 24, 2011 at 02:35:41PM +0200, Dominick Grift wrote: > > > > Today i was reading an article about the scponly shell. This seems to have properties similar to Git shell. Maybe we could make userdom_git_user_template -> userdom_base_user_template, and rename the current userdom_base_user_template, or something along those lines. > > > > I have been thinking about possible arguments against a userdom_git_user_tempplate. > > > > Q: Why not just use userdom_base_user_template for "git shell (and possibly scponly) users? > > A: That would make it harder to configure for administrators. The nice thing about this current implementation is that a default Git shell seuser exists. Administrators can just map their users logins to it and start. It provides Git shell users with access to generic shared repositories. Besides, compare the userdom_git_user_template to userdom_base_user_template, the laster gives the caller way more privileges that arent needed. > > I'm very conflicted on this point. My initial reaction is that I don't > like putting any git stuff in userdomain and that > userdom_base_user_template is fine. Alternatively we could make a > generic template which is useful for special user shell accounts like > git_shell and scponly. I'll have to think about it more. > > > But userdom_git_user_template is useless for scponly users currently because it provides access to generic shared repositories. We do not want scponly users to have this privilege. > > > > That brings me to another issue where the inteface calls git_manage_generic_sys_content and git exec_generic_content_files are not optional policy in the userdom_git_user_template. Which means any calling module will have a dependency on the git module. So this is just a bit of brainstorming. Were making the current userdom_git_user_template the new userdom_base_user_template ( and were renaming the current userdom_base_user_template to something else and base that off of the current userdom_git_user_template. Were removing any reference to git_manage| exec_generic_sys_content from the current userdom_git_user_template. Then we create a git_shared_content_template that is expecting a prefix as it currently does but we merge the current userdom_git_user_template, git_shared_content_template and git_manage| exec_spec_shared_content into the single one. we call the (new) userdom_base_user_template(prefix), use the prefix to also prefix the new shared repository type and now we also can provide the user access to the prefixed git shared content: allow $1_t git_$1_content_t:file { manage_file_perms execute_file_perms }; we also allow $1_t access to manage and execute generic shared repositories in there. hmm this seems like a good idea to me, that would make it very easy for admins to configure, plus we could reuse the new userdom_base_user_template for for example scponly. The only problem is that git module will now have a userdomain template (although based off of the userdom_base_user_template from userdomain) > > > >> Did you know that there is a Git shell in /usr/bin/git-shell, and did you know that you can use that > >> together with OpenSSH to commit to shared repositories? Heck you can even commit to shared repositories > >> using OpenSSH with a plain bash shell, but the Git shell is much cooler. A user domain solely for the > >> purpose of commiting to shared repositories needs much less privileges that the least privilege > >> userdom_base_user_template provides. > >> > >> Git shell users do not need pty's, execmem or many other privileges provided by the base_user_template. > >> Therefore we implement a template just for Git shell users, and we create a Git shell role, so that > >> administrators can easily map their Unix logins to the Git shell SELinux user. > >> > >> This Git shell user domain is allowed to manage and execute (primary) shared repositories. > >> > >> FIXED: the default context in config/appconfig-mls for git_shell_u was wrong. > >> git_shell.te: userdom_git_user_template was called by git_user but should be called by git_shell > >> > >> Fix2: booleans git_system_use_cifs and git_system_use_nfs are currenlty named gitd_use_cifs and gitd_use_nfs respectively > >> > >> Signed-off-by: Dominick Grift > >> --- > >> :000000 100644 0000000... 2d9c6bc... A config/appconfig-mcs/git_shell_u_default_contexts > >> :000000 100644 0000000... 2d9c6bc... A config/appconfig-mls/git_shell_u_default_contexts > >> :000000 100644 0000000... bfbd788... A config/appconfig-standard/git_shell_u_default_contexts > >> :000000 100644 0000000... 601a7b0... A policy/modules/roles/git_shell.fc > >> :000000 100644 0000000... c6d9896... A policy/modules/roles/git_shell.if > >> :000000 100644 0000000... f5aa6cb... A policy/modules/roles/git_shell.te > >> :100644 100644 4da6875... 6238d54... M policy/modules/services/git.if > >> :100644 100644 2dc8697... 5c30b4b... M policy/modules/system/userdomain.if > >> config/appconfig-mcs/git_shell_u_default_contexts | 2 + > >> config/appconfig-mls/git_shell_u_default_contexts | 2 + > >> .../git_shell_u_default_contexts | 2 + > >> policy/modules/roles/git_shell.fc | 1 + > >> policy/modules/roles/git_shell.if | 50 +++++++++++++++ > >> policy/modules/roles/git_shell.te | 15 +++++ > >> policy/modules/services/git.if | 67 ++++++++++++++++++++ > >> policy/modules/system/userdomain.if | 63 ++++++++++++++++++ > >> 8 files changed, 202 insertions(+), 0 deletions(-) > > -- > 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/0493e529/attachment.bin