[refpolicy] [patch 1/3] Implementation of system conf type
Guido Trentalancia
guido at trentalancia.com
Tue Feb 22 10:18:46 CST 2011
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
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
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...
Regards,
Guido
More information about the refpolicy
mailing list