From: domg472@gmail.com (Dominick Grift) Date: Wed, 31 Aug 2011 16:49:10 +0200 Subject: [refpolicy] [ v3 PATCH 4/8] Git session daemon In-Reply-To: <4E5E470A.5010609@tresys.com> 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> <4E5E470A.5010609@tresys.com> Message-ID: <20110831144908.GA11607@localhost.localdomain> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On Wed, Aug 31, 2011 at 10:36:58AM -0400, Christopher J. PeBenito wrote: > 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. I guess that depends on ones vision. Integrity is integrity for me. I am using SELinux policy tuned strict. I want some integrity in the user space. Yes you probably could run git -daemon and or apache as session in the user domain. You would need to set user_tcp_server. Yet this provides no integrity in the user space. E.g. git-daemon or apache will be able to serve my ssh private key, will be able to mess with my processes etc etc. I am going to step back right here because we keep arguing over some fundamental different views. > > -- > 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/20110831/fb338146/attachment.bin