From: dominick.grift@gmail.com (Dominick Grift)
Date: Mon, 13 Aug 2012 15:31:36 +0200
Subject: [refpolicy] ntp issue
In-Reply-To: <502900CF.4030405@redhat.com>
References: <1344615611.6662.4.camel@d30.localdomain>
	<50256007.4040807@trentalancia.com> <502900CF.4030405@redhat.com>
Message-ID: <1344864696.11236.9.camel@d30.localdomain>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com



On Mon, 2012-08-13 at 09:27 -0400, Daniel J Walsh wrote:
> On 08/10/2012 03:24 PM, Guido Trentalancia wrote:
> > On 10/08/2012 18:20, Dominick Grift wrote:
> >> I was playing with ntp_admin() and i figured out that /etc/ntp.conf is 
> >> labeled net_conf_t. What is the rationale behind that decision, I dont 
> >> see it?
> > 
> > If net_conf_t is also used in ntp.te then it sounds like a security flaw.
> > 
> > Otherwise, it's a typo, which however might not be unlikely to lead to a 
> > security flaw in the future.
> > 
> >> Whatever the reason for this is, its not implemented properly. The 
> >> net_conf_t type should not be used in the ntp.fc file.
> > 
> >> Instead, if one really wants /etc/ntp.conf to be net_conf_t, then move 
> >> the fc spec to sysnetwork.fc
> > 
> > There should be its own type.
> > 
> >> But again i dont see why this file has to be net_conf_t. Its not good for
> >> ntp_admin either. I wouldnt want my ntp_admin to have access to 
> >> net_conf_t files just so that he is able to manage ntp config files
> > 
> > Regards,
> > 
> > Guido _______________________________________________ refpolicy mailing
> > list refpolicy at oss.tresys.com 
> > http://oss.tresys.com/mailman/listinfo/refpolicy
> > 
> 
> I agree it should not be net_conf_t, but I think we will need to make sure
> that NetworkManager_t can configure it, as it was most likely changed to this
> label when a network configuration tool needed to manage it.  Now that we have
> filename transition rules we can label /etc/resolv.conf and /etc/ntp.conf
> differently and allow network manage ment tools to manage and maintain the labels.

That is what i thought as well but git blame shows otherwise. This has
been there ever since the first iteration of this module.