From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Tue, 01 Mar 2011 15:01:00 -0500
Subject: [refpolicy] [patch 1/3] Implementation of system conf type
In-Reply-To: <1298392040.16004.15.camel@tesla.lan>
References: <4D5E95C1.9080805@redhat.com> <20110219095711.GA6270@siphos.be>	
	<1298180267.3098.11.camel@tesla.lan> <4D62875A.8060006@redhat.com>	
	<1298319075.11119.3.camel@tesla.lan> <4D63DA61.3050705@tresys.com>
	<1298392040.16004.15.camel@tesla.lan>
Message-ID: <4D6D507C.2040906@tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On 02/22/11 11:27, Guido Trentalancia wrote:
> Hello again Christopher !
> 
> On Tue, 22/02/2011 at 10.46 -0500, Christopher J. PeBenito wrote:
>> On 02/21/11 15:11, Guido Trentalancia wrote:
>>> On Mon, 21/02/2011 at 10.40 -0500, Daniel J Walsh wrote:
>>>> On 02/20/2011 12:37 AM, Guido Trentalancia wrote:
>>>>> On Sat, 19/02/2011 at 10.57 +0100, Sven Vermeulen wrote:
>>>>>> On Fri, Feb 18, 2011 at 03:52:33PM +0000, Miroslav Grepl wrote:
>>>>>>> http://mgrepl.fedorapeople.org/F15/system_conf_implemantion_p1.patch
>>>>>>>
>>>>>>>      * Implementation of system conf type for manageable system 
>>>>>>> configuration files.
>>>>>>
>>>>>> Isn't a generic system configuration type a bit too broad for a security
>>>>>> policy? We already have etc_t.
>>>>>
>>>>> I agree with Sven, it appears to be rather useless (at least for the use
>>>>> that is being made so far in the patches that have been posted) and it
>>>>> just introduces a redundancy of types.
>>>>>
>>>>> But Sven, I believe this is stuff just intended for Fedora 15. It won't
>>>>> affect the rest of us. I don't even understand why it has been posted
>>>>> with the [PATCH] tag in the subject on this mailing list. Some stuff
>>>>> won't even build on refpolicy because there are missing bits (such as
>>>>> missing interfaces that have never been defined in refpolicy and that
>>>>> are only being used by Fedora as part of their customisations).
>>>>>
>>>>
>>>> When you have a type a domain needs to write, you do not want that type
>>>> to be etc_t.  In this case several confined domains needs to be able to
>>>> write firewall rules, I believe.  If we give tools like
>>>> system-config-firewall the ability to write etc_t, it can replace
>>>> /etc/passwd and other key config files.  So an exploit can be used to
>>>> take over the entire machine, if we add a new type, then
>>>> system-config-firewall will only be allowed to write firewall rules and
>>>> not most files within the /etc tree.
>>
>> I am against system_conf_t as it is too generic.  Yes, we'd like to curb
>> writing to etc_t.  But creating another generic type is not the answer.
>>  In a year or two, we'd be in the same boat except with system_conf_t
>> instead of (or maybe in addition to) etc_t.
> 
> However, a label for configuration files that tweak kernel parameters
> could be a nice thing to have. So, it would not be generic. And it could
> bring security benefits, as kernel parameters are critical.
> 
> Something like kernel_conf_t ? That could be used for Fedora's sysconf
> (if it has something to do with kernel parameters),
> Debian's /etc/sysctl.conf and so on. It could be used for things such as
> grub that also has kernel boot parameters.

What other examples are there other than sysctl.conf?  If there are
none, then we could consider sysctl_conf_t, but I don't know of a reason
for anyone other than the sysadmin or the package manager for modifying
that file.  Both are trusted to handle etc_t.

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