From: guido@trentalancia.com (Guido Trentalancia) Date: Tue, 01 Mar 2011 21:41:09 +0100 Subject: [refpolicy] [patch 1/3] Implementation of system conf type In-Reply-To: <4D6D4FBA.5040005@tresys.com> 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> <4D6D4FBA.5040005@tresys.com> Message-ID: <1299012069.14035.36.camel@tesla.lan> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On Tue, 01/03/2011 at 14.57 -0500, Christopher J. PeBenito wrote: > 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. I suppose you are going to take care of that. > > 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... Yes, some distributions generate very generic banners with the name of the distribution and the version. But they are just meant to be examples (similarly to generic configuration files installed by default in /etc by most packages). They are static, so etc_t is what we need here. Regards, Guido