From: JensNeuhalfen@gmx.de (Jens Neuhalfen)
Date: Mon, 18 Aug 2008 18:09:47 +0200
Subject: [refpolicy] SeLinux policy for git-daemon
In-Reply-To: <1219073514.2609.98.camel@moss-terrapins.epoch.ncsc.mil>
References: <1219072370.15402.6.camel@desktop.local.neuhalfen.name>
	<1219072116.2609.90.camel@moss-terrapins.epoch.ncsc.mil>
	<1219073827.15402.15.camel@desktop.local.neuhalfen.name>
	<1219073514.2609.98.camel@moss-terrapins.epoch.ncsc.mil>
Message-ID: <1219075787.15402.27.camel@desktop.local.neuhalfen.name>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

Hi Dave,


> 
> I'm sure Chris and Dan will have better comments than I do but initially
> there are a couple of things that I see. The first is you might want to
> shorten git-daemon to gitd and replace git_daemon with gitd as well in
> interface names. Also since you will probably want this merged into

That sounds like a good idea. 

> reference policy you will want to make sure all of the comments are in
> English. I see a couple of comments in German through the .te file. I am

hm. Ignore them ;-) Documentation is definitely lacking. I hope to write
something that is worth the name description around next weekend.

> not a policy guru so I can't speak to the usage of interfaces and
> patterns so I will leave that to Dan and Chris. One question though is
> how did you derive this policy. Did you use the run gitd then run the
> logs through audit2allow approach?

I started to write it on my Fedora 9 system. The skeleton was generated
by one of the policygen tools. After that I borrowed from other policies
and the include-files. 

audit2allow -R was definitely helpful. To be honest, without it I would
not have started to write the policy at all. All the macros and
interfaces are *there* but you'll only find them, if you already know,
what you want to do ("So, I need  *read* access to that *file*. Lets run
grep on the sourcecode".) BTW: More inline-documentation would really be
helpful. Most people, including me, are not that familiar with the
difference between "read directory"  and "search directory" and this
uncertainty can be frustrating. 


> 
> Dave

Jens