Implementation of system conf type

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

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

Quoted 4 lines · Miroslav Grepl

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.

Quoted 8 lines · Sven Vermeulen

Quoted 4 lines · Miroslav Grepl

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

Quoted 21 lines · Guido Trentalancia

Quoted 8 lines · Sven Vermeulen

Quoted 4 lines · Miroslav Grepl

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

Quoted 8 lines

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.

Quoted 23 lines · Daniel J Walsh

Quoted 21 lines · Guido Trentalancia

Quoted 8 lines · Sven Vermeulen

Quoted 4 lines · Miroslav Grepl

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

Quoted 8 lines

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 ?

Quoted 24 lines · Guido Trentalancia

Quoted 23 lines · Daniel J Walsh

Quoted 21 lines · Guido Trentalancia

Quoted 8 lines · Sven Vermeulen

Quoted 4 lines · Miroslav Grepl

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

Quoted 8 lines

Quoted 8 lines

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)

Quoted 2 lines

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.

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

Quoted 45 lines · Christopher J. PeBenito

Quoted 21 lines · Guido Trentalancia

Quoted 20 lines · Daniel J Walsh

Quoted 19 lines · Guido Trentalancia

Quoted 7 lines · Sven Vermeulen

Quoted 4 lines · Miroslav Grepl

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

Quoted 8 lines

Quoted 8 lines

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)

Quoted 2 lines

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

Quoted 5 lines

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

Quoted 24 lines · Guido Trentalancia

Quoted 23 lines · Daniel J Walsh

Quoted 21 lines · Guido Trentalancia

Quoted 8 lines · Sven Vermeulen

Quoted 4 lines · Miroslav Grepl

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

Quoted 8 lines

Quoted 8 lines

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)

Quoted 2 lines

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.

Hello Christopher !

Quoted 50 lines · Christopher J. PeBenito

Quoted 24 lines · Guido Trentalancia

Quoted 23 lines · Daniel J Walsh

Quoted 21 lines · Guido Trentalancia

Quoted 8 lines · Sven Vermeulen

Quoted 4 lines · Miroslav Grepl

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

Quoted 8 lines

Quoted 8 lines

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)

Quoted 2 lines

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

Quoted 2 lines

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

Quoted 56 lines · Guido Trentalancia

Hello Christopher !

Quoted 52 lines · Christopher J. PeBenito

Quoted 24 lines · Guido Trentalancia

Quoted 23 lines · Daniel J Walsh

Quoted 21 lines · Guido Trentalancia

Quoted 8 lines · Sven Vermeulen

Quoted 4 lines · Miroslav Grepl

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

Quoted 8 lines

Quoted 8 lines

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)

Quoted 2 lines

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.

Quoted 4 lines

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.

Quoted 7 lines

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

Quoted 3 lines

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

Quoted 19 lines · Christopher J. PeBenito

Quoted 18 lines · Guido Trentalancia

Quoted 16 lines · Christopher J. PeBenito

Quoted 2 lines · Guido Trentalancia

Quoted 1 line · Daniel J Walsh

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)

Quoted 2 lines

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.

Quoted 6 lines

Quoted 4 lines

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.

Quoted 15 lines

Quoted 7 lines

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

Quoted 3 lines

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.

Quoted 25 lines · Guido Trentalancia

Quoted 24 lines · Christopher J. PeBenito

Quoted 22 lines · Guido Trentalancia

Quoted 11 lines · Christopher J. PeBenito

Quoted 2 lines · Guido Trentalancia

Quoted 1 line · Daniel J Walsh

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)

Quoted 5 lines

Quoted 2 lines

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

Quoted 3 lines

Quoted 1 line

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.

Quoted 22 lines

Quoted 15 lines

Quoted 7 lines

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

Quoted 3 lines

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.

Quoted 25 lines · Guido Trentalancia

Quoted 24 lines · Christopher J. PeBenito

Quoted 22 lines · Guido Trentalancia

Quoted 11 lines · Christopher J. PeBenito

Quoted 2 lines · Guido Trentalancia

Quoted 1 line · Daniel J Walsh

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)

Quoted 5 lines

Quoted 2 lines

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

Quoted 3 lines

Quoted 1 line

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.

Quoted 22 lines

Quoted 15 lines

Quoted 7 lines

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

Quoted 3 lines

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.

Quoted 26 lines · Christopher J. PeBenito

Quoted 25 lines · Guido Trentalancia

Quoted 24 lines · Christopher J. PeBenito

Quoted 22 lines · Guido Trentalancia

Quoted 11 lines · Christopher J. PeBenito

Quoted 2 lines · Guido Trentalancia

Quoted 1 line · Daniel J Walsh

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)

Quoted 5 lines

Quoted 2 lines

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

Quoted 29 lines

Quoted 3 lines

Quoted 1 line

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.

Quoted 22 lines

Quoted 15 lines

Quoted 7 lines

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

Quoted 3 lines

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

Quoted 26 lines · Christopher J. PeBenito

Quoted 25 lines · Guido Trentalancia

Quoted 24 lines · Christopher J. PeBenito

Quoted 22 lines · Guido Trentalancia

Quoted 11 lines · Christopher J. PeBenito

Quoted 2 lines · Guido Trentalancia

Quoted 1 line · Daniel J Walsh

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)

Quoted 5 lines

Quoted 2 lines

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

Quoted 29 lines

Quoted 3 lines

Quoted 1 line

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.

Quoted 22 lines

Quoted 15 lines

Quoted 7 lines

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

Quoted 3 lines

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 ?

Quoted 74 lines · Guido Trentalancia

Quoted 26 lines · Christopher J. PeBenito

Quoted 25 lines · Guido Trentalancia

Quoted 24 lines · Christopher J. PeBenito

Quoted 22 lines · Guido Trentalancia

Quoted 11 lines · Christopher J. PeBenito

Quoted 2 lines · Guido Trentalancia

Quoted 1 line · Daniel J Walsh

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)

Quoted 5 lines

Quoted 2 lines

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

Quoted 29 lines

Quoted 3 lines

Quoted 1 line

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.

Quoted 22 lines

Quoted 15 lines

Quoted 7 lines

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

Quoted 3 lines

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.

Quoted 5 lines

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.

Quoted 1 line

I also take the opportunity to remind you of the issue with mtab

lock

Quoted 9 lines

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

Quoted 4 lines

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

Quoted 4 lines

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

Quoted 4 lines

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

Quoted 24 lines · Guido Trentalancia

Quoted 23 lines · Daniel J Walsh

Quoted 21 lines · Guido Trentalancia

Quoted 8 lines · Sven Vermeulen

Quoted 4 lines · Miroslav Grepl

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

Quoted 8 lines

Quoted 8 lines

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.

Hello again Christopher !

Quoted 34 lines · Christopher J. PeBenito

Quoted 24 lines · Guido Trentalancia

Quoted 23 lines · Daniel J Walsh

Quoted 21 lines · Guido Trentalancia

Quoted 8 lines · Sven Vermeulen

Quoted 4 lines · Miroslav Grepl

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

Quoted 8 lines

Quoted 8 lines

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.

Quoted 4 lines

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.

Quoted 42 lines · Guido Trentalancia

Hello again Christopher !

Quoted 34 lines · Christopher J. PeBenito

Quoted 24 lines · Guido Trentalancia

Quoted 23 lines · Daniel J Walsh

Quoted 21 lines · Guido Trentalancia

Quoted 8 lines · Sven Vermeulen

Quoted 4 lines · Miroslav Grepl

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

Quoted 8 lines

Quoted 8 lines

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.

Quoted 4 lines

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.

Quoted 8 lines

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.