[refpolicy] [patch 1/3] Implementation of system conf type

[refpolicy] [patch 1/3] Implementation of system conf type

[Miroslav Grepl]

http://mgrepl.fedorapeople.org/F15/system_conf_implemantion_p1.patch

     * Implementation of system conf type for manageable system 
configuration files.

[refpolicy] [patch 1/3] Implementation of system conf type

[Sven Vermeulen]

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.

Wkr,
	Sven Vermeulen

[refpolicy] [patch 1/3] Implementation of system conf type

[Guido Trentalancia]

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

Regards,

Guido

[refpolicy] [patch 1/3] Implementation of system conf type

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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).
> 
> Regards,
> 
> Guido
> 
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy

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.

We have lots of examples of this, for example net_conf_t for
/etc/resolv.conf.

As configuration tools move to a dbus/policykit config, you will see
more "config" files gather labels.  As we try to add domains for
confined administrator, you will also see types added.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk1ih1kACgkQrlYvE4MpobOQtwCgxIxBkC7WtMV/uzUDiVercj5A
nAYAoKV6ywEHdiAwRPSheCN9nbOXmcuo
=mGAX
-----END PGP SIGNATURE-----

[refpolicy] [patch 1/3] Implementation of system conf type

[Guido Trentalancia]

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).
> > 
> > Regards,
> > 
> > Guido
> > 
> > _______________________________________________
> > refpolicy mailing list
> > refpolicy at oss.tresys.com
> > http://oss.tresys.com/mailman/listinfo/refpolicy
> 
> 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.

Yes, this is very important. But isn't etc_runtime_t what is needed here
then ?

That should be writable but distinct from critical etc_t. Not 100% sure
and I haven't checked but as far as I remember...

Regards,

Guido

[refpolicy] [patch 1/3] Implementation of system conf type

[Christopher J. PeBenito]

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.



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

[refpolicy] [patch 1/3] Implementation of system conf type

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/22/2011 10:46 AM, 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.
> 
> 
> 
I am fine with the iptables_conf_t also, not sure why mgrepl changed the
label.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk1j3QAACgkQrlYvE4MpobMwTgCguDuLlwCC0V10z94QzIZWCqyT
ITkAn1P1KcmimuBZxRdSNI/eLJgT+FTF
=Ug15
-----END PGP SIGNATURE-----

[refpolicy] [patch 1/3] Implementation of system conf type

[Guido Trentalancia]

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

[refpolicy] [patch 1/3] Implementation of system conf type

[Guido Trentalancia]

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 do you say ?

Regards,

Guido

Regards,

Guido

[refpolicy] [patch 1/3] Implementation of system conf type

[Miroslav Grepl]

On 02/22/2011 03:57 PM, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 02/22/2011 10:46 AM, 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.
>>
>>
>>
> I am fine with the iptables_conf_t also, not sure why mgrepl changed the
> label.
The problem is with sysctl.conf/systctl.conf.old files which are 
writeable/created by s-c-firewall.

My first idea was adding of the iptables_conf_t type for these files.

But we were discussing it and since sysctl.conf is used for more than 
just network settings so using the iptables_conf_t label for it seemed 
fishy.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk1j3QAACgkQrlYvE4MpobMwTgCguDuLlwCC0V10z94QzIZWCqyT
> ITkAn1P1KcmimuBZxRdSNI/eLJgT+FTF
> =Ug15
> -----END PGP SIGNATURE-----

[refpolicy] [patch 1/3] Implementation of system conf type

[Christopher J. PeBenito]

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

[refpolicy] [patch 1/3] Implementation of system conf type

[Christopher J. PeBenito]

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

[refpolicy] [patch 1/3] Implementation of system conf type

[Guido Trentalancia]

On Tue, 01/03/2011 at 15.01 -0500, Christopher J. PeBenito wrote:
> 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.

First of all I am not sure that that this system conf from Fedora 15 has
anything to do with kernel parameters or is something similar to
sysctl.conf on Debian.

And for sure this is not something that is needed right now.

On the other hand, having a separate label for sysctl.conf (and anything
similar to sysctl.conf on other distributions) would be an investment
for the future if one day somebody develops an application that needs to
write those files (either interactively or automatically). At that
point, the policy needs to specify who is allowed to write those files
which would be treated for what they are and not as generic etc_t files.

An example of such application could be a graphical system
administration tool (an interactive tool) that can be used not only by
sysadm but also by others. Such tool could then modify the new file type
but not /etc/passwd or /etc/bashrc.

In my opinion, in the current situation there is very little benefit
from having that (other than being "future-proof").

Regards,

Guido

[refpolicy] [patch 1/3] Implementation of system conf type

[Guido Trentalancia]

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

[refpolicy] [patch 1/3] Implementation of system conf type

[Christopher J. PeBenito]

On 03/01/11 15:41, Guido Trentalancia wrote:
> On Tue, 01/03/2011 at 14.57 -0500, Christopher J. PeBenito wrote:
>> On 02/22/11 11:18, Guido Trentalancia wrote:
>>> 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:
>>>> 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.

Dan/Miroslav, do you have any thoughts on this?  I think these lines and
the below four lines should be removed.

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

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

[refpolicy] [patch 1/3] Implementation of system conf type

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/02/2011 09:33 AM, Christopher J. PeBenito wrote:
> On 03/01/11 15:41, Guido Trentalancia wrote:
>> On Tue, 01/03/2011 at 14.57 -0500, Christopher J. PeBenito wrote:
>>> On 02/22/11 11:18, Guido Trentalancia wrote:
>>>> 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:
>>>>> 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.
> 
> Dan/Miroslav, do you have any thoughts on this?  I think these lines and
> the below four lines should be removed.
> 
>>>> 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.
> 

Remove them and we will see what happens.  The scripts that fix them,
might need to run restorecon if they need to create them.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk1uljAACgkQrlYvE4MpobML7ACcDfDzQLPdga3a0qX/9RfQd9yo
mGAAoISVP8wZaWvU5TdUXNVEBToD7sK4
=Vx8k
-----END PGP SIGNATURE-----

[refpolicy] [patch 1/3] Implementation of system conf type

[Guido Trentalancia]

On Wed, 02/03/2011 at 09.33 -0500, Christopher J. PeBenito wrote:
> On 03/01/11 15:41, Guido Trentalancia wrote:
> > On Tue, 01/03/2011 at 14.57 -0500, Christopher J. PeBenito wrote:
> >> On 02/22/11 11:18, Guido Trentalancia wrote:
> >>> 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:
> >>>> 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.
> 
> Dan/Miroslav, do you have any thoughts on this?  I think these lines and
> the below four lines should be removed.
> 
> >>> 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.

I also take the opportunity to remind you of the issue with mtab lock
files that I had already mentioned a few days ago.

Basically, mount tries to create lock files named:

/etc/mtab~<pid>

where <pid> gets substituted with the process id of mount itself.

Unfortunately at the moment these files are currently falling back to
the etc_t label. It is very much desirable to have them labeled
etc_runtime_t to avoid problems (denials) with write operations.

Originally the name for those lock files was /etc/mtab~. To avoid race
conditions it was decided to append the <pid>. The source code is
designed so that the upper bound for the length of <pid> is 20.

Please note that contrary to what is stated in the source code for mount
(fstab.c) there is no dot between "/etc/mtab~" and "<pid>" (it's not
"/etc/mtab~.<pid>") !

Can somebody please take care of this ?

Regards,

Guido

[refpolicy] [patch 1/3] Implementation of system conf type

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/03/2011 09:36 AM, Guido Trentalancia wrote:
> On Wed, 02/03/2011 at 09.33 -0500, Christopher J. PeBenito wrote:
>> On 03/01/11 15:41, Guido Trentalancia wrote:
>>> On Tue, 01/03/2011 at 14.57 -0500, Christopher J. PeBenito wrote:
>>>> On 02/22/11 11:18, Guido Trentalancia wrote:
>>>>> 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:
>>>>>> 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.
>>
>> Dan/Miroslav, do you have any thoughts on this?  I think these lines and
>> the below four lines should be removed.
>>
>>>>> 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.
> 
> I also take the opportunity to remind you of the issue with mtab lock
> files that I had already mentioned a few days ago.
> 
> Basically, mount tries to create lock files named:
> 
> /etc/mtab~<pid>
> 
> where <pid> gets substituted with the process id of mount itself.
> 
> Unfortunately at the moment these files are currently falling back to
> the etc_t label. It is very much desirable to have them labeled
> etc_runtime_t to avoid problems (denials) with write operations.
> 
> Originally the name for those lock files was /etc/mtab~. To avoid race
> conditions it was decided to append the <pid>. The source code is
> designed so that the upper bound for the length of <pid> is 20.
> 
> Please note that contrary to what is stated in the source code for mount
> (fstab.c) there is no dot between "/etc/mtab~" and "<pid>" (it's not
> "/etc/mtab~.<pid>") !
> 
> Can somebody please take care of this ?
> 
> Regards,
> 
> Guido
> 
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy


Well one nice thing in F15 /etc/mtab is going away.

 ls -l /etc/mtab
lrwxrwxrwx. 1 root root 12 Mar  1 08:15 /etc/mtab -> /proc/mounts

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk1vtIsACgkQrlYvE4MpobNivwCgpW04FPOkyO3AiuqHH040qgGR
x8AAnjU6Xxp7u2f2ii2RgFUeezdEHGX7
=G4SU
-----END PGP SIGNATURE-----

[refpolicy] [patch 1/3] Implementation of system conf type

[Christopher J. PeBenito]

On 03/03/11 09:36, Guido Trentalancia wrote:
> On Wed, 02/03/2011 at 09.33 -0500, Christopher J. PeBenito wrote:
>> On 03/01/11 15:41, Guido Trentalancia wrote:
>>> On Tue, 01/03/2011 at 14.57 -0500, Christopher J. PeBenito wrote:
>>>> On 02/22/11 11:18, Guido Trentalancia wrote:
>>>>> 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:
>>>>>> 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.
>>
>> Dan/Miroslav, do you have any thoughts on this?  I think these lines and
>> the below four lines should be removed.
>>
>>>>> 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.
> 
> I also take the opportunity to remind you of the issue with mtab lock
> files that I had already mentioned a few days ago.
> 
> Basically, mount tries to create lock files named:
> 
> /etc/mtab~<pid>
> 
> where <pid> gets substituted with the process id of mount itself.
> 
> Unfortunately at the moment these files are currently falling back to
> the etc_t label. It is very much desirable to have them labeled
> etc_runtime_t to avoid problems (denials) with write operations.
> 
> Originally the name for those lock files was /etc/mtab~. To avoid race
> conditions it was decided to append the <pid>. The source code is
> designed so that the upper bound for the length of <pid> is 20.
> 
> Please note that contrary to what is stated in the source code for mount
> (fstab.c) there is no dot between "/etc/mtab~" and "<pid>" (it's not
> "/etc/mtab~.<pid>") !
> 
> Can somebody please take care of this ?

I don't see why this would be happening.  There are the following rules
in mount:

files_manage_etc_runtime_files(mount_t)
files_etc_filetrans_etc_runtime(mount_t, file)

So the file should be created with etc_runtime_t.  The only reasons I
can think of this mtab~<pid> file having etc_t are

1. it was there already and someone did a relabel
2. some new SELinux logic in it that does a matchpathcon on the filename
and then does setfscreatecon() to that context.

So if either of those is the case, you could add a file context entry to
try to fix it.

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

[refpolicy] [patch 1/3] Implementation of system conf type

[Guido Trentalancia]

Hello Christopher !

Thanks for getting back on this.

On Fri, 04/03/2011 at 09.21 -0500, Christopher J. PeBenito wrote:
> On 03/03/11 09:36, Guido Trentalancia wrote:
> > On Wed, 02/03/2011 at 09.33 -0500, Christopher J. PeBenito wrote:
> >> On 03/01/11 15:41, Guido Trentalancia wrote:
> >>> On Tue, 01/03/2011 at 14.57 -0500, Christopher J. PeBenito wrote:
> >>>> On 02/22/11 11:18, Guido Trentalancia wrote:
> >>>>> 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:
> >>>>>> 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.
> >>
> >> Dan/Miroslav, do you have any thoughts on this?  I think these lines and
> >> the below four lines should be removed.
> >>
> >>>>> 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.
> > 
> > I also take the opportunity to remind you of the issue with mtab lock
> > files that I had already mentioned a few days ago.
> > 
> > Basically, mount tries to create lock files named:
> > 
> > /etc/mtab~<pid>
> > 
> > where <pid> gets substituted with the process id of mount itself.
> > 
> > Unfortunately at the moment these files are currently falling back to
> > the etc_t label. It is very much desirable to have them labeled
> > etc_runtime_t to avoid problems (denials) with write operations.
> > 
> > Originally the name for those lock files was /etc/mtab~. To avoid race
> > conditions it was decided to append the <pid>. The source code is
> > designed so that the upper bound for the length of <pid> is 20.
> > 
> > Please note that contrary to what is stated in the source code for mount
> > (fstab.c) there is no dot between "/etc/mtab~" and "<pid>" (it's not
> > "/etc/mtab~.<pid>") !
> > 
> > Can somebody please take care of this ?
> 
> I don't see why this would be happening.  There are the following rules
> in mount:
> 
> files_manage_etc_runtime_files(mount_t)
> files_etc_filetrans_etc_runtime(mount_t, file)
> 
> So the file should be created with etc_runtime_t.  The only reasons I
> can think of this mtab~<pid> file having etc_t are
> 
> 1. it was there already and someone did a relabel

This is not the case. The test system has only one administrator, only
one user and that is me.

> 2. some new SELinux logic in it that does a matchpathcon on the filename
> and then does setfscreatecon() to that context.

In util-linux-2.19 matchpathcon() is only used by disk-utils/mkswap.c
and setfscreatecon() is only used by login-utils/selinux_utils.c (none
of them is used to build mount). The same is true for the previous
version of util-linux.

> So if either of those is the case, you could add a file context entry to
> try to fix it.

Any other idea ?

Regards,

Guido

[refpolicy] mtab lock files label (was [patch 1/3] Implementation of system conf type)

[Guido Trentalancia]

On Fri, 04/03/2011 at 09.21 -0500, Christopher J. PeBenito wrote:
> > I also take the opportunity to remind you of the issue with mtab
> lock
> > files that I had already mentioned a few days ago.
> > 
> > Basically, mount tries to create lock files named:
> > 
> > /etc/mtab~<pid>
> > 
> > where <pid> gets substituted with the process id of mount itself.
> > 
> > Unfortunately at the moment these files are currently falling back
> to
> > the etc_t label. It is very much desirable to have them labeled
> > etc_runtime_t to avoid problems (denials) with write operations.
> > 
> > Originally the name for those lock files was /etc/mtab~. To avoid
> race
> > conditions it was decided to append the <pid>. The source code is
> > designed so that the upper bound for the length of <pid> is 20.
> > 
> > Please note that contrary to what is stated in the source code for
> mount
> > (fstab.c) there is no dot between "/etc/mtab~" and "<pid>" (it's not
> > "/etc/mtab~.<pid>") !
> > 
> > Can somebody please take care of this ?
> 
> I don't see why this would be happening.  There are the following
> rules
> in mount:
> 
> files_manage_etc_runtime_files(mount_t)
> files_etc_filetrans_etc_runtime(mount_t, file)
> 
> So the file should be created with etc_runtime_t.  The only reasons I
> can think of this mtab~<pid> file having etc_t are
> 
> 1. it was there already and someone did a relabel

Explained. /etc/mtab* easily ends up in restorecond.conf (it's even in
selinuxproject.org). Now to me the incorrect etc_t type for mtab lock
files looks as a bug in the file contexts definitions that should be
fixed.

> 2. some new SELinux logic in it that does a matchpathcon on the
> filename
> and then does setfscreatecon() to that context.
> 
> So if either of those is the case, you could add a file context entry
> to
> try to fix it.

Regards,

Guido