[refpolicy] [PATCH 1/1] Mount output should be writeable to puppet_tmp_t

[refpolicy] [PATCH 1/1] Mount output should be writeable to puppet_tmp_t

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

Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
---
 policy/modules/system/mount.te |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/policy/modules/system/mount.te 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)
-- 
1.7.3.4

[refpolicy] [PATCH 1/1] Mount output should be writeable to puppet_tmp_t

[Dominick Grift]

On Sat, 2011-09-24 at 15:56 +0200, Sven Vermeulen wrote:
> 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.

> Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
> ---
>  policy/modules/system/mount.te |    4 ++++
>  1 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/policy/modules/system/mount.te 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)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110924/65393f50/attachment.bin 

[refpolicy] [PATCH 1/1] Mount output should be writeable to puppet_tmp_t

[Dominick Grift]

On Sat, 2011-09-24 at 17:18 +0200, Dominick Grift wrote:
> On Sat, 2011-09-24 at 15:56 +0200, Sven Vermeulen wrote:
> > 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.

> > Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
> > ---
> >  policy/modules/system/mount.te |    4 ++++
> >  1 files changed, 4 insertions(+), 0 deletions(-)
> > 
> > diff --git a/policy/modules/system/mount.te 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)
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110924/3184038a/attachment-0001.bin 

[refpolicy] [PATCH 1/1] Mount output should be writeable to puppet_tmp_t

[Daniel J Walsh]

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

On 09/24/2011 11:22 AM, Dominick Grift wrote:
> On Sat, 2011-09-24 at 17:18 +0200, Dominick Grift wrote:
>> On Sat, 2011-09-24 at 15:56 +0200, Sven Vermeulen wrote:
>>> 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.
> 
>>> Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be> --- 
>>> policy/modules/system/mount.te |    4 ++++ 1 files changed, 4 
>>> insertions(+), 0 deletions(-)
>>> 
>>> diff --git a/policy/modules/system/mount.te 
>>> 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6AelcACgkQrlYvE4MpobOFxgCgiIRTIsTF1kNkllm2D2/Po99O
LqQAoL3xMud++w5zys4HzoIIk6954pfs
=dJax
-----END PGP SIGNATURE-----

[refpolicy] [PATCH 1/1] Mount output should be writeable to puppet_tmp_t

[Sven Vermeulen]

On Mon, Sep 26, 2011 at 09:12:59AM -0400, Daniel J Walsh wrote:
> 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] [PATCH 1/1] Mount output should be writeable to puppet_tmp_t

[Daniel J Walsh]

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

On 09/26/2011 10:22 AM, Sven Vermeulen wrote:
> On Mon, Sep 26, 2011 at 09:12:59AM -0400, Daniel J Walsh wrote:
>> 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


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.

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

iEYEARECAAYFAk6Ak+YACgkQrlYvE4MpobOszACfVcthPTlPfWNSnBbr8+WrGGl+
GtwAoKFWCCkKqoesAKbnEePLpLfiwgu2
=iJ49
-----END PGP SIGNATURE-----

[refpolicy] [PATCH 1/1] Mount output should be writeable to puppet_tmp_t

[Dominick Grift]

On Mon, 2011-09-26 at 11:01 -0400, Daniel J Walsh wrote:
> On 09/26/2011 10:22 AM, Sven Vermeulen wrote:
> > On Mon, Sep 26, 2011 at 09:12:59AM -0400, Daniel J Walsh wrote:
> >> 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
> 
> 
> 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.


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

[refpolicy] [PATCH 1/1] Mount output should be writeable to puppet_tmp_t

[Daniel J Walsh]

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

On 09/26/2011 11:11 AM, Dominick Grift wrote:
> On Mon, 2011-09-26 at 11:01 -0400, Daniel J Walsh wrote:
>> On 09/26/2011 10:22 AM, Sven Vermeulen wrote:
>>> On Mon, Sep 26, 2011 at 09:12:59AM -0400, Daniel J Walsh
>>> wrote:
>>>> 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
>> 
>> 
>> 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.
> 
> 
>> _______________________________________________ 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


We are in violent agreement.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6AnRYACgkQrlYvE4MpobMpSgCgqaf3wMdU0417M/+Zz07iBShN
w1QAoJljNjlJKLTBm+BNU6V4DuGktUgM
=jJRP
-----END PGP SIGNATURE-----

[refpolicy] [PATCH 1/1] Mount output should be writeable to puppet_tmp_t

[Christopher J. PeBenito]

On 09/26/11 11:41, Daniel J Walsh wrote:
> On 09/26/2011 11:11 AM, Dominick Grift wrote:
>> On Mon, 2011-09-26 at 11:01 -0400, Daniel J Walsh wrote:
>>> On 09/26/2011 10:22 AM, Sven Vermeulen wrote:
>>>> On Mon, Sep 26, 2011 at 09:12:59AM -0400, Daniel J Walsh
>>>> wrote:
>>>>> 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.
>>>>
>>> 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.
> 
> 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.

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

[refpolicy] [PATCH 1/1] Mount output should be writeable to puppet_tmp_t

[Matt Thode]

On Sep 26, 2011, at 1:31 PM, Christopher J. PeBenito wrote:
> On 09/26/11 11:41, Daniel J Walsh wrote:
>> On 09/26/2011 11:11 AM, Dominick Grift wrote:
>>> On Mon, 2011-09-26 at 11:01 -0400, Daniel J Walsh wrote:
>>>> On 09/26/2011 10:22 AM, Sven Vermeulen wrote:
>>>>> On Mon, Sep 26, 2011 at 09:12:59AM -0400, Daniel J Walsh
>>>>> wrote:
>>>>>> 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.
>>>>> 
>>>> 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.
>> 
>> 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.
> 
> -- 
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 881 bytes
Desc: This is a digitally signed message part
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110926/5b4f946e/attachment.bin 

[refpolicy] [PATCH 1/1] Mount output should be writeable to puppet_tmp_t

[Daniel J Walsh]

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

On 09/26/2011 03:36 PM, Matt Thode wrote:
> On Sep 26, 2011, at 1:31 PM, Christopher J. PeBenito wrote:
>> On 09/26/11 11:41, Daniel J Walsh wrote:
>>> On 09/26/2011 11:11 AM, Dominick Grift wrote:
>>>> On Mon, 2011-09-26 at 11:01 -0400, Daniel J Walsh wrote:
>>>>> On 09/26/2011 10:22 AM, Sven Vermeulen wrote:
>>>>>> On Mon, Sep 26, 2011 at 09:12:59AM -0400, Daniel J Walsh 
>>>>>> wrote:
>>>>>>> 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.
>>>>>> 
>>>>> 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.
>>> 
>>> 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.
>> 
>> -- 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


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

[refpolicy] [PATCH 1/1] Mount output should be writeable to puppet_tmp_t

[Matt Thode]

On Sep 27, 2011, at 7:59 AM, Daniel J Walsh wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 09/26/2011 03:36 PM, Matt Thode wrote:
>> On Sep 26, 2011, at 1:31 PM, Christopher J. PeBenito wrote:
>>> On 09/26/11 11:41, Daniel J Walsh wrote:
>>>> On 09/26/2011 11:11 AM, Dominick Grift wrote:
>>>>> On Mon, 2011-09-26 at 11:01 -0400, Daniel J Walsh wrote:
>>>>>> On 09/26/2011 10:22 AM, Sven Vermeulen wrote:
>>>>>>> On Mon, Sep 26, 2011 at 09:12:59AM -0400, Daniel J Walsh 
>>>>>>> wrote:
>>>>>>>> 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.
>>>>>>> 
>>>>>> 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.
>>>> 
>>>> 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.
>>> 
>>> -- 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
> 
> 
> 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-----


It is true that puppet would need special permissions to modify bools, can this be
done on policy installation?
I am trying to find a way so that puppet does not need to manage selinux
directly, but through package managers instead.

-- Matthew Thode
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 881 bytes
Desc: This is a digitally signed message part
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110927/c40c4a49/attachment.bin 

[refpolicy] [PATCH 1/1] Mount output should be writeable to puppet_tmp_t

[Christopher J. PeBenito]

On 09/27/11 08:59, Daniel J Walsh wrote:
> On 09/26/2011 03:36 PM, Matt Thode wrote:
>> On Sep 26, 2011, at 1:31 PM, Christopher J. PeBenito wrote:
>>> On 09/26/11 11:41, Daniel J Walsh wrote:
>>>> On 09/26/2011 11:11 AM, Dominick Grift wrote:
>>>>> On Mon, 2011-09-26 at 11:01 -0400, Daniel J Walsh wrote:
>>>>>> On 09/26/2011 10:22 AM, Sven Vermeulen wrote:
>>>>>>> On Mon, Sep 26, 2011 at 09:12:59AM -0400, Daniel J Walsh 
>>>>>>> wrote:
>>>>>>>> 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.
>>>>>>>
>>>>>> 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.
>>>>
>>>> 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.
>>>
>> 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?

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

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

[refpolicy] [PATCH 1/1] Mount output should be writeable to puppet_tmp_t

[Daniel J Walsh]

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

On 09/27/2011 09:29 AM, Christopher J. PeBenito wrote:
> On 09/27/11 08:59, Daniel J Walsh wrote:
>> On 09/26/2011 03:36 PM, Matt Thode wrote:
>>> On Sep 26, 2011, at 1:31 PM, Christopher J. PeBenito wrote:
>>>> On 09/26/11 11:41, Daniel J Walsh wrote:
>>>>> On 09/26/2011 11:11 AM, Dominick Grift wrote:
>>>>>> On Mon, 2011-09-26 at 11:01 -0400, Daniel J Walsh wrote:
>>>>>>> On 09/26/2011 10:22 AM, Sven Vermeulen wrote:
>>>>>>>> On Mon, Sep 26, 2011 at 09:12:59AM -0400, Daniel J
>>>>>>>> Walsh wrote:
>>>>>>>>> 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.
>>>>>>>> 
>>>>>>> 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.
>>>>> 
>>>>> 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.
>>>> 
>>> 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?
> 
>> 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.
> 
>> 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.
> 
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.


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

iEYEARECAAYFAk6B5KUACgkQrlYvE4MpobMDLgCfWJv4vdN8wbT/9lzahnhsLdbK
/14An2JvagdqMSdu+LdLiiIxKeFNnlKn
=m3j4
-----END PGP SIGNATURE-----

[refpolicy] [PATCH 1/1] Mount output should be writeable to puppet_tmp_t

[Christopher J. PeBenito]

On 09/27/11 10:58, Daniel J Walsh wrote:
> On 09/27/2011 09:29 AM, Christopher J. PeBenito wrote:
>> On 09/27/11 08:59, Daniel J Walsh wrote:

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

So what needs to be decided is where to draw the line.  I think we should look to something reasonable inside the base functionality.  The problem is that puppet's base support is already pretty broad.  I think the minimum we want is:

* edit etc_t files
* tunable: edit all config files

some other reasonable ones are:
* tunable: start & stop services
* tunable: toggle SELinux Booleans
* tunable: manage users & groups
* tunable: manage packages (eg run yum/rpm, etc.)

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

[refpolicy] [PATCH 1/1] Mount output should be writeable to puppet_tmp_t

[Dominick Grift]

On Tue, 2011-09-27 at 10:58 -0400, Daniel J Walsh wrote:
> On 09/27/2011 09:29 AM, Christopher J. PeBenito wrote:
> > On 09/27/11 08:59, Daniel J Walsh wrote:
> >> On 09/26/2011 03:36 PM, Matt Thode wrote:
> >>> On Sep 26, 2011, at 1:31 PM, Christopher J. PeBenito wrote:
> >>>> On 09/26/11 11:41, Daniel J Walsh wrote:
> >>>>> On 09/26/2011 11:11 AM, Dominick Grift wrote:
> >>>>>> On Mon, 2011-09-26 at 11:01 -0400, Daniel J Walsh wrote:
> >>>>>>> On 09/26/2011 10:22 AM, Sven Vermeulen wrote:
> >>>>>>>> On Mon, Sep 26, 2011 at 09:12:59AM -0400, Daniel J
> >>>>>>>> Walsh wrote:
> >>>>>>>>> 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.
> >>>>>>>> 
> >>>>>>> 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.
> >>>>> 
> >>>>> 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.
> >>>> 
> >>> 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?
> > 
> >> 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.
> > 
> >> 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.
> > 
> 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.

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)

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110927/9111cc81/attachment.bin 

[refpolicy] [PATCH 1/1] Mount output should be writeable to puppet_tmp_t

[Daniel J Walsh]

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

On 09/27/2011 12:37 PM, Dominick Grift wrote:
> On Tue, 2011-09-27 at 10:58 -0400, Daniel J Walsh wrote:
>> On 09/27/2011 09:29 AM, Christopher J. PeBenito wrote:
>>> On 09/27/11 08:59, Daniel J Walsh wrote:
>>>> On 09/26/2011 03:36 PM, Matt Thode wrote:
>>>>> On Sep 26, 2011, at 1:31 PM, Christopher J. PeBenito
>>>>> wrote:
>>>>>> On 09/26/11 11:41, Daniel J Walsh wrote:
>>>>>>> On 09/26/2011 11:11 AM, Dominick Grift wrote:
>>>>>>>> On Mon, 2011-09-26 at 11:01 -0400, Daniel J Walsh
>>>>>>>> wrote:
>>>>>>>>> On 09/26/2011 10:22 AM, Sven Vermeulen wrote:
>>>>>>>>>> On Mon, Sep 26, 2011 at 09:12:59AM -0400, Daniel
>>>>>>>>>> J Walsh wrote:
>>>>>>>>>>> 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.
>>>>>>>>>> 
>>>>>>>>> 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.
>>>>>>> 
>>>>>>> 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.
>>>>>> 
>>>>> 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?
>>> 
>>>> 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.
>>> 
>>>> 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.
>>> 
>> 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.
> 
> 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)
> 
>> 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?
>> _______________________________________________ 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

Fine I was arguing what I thought Chris would want for his people who
do full lock down.  Allowing puppet common configuration issues is fine.


You might need to allow puppet to change the labels if you are going
to allow it to manipulate etc_t.  relabelfrom puppet file types.
Relabelto types that puppet is allowed to manage.  Since puppet might
first create its content in /run or /tmp.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6CELIACgkQrlYvE4MpobNbfACg1jJRTjfYfYMNh7/u+S6FwYAT
cWwAmgMi4bkZhfhxOAdV48krEYHgYv0a
=dKj7
-----END PGP SIGNATURE-----

[refpolicy] [PATCH 1/1] Mount output should be writeable to puppet_tmp_t

[Sven Vermeulen]

On Tue, Sep 27, 2011 at 09:29:58AM -0400, Christopher J. PeBenito wrote:
> >> 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] [PATCH 1/1] Mount output should be writeable to puppet_tmp_t

[Daniel J Walsh]

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

On 09/27/2011 12:40 PM, Sven Vermeulen wrote:
> On Tue, Sep 27, 2011 at 09:29:58AM -0400, Christopher J. PeBenito
> wrote:
>>>> 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
Yes puppet was made Somewhat SELinux aware. It can do most of the
stuff you would expect with libselinux, but not the stuff that
libsemanage does.

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

iEYEARECAAYFAk6CD/EACgkQrlYvE4MpobMGWACeOoUre+aA8drmZoP4qgNA5s9H
W3AAoIxL8VMIpB/fV3jcCtQMsx/jo0Xf
=jsKB
-----END PGP SIGNATURE-----