by cpebenito

[permalink] [raw]

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

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
http://www.tresys.com | oss.tresys.com

2011-08-31 15:38:13

by domg472

[permalink] [raw]

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

On Wed, Aug 31, 2011 at 11:14:42AM -0400, Christopher J. PeBenito wrote:
> 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.

I think ican counter this just by saying that administrators that map users to confined domains choose integrity. Administrators that "are unhappy with constraints" will map their users to unconfined_t, as per default.

In my v6 patch i removed support for git shell which simplefied policy a great deal.

>
> 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

I just dont agree, sorry

For the audience that do not like these constraints we already made great sacrifice by mapping unix users to the unconfined_u by default. So by default git session are already run unconfined (unconstrained)

Its the audience that does value integrity in the user space that i designed the git_role for. It is "hidden". Administrator has to explicitly map users to either user_u , staff_u or sysadm_u to be able to run git sessions constrained. Admins that map their unix users to confined user domain expect strict policy, i think that is safe to asume.

And even then, in my v6 patch, admin has to toggle git_session_user to allow any of the confined users to transition to the git session domain. So if git_session user is off then staff_u , user_u and sysadm_u run git-daemon in their user domain, and then git-daemon can export ~/.ssh if they so please.

What you are saying is, we'll just ignore this functionality for strict users, its not worth it.

There are people actually trying to use confined domains in their daily lives. We need to support it, not ignore it. These people want integrity in the user space.

I am representing the people that do value integrity on the desktop, and my v6 patch shows that i am willing to compromize a great deal.

> 2. it doesn't make sense to have content types except for cases where the repos are actually exported

In my v6 patch there are only two content type system content and user content.( i have removed the interfaces that allow one to create new content types ) I do not understand to context of your statement above.

> 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.

In my v6 patch i removed support for git_shell, not because i agree with you but just because i want to put this behind me. We can later maybe consider git shell support and/or support for other content types.

>
> --
> Chris PeBenito
> Tresys Technology, LLC
> http://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/fbcbf6f9/attachment-0001.bin