From: guido@trentalancia.com (Guido Trentalancia)
Date: Wed, 15 Aug 2012 10:49:27 +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: <502B6297.1060208@trentalancia.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On 13/08/2012 15:27, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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

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

In my opinion, this is a good point, but it's only really needed in 
certain conditions (multiuser X mode). So, definitely, not on servers 
running at init level 3 or, say, kiosks running single-mode.

Ideally, tunable policy should be used to restore the above 
compatibility with NetworkManager on the desktops (and maybe those 
servers) that actually use it.

On Fedora, you could then even toggle such boolean on/off upon 
installation/removal of the NM package (%postinstall, %preinstall spec 
sections).

But having a stricter policy for safer servers should probably be the 
priority in my opinion.

Regards,

Guido