[refpolicy] [ v3 PATCH 4/8] Git session daemon

[cpebenito@tresys.com (Christopher J. PeBenito)]

On 08/31/11 10:49, Dominick Grift wrote:
> 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.

I'm not sure that these are fundamentally different views, I think its a question of pragmatism.  Of course, if it were an ideal world, I'd be happy to have a policy that fully enforces every little security goal.  Except for cases where users can only log in through the git shell or scponly, users tend to be quite variable on what they do, making it increasingly difficult to constrain.  The more you try to constrain, the unhappier users start to get, and then they might disable SELinux in response.  As maintainer, I have to balance the strength of the policy vs the complexity of the policy vs. the usefulness of the policy.  I've drawn a line in the sand that says users running system services (eg apache, samba, ftp) out of their home dir is probably not something worth covering in the policy.  If you want to do that, CIL will make it easy, since the policy writer can clone, for example, ftpd_t  into user_ftpd_t and tweak it to be runnable by user_t and export only user ftp f
iles.

To try to summarize my current positions on the contended portions of this patch set:

1. users running gitd service out of their home dirs probably isn't worth including
2. it doesn't make sense to have content types except for cases where the repos are actually exported
3. git shell can be supported, but for now I think that the template should go in the git module.  We can consider a more general template to handle this and stuff like scponly (are there other examples?) once those are understood better.

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