From: cpebenito@tresys.com (Christopher J. PeBenito) Date: Tue, 01 Mar 2011 14:57:46 -0500 Subject: [refpolicy] [patch 1/3] Implementation of system conf type In-Reply-To: <1298391526.16004.8.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> <1298391526.16004.8.camel@tesla.lan> Message-ID: <4D6D4FBA.5040005@tresys.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 02/22/11 11:18, Guido Trentalancia wrote: > Hello 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. >> >> I don't understand why system-config-firewall would need to write to >> etc_t, the iptables rules have their own labeling: >> >> /etc/sysconfig/ip6?tables.* -- >> gen_context(system_u:object_r:iptables_conf_t,s0) >> /etc/sysconfig/system-config-firewall.* -- >> gen_context(system_u:object_r:iptables_conf_t,s0) >> >>> Yes, this is very important. But isn't etc_runtime_t what is needed here >>> then ? >> >> No, the purpose of that type is for generated files such as /.autofsck >> and /etc/motd. > > Well then I think we need to check a few labels: > > /etc/smartd\.conf.* -- system_u:object_r:etc_runtime_t:s0 > /etc/reader\.conf -- system_u:object_r:etc_runtime_t:s0 Right, these need to be reevaluated. > And there is also other stuff that is not automatically-generated (if > that is what you meant for "generated"): > > /etc/motd -- system_u:object_r:etc_runtime_t:s0 > /etc/issue -- system_u:object_r:etc_runtime_t:s0 > /etc/HOSTNAME -- system_u:object_r:etc_runtime_t:s0 > /etc/issue\.net -- system_u:object_r:etc_runtime_t:s0 These can be generated out of init scripts. For example, Fedora used to generate /etc/issue out of a init script. It doesn't look like they do that anymore, so perhaps we should reconsider these too > All the above mentioned files are configuration files by all means. Not > that it's an urgent matter, but according to what you just said, then > etc_runtime_t is possibly misplaced there... -- Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com