Mount output should be writeable to puppet_tmp_t

When using puppet to configure systems, the puppet system runs the mount command and captures its output in a temporary file in /tmp (which is labeled puppet_tmp_t).

Signed-off-by Sven Vermeulen <[email protected]>

---
 policy/modules/system/mount.te |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

policy/modules/system/mount.te +0 -0

index 1284081..ca9cdc0 100644

Quoted 3 lines · Sven Vermeulen

When using puppet to configure systems, the puppet system runs the mount command and captures its output in a temporary file in /tmp (which is labeled puppet_tmp_t).

I wonder what it is exactly what is causing puppet to run mount.

Fedoras' puppet policy does not allow puppet to run mount and domain transition to mount_t.

I wonder why Fedoras' puppet seems to not need this access.

Quoted 13 lines

Signed-off-by Sven Vermeulen <[email protected]>

---
 policy/modules/system/mount.te |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

policy/modules/system/mount.te +0 -0

index 1284081..ca9cdc0 100644
@@ -191,6 +191,10 @@ optional_policy(`
 	')
 ')
 

policy/modules/system/mount.te optional_policy(` · line 200

Quoted 7 lines

policy/modules/system/mount.te +4 -0

+optional_policy(`
+	puppet_rw_tmp(mount_t)
+')
+
 # for kernel package installation
 optional_policy(`
 	rpm_rw_pipes(mount_t)

Quoted 11 lines · Dominick Grift

Quoted 3 lines · Sven Vermeulen

When using puppet to configure systems, the puppet system runs the mount command and captures its output in a temporary file in /tmp (which is labeled puppet_tmp_t).

I wonder what it is exactly what is causing puppet to run mount.

Fedoras' puppet policy does not allow puppet to run mount and domain transition to mount_t.

I wonder why Fedoras' puppet seems to not need this access.

I guess it is because puppet_t is a unconfined domain.

Fedora should make these domains unconfined when the release goes stable only imho.

Quoted 4 lines

Quoted 4 lines

Signed-off-by Sven Vermeulen <[email protected]> ---

policy/modules/system/mount.te | 4 ++++ 1 files changed, 4
insertions(+), 0 deletions(-)

Quoted 9 lines

Quoted 8 lines

(quoted diff) +0 -0

b/policy/modules/system/mount.te index 1284081..ca9cdc0 100644
--- a/policy/modules/system/mount.te +++
b/policy/modules/system/mount.te @@ -191,6 +191,10 @@ optional_policy(` ') ')

+optional_policy(` + puppet_rw_tmp(mount_t) +') + # for kernel
package installation optional_policy(` rpm_rw_pipes(mount_t)

_______________________________________________ refpolicy mailing list refpolicy at oss.tresys.com
http://oss.tresys.com/mailman/listinfo/refpolicy

We usually go from permissive to unconfined when we try to spin off to beta. But making puppet confined is probably a waste of time anyways, since it pretty much needs to be able to do anything.

Quoted 4 lines · Daniel J Walsh

We usually go from permissive to unconfined when we try to spin off to beta. But making puppet confined is probably a waste of time anyways, since it pretty much needs to be able to do anything.

I disagree. Even powerful domains should be confined. I'd personally like to go even further and make sure that the policy is flexible enough to deal with limited use - for instance, if I use puppet only for ensuring mounts, then it should not be able to reload selinux policies (or transition to domains that can). Although we are definitely not there yet, I believe that we should at least first see how confining puppet goes.

Once a more complete policy is found, we can see if this can be segregated nicely.

Furthermore, the puppet policy itself has most of its "power" through domain transitions, not through elevated privileges on the puppet_t domain itself. Although remote command execution is still exploitable through this, making puppet SELinux-aware might help to reduce attacks there as well.

Wkr, Sven Vermeulen _______________________________________________ refpolicy mailing list refpolicy at oss.tresys.com
http://oss.tresys.com/mailman/listinfo/refpolicy

Quoted 23 lines · Sven Vermeulen

Quoted 4 lines · Daniel J Walsh

We usually go from permissive to unconfined when we try to spin off to beta. But making puppet confined is probably a waste of time anyways, since it pretty much needs to be able to do anything.

I disagree. Even powerful domains should be confined. I'd personally like to go even further and make sure that the policy is flexible enough to deal with limited use - for instance, if I use puppet only for ensuring mounts, then it should not be able to reload selinux policies (or transition to domains that can). Although we are definitely not there yet, I believe that we should at least first see how confining puppet goes.

Once a more complete policy is found, we can see if this can be segregated nicely.

Furthermore, the puppet policy itself has most of its "power" through domain transitions, not through elevated privileges on the puppet_t domain itself. Although remote command execution is still exploitable through this, making puppet SELinux-aware might help to reduce attacks there as well.

Quoted 4 lines

Wkr, Sven Vermeulen _______________________________________________ refpolicy mailing list refpolicy at oss.tresys.com
http://oss.tresys.com/mailman/listinfo/refpolicy

My point being that it is very difficult to make a policy for the masses that will work with a domain that can place files anywhere and even needs to be able to turn on and off SELinux. Setting booleans, file_context, policy modules, are all things that puppet does within the Fedora infrastructure.

_______________________________________________
refpolicy mailing list
refpolicy at oss.tresys.com
http://oss.tresys.com/mailman/listinfo/refpolicy

Quoted 32 lines · Daniel J Walsh

Quoted 25 lines · Sven Vermeulen

Quoted 4 lines · Daniel J Walsh

We usually go from permissive to unconfined when we try to spin off to beta. But making puppet confined is probably a waste of time anyways, since it pretty much needs to be able to do anything.

I disagree. Even powerful domains should be confined. I'd personally like to go even further and make sure that the policy is flexible enough to deal with limited use - for instance, if I use puppet only for ensuring mounts, then it should not be able to reload selinux policies (or transition to domains that can). Although we are definitely not there yet, I believe that we should at least first see how confining puppet goes.

Once a more complete policy is found, we can see if this can be segregated nicely.

Furthermore, the puppet policy itself has most of its "power" through domain transitions, not through elevated privileges on the puppet_t domain itself. Although remote command execution is still exploitable through this, making puppet SELinux-aware might help to reduce attacks there as well.

Quoted 4 lines

Wkr, Sven Vermeulen _______________________________________________ refpolicy mailing list refpolicy at oss.tresys.com
http://oss.tresys.com/mailman/listinfo/refpolicy

Quoted 5 lines

My point being that it is very difficult to make a policy for the masses that will work with a domain that can place files anywhere and even needs to be able to turn on and off SELinux. Setting booleans, file_context, policy modules, are all things that puppet does within the Fedora infrastructure.

We arent (at least i am not) saying these domain cannot be unconfined eventually. I am just saying it should be optional.

That means that during rawhide we make these unconfined domain, permissive domains and use the reports to perfect the policy for any scenario. then when rawhide gets branched we make it unconfined again so that "the masses? get an unconfined puppet. But if one decides to remove the unconfined domains , puppet will still work (atleast better than currently) because we kept perfecting policy during the rawhide.

Quoted 3 lines

_______________________________________________ refpolicy mailing list refpolicy at oss.tresys.com
http://oss.tresys.com/mailman/listinfo/refpolicy

_______________________________________________ refpolicy mailing list refpolicy at oss.tresys.com
http://oss.tresys.com/mailman/listinfo/refpolicy

Quoted 36 lines · Dominick Grift

Quoted 26 lines · Daniel J Walsh

Quoted 16 lines · Sven Vermeulen

Quoted 4 lines · Daniel J Walsh

We usually go from permissive to unconfined when we try to spin off to beta. But making puppet confined is probably a waste of time anyways, since it pretty much needs to be able to do anything.

I disagree. Even powerful domains should be confined. I'd personally like to go even further and make sure that the policy is flexible enough to deal with limited use - for instance, if I use puppet only for ensuring mounts, then it should not be able to reload selinux policies (or transition to domains that can). Although we are definitely not there yet, I believe that we should at least first see how confining puppet goes.

Quoted 9 lines

Once a more complete policy is found, we can see if this can be segregated nicely.

Furthermore, the puppet policy itself has most of its "power" through domain transitions, not through elevated privileges on the puppet_t domain itself. Although remote command execution is still exploitable through this, making puppet SELinux-aware might help to reduce attacks there as well.

Quoted 5 lines

My point being that it is very difficult to make a policy for the masses that will work with a domain that can place files anywhere and even needs to be able to turn on and off SELinux. Setting booleans, file_context, policy modules, are all things that puppet does within the Fedora infrastructure.

We arent (at least i am not) saying these domain cannot be unconfined eventually. I am just saying it should be optional.

Quoted 7 lines

That means that during rawhide we make these unconfined domain, permissive domains and use the reports to perfect the policy for any scenario. then when rawhide gets branched we make it unconfined again so that "the masses?? get an unconfined puppet. But if one decides to remove the unconfined domains , puppet will still work (atleast better than currently) because we kept perfecting policy during the rawhide.

We are in violent agreement.

Quoted 45 lines · Daniel J Walsh

Quoted 43 lines · Dominick Grift

Quoted 26 lines · Daniel J Walsh

Quoted 16 lines · Sven Vermeulen

Quoted 4 lines · Daniel J Walsh

We usually go from permissive to unconfined when we try to spin off to beta. But making puppet confined is probably a waste of time anyways, since it pretty much needs to be able to do anything.

I disagree. Even powerful domains should be confined. I'd personally like to go even further and make sure that the policy is flexible enough to deal with limited use - for instance, if I use puppet only for ensuring mounts, then it should not be able to reload selinux policies (or transition to domains that can). Although we are definitely not there yet, I believe that we should at least first see how confining puppet goes.

Quoted 9 lines

Once a more complete policy is found, we can see if this can be segregated nicely.

Furthermore, the puppet policy itself has most of its "power" through domain transitions, not through elevated privileges on the puppet_t domain itself. Although remote command execution is still exploitable through this, making puppet SELinux-aware might help to reduce attacks there as well.

Quoted 5 lines

My point being that it is very difficult to make a policy for the masses that will work with a domain that can place files anywhere and even needs to be able to turn on and off SELinux. Setting booleans, file_context, policy modules, are all things that puppet does within the Fedora infrastructure.

We arent (at least i am not) saying these domain cannot be unconfined eventually. I am just saying it should be optional.

That means that during rawhide we make these unconfined domain, permissive domains and use the reports to perfect the policy for any scenario. then when rawhide gets branched we make it unconfined again so that "the masses?? get an unconfined puppet. But if one decides to remove the unconfined domains , puppet will still work (atleast better than currently) because we kept perfecting policy during the rawhide.

Quoted 1 line

We are in violent agreement.

I think we should take a best effort approach to situations like this. Based on my (albeit limited) perspective of puppet usage, its for managing system config. So its primary features are managing config files and transitioning out to tighter domains, eg mount_t, etc) when possible, especially since its typically network facing. I'm comfortable with the policy supporting this level of access. Once you start (ab)using puppet to directly manage binaries, manage SELinux policy, relabel files, etc. you get to unconfined land, since you're imbuing puppet with a huge amount of trust and power.

Signature · 7 lines

Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com
_______________________________________________
refpolicy mailing list
refpolicy at oss.tresys.com
http://oss.tresys.com/mailman/listinfo/refpolicy

Quoted 63 lines · Christopher J. PeBenito

Quoted 49 lines · Daniel J Walsh

Quoted 39 lines · Dominick Grift

Quoted 27 lines · Daniel J Walsh

Quoted 19 lines · Sven Vermeulen

Quoted 4 lines · Daniel J Walsh

We usually go from permissive to unconfined when we try to spin off to beta. But making puppet confined is probably a waste of time anyways, since it pretty much needs to be able to do anything.

I disagree. Even powerful domains should be confined. I'd
personally like to go even further and make sure that
the policy is flexible enough to deal with limited use - for instance, if I use puppet only for ensuring mounts, then it should not be able to reload selinux policies (or transition to domains that can). Although we are definitely not there yet, I believe that we should at least first see how confining puppet goes.

Once a more complete policy is found, we can see if this can be segregated nicely.

Quoted 7 lines

Furthermore, the puppet policy itself has most of its "power" through domain transitions, not through elevated privileges on the puppet_t domain itself. Although remote command execution is still exploitable through this, making puppet SELinux-aware might help to reduce attacks there as well.

Quoted 6 lines

My point being that it is very difficult to make a policy for the masses that will work with a domain that can place files anywhere and even needs to be able to turn on and off SELinux. Setting booleans, file_context, policy modules, are all things that puppet does within the Fedora infrastructure.

We arent (at least i am not) saying these domain cannot be unconfined eventually. I am just saying it should be optional.

Quoted 8 lines

That means that during rawhide we make these unconfined domain, permissive domains and use the reports to perfect the policy for any scenario. then when rawhide gets branched we make it unconfined again so that "the masses?? get an unconfined puppet. But if one decides to remove the unconfined domains , puppet will still work (atleast better than currently) because we kept perfecting policy during the rawhide.

Quoted 1 line

We are in violent agreement.

I think we should take a best effort approach to situations like this. Based on my (albeit limited) perspective of puppet usage, its for managing system config. So its primary features are managing config files and transitioning out to tighter domains, eg mount_t, etc) when possible, especially since its typically network facing. I'm comfortable with the policy supporting this level of access. Once you start (ab)using puppet to directly manage binaries, manage SELinux policy, relabel files, etc. you get to unconfined land, since you're imbuing puppet with a huge amount of trust and power.

Quoted 4 lines

-- Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com _______________________________________________ refpolicy mailing list refpolicy at oss.tresys.com
http://oss.tresys.com/mailman/listinfo/refpolicy

Well, the way puppet should manage anything selinux related should be though packages I think. For instance, I have puppet set up to install selinux-nginx on gentoo. Then if I place a file via puppet it gets relabeled automatically via the file context.

-- Matthew Thode

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

Quoted 70 lines · Matt Thode

Quoted 63 lines · Christopher J. PeBenito

Quoted 49 lines · Daniel J Walsh

Quoted 39 lines · Dominick Grift

Quoted 27 lines · Daniel J Walsh

Quoted 19 lines · Sven Vermeulen

Quoted 4 lines · Daniel J Walsh

We usually go from permissive to unconfined when we try to spin off to beta. But making puppet confined is probably a waste of time anyways, since it pretty much needs to be able to do anything.

I disagree. Even powerful domains should be confined. I'd personally like to go even further and make sure that the policy is flexible enough to deal with limited use - for instance, if I use puppet only for ensuring mounts, then it should not be able to reload selinux policies (or transition to domains that can). Although we are definitely not there yet, I believe that we should at least first see how confining puppet goes.

Once a more complete policy is found, we can see if this can be segregated nicely.

Quoted 7 lines

Furthermore, the puppet policy itself has most of its "power" through domain transitions, not through elevated privileges on the puppet_t domain itself. Although remote command execution is still exploitable through this, making puppet SELinux-aware might help to reduce attacks there as well.

Quoted 6 lines

My point being that it is very difficult to make a policy for the masses that will work with a domain that can place files anywhere and even needs to be able to turn on and off SELinux. Setting booleans, file_context, policy modules, are all things that puppet does within the Fedora infrastructure.

We arent (at least i am not) saying these domain cannot be unconfined eventually. I am just saying it should be optional.

Quoted 8 lines

That means that during rawhide we make these unconfined domain, permissive domains and use the reports to perfect the policy for any scenario. then when rawhide gets branched we make it unconfined again so that "the masses?? get an unconfined puppet. But if one decides to remove the unconfined domains , puppet will still work (atleast better than currently) because we kept perfecting policy during the rawhide.

Quoted 1 line

We are in violent agreement.

I think we should take a best effort approach to situations like this. Based on my (albeit limited) perspective of puppet usage, its for managing system config. So its primary features are managing config files and transitioning out to tighter domains, eg mount_t, etc) when possible, especially since its typically network facing. I'm comfortable with the policy supporting this level of access. Once you start (ab)using puppet to directly manage binaries, manage SELinux policy, relabel files, etc. you get to unconfined land, since you're imbuing puppet with a huge amount of trust and power.

Quoted 4 lines

-- Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com _______________________________________________ refpolicy mailing list refpolicy at oss.tresys.com
http://oss.tresys.com/mailman/listinfo/refpolicy

Quoted 6 lines

Well, the way puppet should manage anything selinux related should be though packages I think. For instance, I have puppet set up to install selinux-nginx on gentoo. Then if I place a file via puppet it gets relabeled automatically via the file context.

-- Matthew Thode

What about boolean settings, what about policy modifications?

The main point is admins are going to need to administrate their systems with puppet, and they are going to do what needs to get done. Usually this is going to move towards and unconfined domain, especially for general purpose OS. One problem with adding lots of transitions and allows to a puppet domain, is that it makes making a truly confined an controlled puppet_t very difficult. For example if all I want to do is allow puppet_t to manage my apache content, and we add lots of transitions to things line mount_t we can not get a limited prived puppet_t.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6ByKsACgkQrlYvE4MpobNwVgCfUk3gn+fEKp/4MGcuUxsUp51m /MsAnAh57u/56aguL7Ex688jWRy73o1f
=nfDx
-----END PGP SIGNATURE-----

Quoted 64 lines · Matt Thode

Quoted 63 lines · Christopher J. PeBenito

Quoted 49 lines · Daniel J Walsh

Quoted 39 lines · Dominick Grift

Quoted 27 lines · Daniel J Walsh

Quoted 19 lines · Sven Vermeulen

Quoted 4 lines · Daniel J Walsh

We usually go from permissive to unconfined when we try to spin off to beta. But making puppet confined is probably a waste of time anyways, since it pretty much needs to be able to do anything.

I disagree. Even powerful domains should be confined. I'd
personally like to go even further and make sure that
the policy is flexible enough to deal with limited use - for instance, if I use puppet only for ensuring mounts, then it should not be able to reload selinux policies (or transition to domains that can). Although we are definitely not there yet, I believe that we should at least first see how confining puppet goes.

Once a more complete policy is found, we can see if this can be segregated nicely.

Quoted 7 lines

Furthermore, the puppet policy itself has most of its "power" through domain transitions, not through elevated privileges on the puppet_t domain itself. Although remote command execution is still exploitable through this, making puppet SELinux-aware might help to reduce attacks there as well.

Quoted 6 lines

My point being that it is very difficult to make a policy for the masses that will work with a domain that can place files anywhere and even needs to be able to turn on and off SELinux. Setting booleans, file_context, policy modules, are all things that puppet does within the Fedora infrastructure.

We arent (at least i am not) saying these domain cannot be unconfined eventually. I am just saying it should be optional.

Quoted 8 lines

That means that during rawhide we make these unconfined domain, permissive domains and use the reports to perfect the policy for any scenario. then when rawhide gets branched we make it unconfined again so that "the masses?? get an unconfined puppet. But if one decides to remove the unconfined domains , puppet will still work (atleast better than currently) because we kept perfecting policy during the rawhide.

Quoted 1 line

We are in violent agreement.

I think we should take a best effort approach to situations like this. Based on my (albeit limited) perspective of puppet usage, its for managing system config. So its primary features are managing config files and transitioning out to tighter domains, eg mount_t, etc) when possible, especially since its typically network facing. I'm comfortable with the policy supporting this level of access. Once you start (ab)using puppet to directly manage binaries, manage SELinux policy, relabel files, etc. you get to unconfined land, since you're imbuing puppet with a huge amount of trust and power.

Quoted 4 lines

Well, the way puppet should manage anything selinux related should be though packages I think. For instance, I have puppet set up to install selinux-nginx on gentoo. Then if I place a file via puppet it gets relabeled automatically via the file context.

What about boolean settings, what about policy modifications?

The main point is admins are going to need to administrate their systems with puppet, and they are going to do what needs to get done.
Usually this is going to move towards and unconfined domain,
especially for general purpose OS. One problem with adding lots of transitions and allows to a puppet domain, is that it makes making a truly confined an controlled puppet_t very difficult. For example if all I want to do is allow puppet_t to manage my apache content, and we add lots of transitions to things line mount_t we can not get a limited prived puppet_t.

Quoted 66 lines · Daniel J Walsh

Quoted 65 lines · Matt Thode

Quoted 64 lines · Christopher J. PeBenito

Quoted 50 lines · Daniel J Walsh

Quoted 40 lines · Dominick Grift

Quoted 28 lines · Daniel J Walsh

Quoted 20 lines · Sven Vermeulen

Quoted 4 lines · Daniel J Walsh

We usually go from permissive to unconfined when we try to spin off to beta. But making puppet confined is probably a waste of time anyways, since it pretty much needs to be able to do anything.

I disagree. Even powerful domains should be confined. I'd personally like to go even further and make sure that the policy is flexible enough to deal with limited use - for instance, if I use puppet only for ensuring mounts, then it should not be able to reload selinux policies (or transition to domains that can). Although we are definitely not there yet, I believe that we should at least first see how confining puppet goes.

Once a more complete policy is found, we can see if this can be segregated nicely.

Quoted 7 lines

Furthermore, the puppet policy itself has most of its "power" through domain transitions, not through elevated privileges on the puppet_t domain itself. Although remote command execution is still exploitable through this, making puppet SELinux-aware might help to reduce attacks there as well.

Quoted 6 lines

My point being that it is very difficult to make a policy for the masses that will work with a domain that can place files anywhere and even needs to be able to turn on and off SELinux. Setting booleans, file_context, policy modules, are all things that puppet does within the Fedora infrastructure.

We arent (at least i am not) saying these domain cannot be unconfined eventually. I am just saying it should be optional.

Quoted 8 lines

That means that during rawhide we make these unconfined domain, permissive domains and use the reports to perfect the policy for any scenario. then when rawhide gets branched we make it unconfined again so that "the masses?? get an unconfined puppet. But if one decides to remove the unconfined domains , puppet will still work (atleast better than currently) because we kept perfecting policy during the rawhide.

Quoted 1 line

We are in violent agreement.

I think we should take a best effort approach to situations like this. Based on my (albeit limited) perspective of puppet usage, its for managing system config. So its primary features are managing config files and transitioning out to tighter domains, eg mount_t, etc) when possible, especially since its typically network facing. I'm comfortable with the policy supporting this level of access. Once you start (ab)using puppet to directly manage binaries, manage SELinux policy, relabel files, etc. you get to unconfined land, since you're imbuing puppet with a huge amount of trust and power.

Quoted 5 lines

Quoted 5 lines

Well, the way puppet should manage anything selinux related should be though packages I think. For instance, I have puppet set up to install selinux-nginx on gentoo. Then if I place a file via puppet it gets relabeled automatically via the file context.

I assume either it is installed correctly with setfscreatecon() or you run restorecon on it?

Quoted 1 line

What about boolean settings, what about policy modifications?

I'd be fine with puppet directly altering booleans via libselinux calls. Policy modifications should go through semodule/semanage.

Quoted 9 lines

The main point is admins are going to need to administrate their systems with puppet, and they are going to do what needs to get done. Usually this is going to move towards and unconfined domain, especially for general purpose OS. One problem with adding lots of transitions and allows to a puppet domain, is that it makes making a truly confined an controlled puppet_t very difficult. For example if all I want to do is allow puppet_t to manage my apache content, and we add lots of transitions to things line mount_t we can not get a limited prived puppet_t.

I don't understand how your example demonstrates a problem with this approach. To me, it seems like we agree. People who want a nice confined system aren't going to have unconfined anyway, so the non-unconfined case need to have a reasonable use case. For the more general case, people will have the unconfined module, and puppet will be unconfined.

Quoted 12 lines · Christopher J. PeBenito

Quoted 9 lines · Daniel J Walsh

The main point is admins are going to need to administrate their systems with puppet, and they are going to do what needs to get done. Usually this is going to move towards and unconfined domain, especially for general purpose OS. One problem with adding lots of transitions and allows to a puppet domain, is that it makes making a truly confined an controlled puppet_t very difficult. For example if all I want to do is allow puppet_t to manage my apache content, and we add lots of transitions to things line mount_t we can not get a limited prived puppet_t.

Quoted 6 lines

I don't understand how your example demonstrates a problem with this approach. To me, it seems like we agree. People who want a nice confined system aren't going to have unconfined anyway, so the non-unconfined case need to have a reasonable use case. For the more general case, people will have the unconfined module, and puppet will be unconfined.

I guess I am arguing not to add functionality to much functionality to puppet, so we have a tightly secured puppet, and then allow people who care about confining it to extend it. Otherwise we will end up with a puppet policy that is somewhere in the middle, which does neither group any good.

For example, if you allow puppet to transition to useradd_t, mount_t, and the ability to write to security_t, then I can not write a more confined policy for my puppet from the reference policy.

I guess I would opt for Minimal puppet_t enough to let the service run and listen on the puppet port. Maybe allow it to read system files.

And an unconfined_domain(puppet_t), for those of us who have no idea what puppet will do.

Quoted 91 lines · Christopher J. PeBenito

Quoted 66 lines · Daniel J Walsh

Quoted 65 lines · Matt Thode

Quoted 64 lines · Christopher J. PeBenito

Quoted 50 lines · Daniel J Walsh

Quoted 40 lines · Dominick Grift

Quoted 28 lines · Daniel J Walsh

Quoted 20 lines · Sven Vermeulen

Quoted 4 lines · Daniel J Walsh

We usually go from permissive to unconfined when we try to spin off to beta. But making puppet confined is probably a waste of time anyways, since it pretty much needs to be able to do anything.

I disagree. Even powerful domains should be confined. I'd personally like to go even further and make sure that the policy is flexible enough to deal with limited use - for instance, if I use puppet only for ensuring mounts, then it should not be able to reload selinux policies (or transition to domains that can). Although we are definitely not there yet, I believe that we should at least first see how confining puppet goes.

Once a more complete policy is found, we can see if this can be segregated nicely.

Quoted 7 lines

Furthermore, the puppet policy itself has most of its "power" through domain transitions, not through elevated privileges on the puppet_t domain itself. Although remote command execution is still exploitable through this, making puppet SELinux-aware might help to reduce attacks there as well.

Quoted 6 lines

My point being that it is very difficult to make a policy for the masses that will work with a domain that can place files anywhere and even needs to be able to turn on and off SELinux. Setting booleans, file_context, policy modules, are all things that puppet does within the Fedora infrastructure.

We arent (at least i am not) saying these domain cannot be unconfined eventually. I am just saying it should be optional.

Quoted 8 lines

That means that during rawhide we make these unconfined domain, permissive domains and use the reports to perfect the policy for any scenario. then when rawhide gets branched we make it unconfined again so that "the masses?? get an unconfined puppet. But if one decides to remove the unconfined domains , puppet will still work (atleast better than currently) because we kept perfecting policy during the rawhide.

Quoted 1 line

We are in violent agreement.

I think we should take a best effort approach to situations like this. Based on my (albeit limited) perspective of puppet usage, its for managing system config. So its primary features are managing config files and transitioning out to tighter domains, eg mount_t, etc) when possible, especially since its typically network facing. I'm comfortable with the policy supporting this level of access. Once you start (ab)using puppet to directly manage binaries, manage SELinux policy, relabel files, etc. you get to unconfined land, since you're imbuing puppet with a huge amount of trust and power.

Quoted 5 lines

Quoted 5 lines

Well, the way puppet should manage anything selinux related should be though packages I think. For instance, I have puppet set up to install selinux-nginx on gentoo. Then if I place a file via puppet it gets relabeled automatically via the file context.

I assume either it is installed correctly with setfscreatecon() or you run restorecon on it?

Quoted 1 line

What about boolean settings, what about policy modifications?

I'd be fine with puppet directly altering booleans via libselinux calls. Policy modifications should go through semodule/semanage.

Quoted 9 lines

The main point is admins are going to need to administrate their systems with puppet, and they are going to do what needs to get done. Usually this is going to move towards and unconfined domain, especially for general purpose OS. One problem with adding lots of transitions and allows to a puppet domain, is that it makes making a truly confined an controlled puppet_t very difficult. For example if all I want to do is allow puppet_t to manage my apache content, and we add lots of transitions to things line mount_t we can not get a limited prived puppet_t.

Quoted 7 lines

I don't understand how your example demonstrates a problem with this approach. To me, it seems like we agree. People who want a nice confined system aren't going to have unconfined anyway, so the non-unconfined case need to have a reasonable use case. For the more general case, people will have the unconfined module, and puppet will be unconfined.

I guess I am arguing not to add functionality to much functionality to puppet, so we have a tightly secured puppet, and then allow people who care about confining it to extend it. Otherwise we will end up with a puppet policy that is somewhere in the middle, which does neither group any good.

For example, if you allow puppet to transition to useradd_t, mount_t, and the ability to write to security_t, then I can not write a more confined policy for my puppet from the reference policy.

I guess I would opt for Minimal puppet_t enough to let the service run and listen on the puppet port. Maybe allow it to read system files.

And an unconfined_domain(puppet_t), for those of us who have no idea what puppet will do.

_______________________________________________
refpolicy mailing list
refpolicy at oss.tresys.com
http://oss.tresys.com/mailman/listinfo/refpolicy

Quoted 116 lines · Daniel J Walsh

Quoted 102 lines · Christopher J. PeBenito

Quoted 74 lines · Daniel J Walsh

Quoted 73 lines · Matt Thode

Quoted 71 lines · Christopher J. PeBenito

Quoted 55 lines · Daniel J Walsh

Quoted 44 lines · Dominick Grift

Quoted 31 lines · Daniel J Walsh

Quoted 22 lines · Sven Vermeulen

Quoted 5 lines · Daniel J Walsh

We usually go from permissive to unconfined when we try to spin off to beta. But making puppet confined is probably a waste of time anyways, since it pretty much needs to be able to do anything.

I disagree. Even powerful domains should be confined. I'd personally like to go even further and make sure that the policy is flexible enough to deal with limited use - for instance, if I use puppet only for ensuring mounts, then it should not be able to reload selinux policies (or transition to domains that can). Although we are definitely not there yet, I believe that we should at least first see how confining puppet goes.

Once a more complete policy is found, we can see if this can be segregated nicely.

Quoted 8 lines

Furthermore, the puppet policy itself has most of its "power" through domain transitions, not through elevated privileges on the puppet_t domain itself. Although remote command execution is still exploitable through this, making puppet SELinux-aware might help to reduce attacks there as well.

Quoted 6 lines

My point being that it is very difficult to make a policy for the masses that will work with a domain that can place files anywhere and even needs to be able to turn on and off SELinux. Setting booleans, file_context, policy modules, are all things that puppet does within the Fedora infrastructure.

We arent (at least i am not) saying these domain cannot be unconfined eventually. I am just saying it should be optional.

Quoted 9 lines

That means that during rawhide we make these unconfined domain, permissive domains and use the reports to perfect the policy for any scenario. then when rawhide gets branched we make it unconfined again so that "the masses?? get an unconfined puppet. But if one decides to remove the unconfined domains , puppet will still work (atleast better than currently) because we kept perfecting policy during the rawhide.

Quoted 1 line

We are in violent agreement.

I think we should take a best effort approach to situations like this. Based on my (albeit limited) perspective of puppet usage, its for managing system config. So its primary features are managing config files and transitioning out to tighter domains, eg mount_t, etc) when possible, especially since its typically network facing. I'm comfortable with the policy supporting this level of access. Once you start (ab)using puppet to directly manage binaries, manage SELinux policy, relabel files, etc. you get to unconfined land, since you're imbuing puppet with a huge amount of trust and power.

Quoted 5 lines

Quoted 5 lines

Well, the way puppet should manage anything selinux related should be though packages I think. For instance, I have puppet set up to install selinux-nginx on gentoo. Then if I place a file via puppet it gets relabeled automatically via the file context.

I assume either it is installed correctly with setfscreatecon() or you run restorecon on it?

Quoted 2 lines

What about boolean settings, what about policy
modifications?

I'd be fine with puppet directly altering booleans via libselinux calls. Policy modifications should go through semodule/semanage.

Quoted 10 lines

The main point is admins are going to need to administrate their systems with puppet, and they are going to do what needs to get done. Usually this is going to move towards and unconfined domain, especially for general purpose OS. One problem with adding lots of transitions and allows to a puppet domain, is that it makes making a truly confined an controlled puppet_t very difficult. For example if all I want to do is allow puppet_t to manage my apache content, and we add lots of transitions to things line mount_t we can not get a limited prived puppet_t.

Quoted 7 lines

I don't understand how your example demonstrates a problem with this approach. To me, it seems like we agree. People who want a nice confined system aren't going to have unconfined anyway, so the non-unconfined case need to have a reasonable use case. For the more general case, people will have the unconfined module, and puppet will be unconfined.

I guess I am arguing not to add functionality to much functionality to puppet, so we have a tightly secured puppet, and then allow people who care about confining it to extend it. Otherwise we will end up with a puppet policy that is somewhere in the middle, which does neither group any good.

Quoted 4 lines

For example, if you allow puppet to transition to useradd_t, mount_t, and the ability to write to security_t, then I can not write a more confined policy for my puppet from the reference policy.

that was maybe the case in the past. nowadays one can just disable a module like puppet and clone it from source, then modify and load the clone (at least if all goes well)

Quoted 7 lines

I guess I would opt for Minimal puppet_t enough to let the service run and listen on the puppet port. Maybe allow it to read system files.

And an unconfined_domain(puppet_t), for those of us who have no idea what puppet will do.

I think the emphasis is often much on restriction rather than integrity. No policy is ever perfect but should that keep us from trying?

instead of looking what it can or should do one can also look at what it cant or should not do.

sure puppet might be used for many things but there are also things where it is not used for, and i think the focus could be on that more.

Yes it would be a very permissive domain ( but like SwifT said we could later make functionality tunable ) but that is the nature of this program.

I guess the question comes down to this;

1. Do we expect people that use puppet for the more exotic configurations and want to run selinux policy "strict" to modify puppet policy themselves.

2. Or do we expect people that want a puppet policy tailored to their specific requirements and want to run selinux policy "strict" to modify policy themselves.

I think i would go for "2." since no policy is ever perfect.

Besides the policy in fedora is typically general purpose in many cases, so supporting a general purpose puppet domain would fit that profile.

It is easy to say "the buck stops here" but we the community as a whole can create a better policy than any single entity alone i believe. So why not take advantage of that: yes it can do a lot of things that not everyone may use, but on the brighter side; it also can't do a lot of things that it should not do. Isnt that what its about in the end?

Quoted 3 lines

_______________________________________________ refpolicy mailing list refpolicy at oss.tresys.com
http://oss.tresys.com/mailman/listinfo/refpolicy

_______________________________________________ refpolicy mailing list refpolicy at oss.tresys.com
http://oss.tresys.com/mailman/listinfo/refpolicy

Quoted 4 lines

Quoted 4 lines

Well, the way puppet should manage anything selinux related should be though packages I think. For instance, I have puppet set up to install selinux-nginx on gentoo. Then if I place a file via puppet it gets relabeled automatically via the file context.

I assume either it is installed correctly with setfscreatecon() or you run restorecon on it?

Quoted 8 lines · Christopher J. PeBenito

Quoted 5 lines

Quoted 5 lines

Well, the way puppet should manage anything selinux related should be though packages I think. For instance, I have puppet set up to install selinux-nginx on gentoo. Then if I place a file via puppet it gets relabeled automatically via the file context.

I assume either it is installed correctly with setfscreatecon() or you run restorecon on it?

Puppet is SELinux-aware (at least it is build with libselinux.so references) so I guess it is the former.

Wkr, Sven Vermeulen

_______________________________________________ refpolicy mailing list refpolicy at oss.tresys.com
http://oss.tresys.com/mailman/listinfo/refpolicy