The attached patch contains policy for Puppet, a configuration management tool. It contains two new services, for the client and server components of Puppet, and adds a new network port type for Puppet's use.
If any changes are desired please let me know and I will provide updated patches as my schedule permits.
Craig
--
Craig Grube
Sparta, Inc. dba Cobham Analytic Solutions
Craig.Grube at cobham.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20090826/2a7a2ce3/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: puppet.patch
Type: application/octet-stream
Size: 13377 bytes
Desc: puppet.patch
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20090826/2a7a2ce3/attachment.obj
On Wed, Aug 26, 2009 at 07:45:55PM -0400, Grube, Craig wrote:
>
> The attached patch contains policy for Puppet, a configuration management tool. It contains two new services, for the client and server components of Puppet, and adds a new network port type for Puppet's use.
>
> If any changes are desired please let me know and I will provide updated patches as my schedule permits.
>
> Craig
It looks like you've designed this policy on RHEL5 or some older implementation of selinux-policy.
I'am do not have any authority here and i am not a professional but i still took the liberty to look over your policy and make some comments in the hope you find it useful:
+/etc/rc.d/init.d/puppet -- gen_context(system_u:object_r:initrc_exec_t,s0)
should be:
/etc/rc\.d/init\.d/puppet -- gen_context(system_u:object_r:puppetd_initrc_exec_t, s0)
type puppetd_initrc_exec_t;
init_script_file(puppetd_initrc_exec_t)
# END
domain_type(puppet_t)
Should be:
Removed this is included in init_daemon_domain(puppet_t, puppet_exec_t)
# END
+## load libraries
+libs_use_ld_so(puppet_t)
+libs_use_shared_libs(puppet_t)
+libs_exec_lib_files(puppet_t)
Should be:
Not required anymore
# END
+## allow client to bind and send data on high ports
+corenet_all_recvfrom_unlabeled(puppet_t)
+corenet_tcp_sendrecv_all_ports(puppet_t)
should be:
This is incomplete
# END
>
> --
> Craig Grube
allow puppet_t self:fifo_file { read write getattr ioctl };
Should be:
use permission sets where ever possible:
allow puppet_t self:fifo_file rw_fifo_file_perms;
# END
+corecmd_bin_entry_type(puppet_t)
Should be:
i dont think this is required
# END
+rpm_run(puppet_t,system_r)
Should be:
why not rpm_domtrans()
# END
+/etc/rc.d/init.d/puppetmaster -- gen_context(system_u:object_r:initrc_exec_t,s0)
Should be:
see above
# END
+interface(`puppet_run_semanage',`
should be:
is not allowed
# END
+interface(`puppet_run_setsebool',`
should be:
is not allowed
# END
files_pid_filetrans($1,puppet_var_run_t, { file })
Should be:
Also dirs are managed
# END
+ allow $1 puppet_tmp_t:file { read write ioctl };
should be:
rw_file_perms
# END
## <summary>Policy for puppet client</summary>
should be:
Description missing
# END
+interface(`puppet_init_scripts_domtrans',`
should be:
not allowed
# END
allow puppet_t self:capability { sys_admin fowner fsetid setuid setgid sys_rawio dac_override sys_nice sys_ptrace sys_tty_config };
Comment:
is that really required?
> Sparta, Inc. dba Cobham Analytic Solutions
> Craig.Grube at cobham.com
>
>
> _______________________________________________
> 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: 197 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20090827/b4535df7/attachment.bin
On 08/26/2009 07:45 PM, Grube, Craig wrote:
>
> The attached patch contains policy for Puppet, a configuration management tool. It contains two new services, for the client and server components of Puppet, and adds a new network port type for Puppet's use.
>
> If any changes are desired please let me know and I will provide updated patches as my schedule permits.
>
> Craig
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
What is your security goals for puppet? Are you going to allow it to write to anywhere on the system? Seems that a configuration system like puppet needs to have full access unless a user can specify his security goals.
I have no issues with most of the comments and will include those in an updated patch. I do have a couple of questions about several comments.
> It looks like you've designed this policy on RHEL5 or some older implementation of selinux-policy.
Correct. Most of the work was done in Fedora Core 11.
> +interface(`puppet_run_semanage',`
> should be:
> is not allowed
> # END
> +interface(`puppet_run_setsebool',`
> should be:
> is not allowed
> # END
The version of Puppet I'm working with relies on semanage and get/setsebool to manage client's SELinux configuration (i.e. load/unload policy modules, set booleans, etc.) Is the issue with the naming convention or is it preferred that Puppet not be able to manage client's SELinux configuration at all, or that the interfaces be moved into a policy module outside of the reference policy?
> +interface(`puppet_init_scripts_domtrans',`
> should be:
> not allowed
> # END
Same question as the previous one, is the issue with the naming convention or with the ability of Puppet to cycle system services?
Puppet restarts system services after updating configuration files, installing new packages, etc. In the absence of the interface Puppet is either unable to cycle system services or cycled services run in the puppet domain instead of the domain intended for the particular service. Not being able to cycle services would make Puppet not so usefu
I had the interface contents in puppet.te, but moved them into an interface when I needed to pull in the init_script_file_type attribute. The move was based on my understanding that the use of interfaces and gen_require is preferred over using require blocks.
> allow puppet_t self:capability { sys_admin fowner fsetid setuid setgid sys_rawio dac_override sys_nice sys_ptrace sys_tty_config };
> Comment:
> is that really required?
Probably not all are required. Some were required to get the service to run, all appeared in the audit logs but are probably not all necessary for Puppet to function properly.
--
Craig Grube
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20090827/ac82db1e/attachment-0001.html
On Thu, 2009-08-27 at 09:16 -0400, Daniel J Walsh wrote:
> On 08/26/2009 07:45 PM, Grube, Craig wrote:
> >
> > The attached patch contains policy for Puppet, a configuration
> > management tool. It contains two new services, for the client and
> > server components of Puppet, and adds a new network port type for
> > Puppet's use.
> >
> > If any changes are desired please let me know and I will provide
> > updated patches as my schedule permits.
>
> What is your security goals for puppet? Are you going to allow it to
> write to anywhere on the system? Seems that a configuration system
> like puppet needs to have full access unless a user can specify his
> security goals.
I don't agree with full access being needed. Its a configuration
management system, so it seems that a reasonable starting policy would
be able to manage files in /etc, in addition to doing things like run
useradd, semanage, mount, ifconfig, etc.
--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150
On Thu, Aug 27, 2009 at 09:24:00AM -0400, Grube, Craig wrote:
> I have no issues with most of the comments and will include those in an updated patch. I do have a couple of questions about several comments.
>
> > It looks like you've designed this policy on RHEL5 or some older implementation of selinux-policy.
>
> Correct. Most of the work was done in Fedora Core 11.
>
> > +interface(`puppet_run_semanage',`
> > should be:
> > is not allowed
> > # END
> > +interface(`puppet_run_setsebool',`
> > should be:
> > is not allowed
> > # END
>
> The version of Puppet I'm working with relies on semanage and get/setsebool to manage client's SELinux configuration (i.e. load/unload policy modules, set booleans, etc.) Is the issue with the naming convention or is it preferred that Puppet not be able to manage client's SELinux configuration at all, or that the interfaces be moved into a policy module outside of the reference policy?
That shared policy is defined in the wrong module. puppet.if should only have shared policy where the puppet domains are target. in these interface the puppet domains arent the target.
if i remember correct than these interfaces should go to seutils module instead (if similar interfaces arent available already there.)
> > +interface(`puppet_init_scripts_domtrans',`
> > should be:
> > not allowed
> > # END
>
> Same question as the previous one, is the issue with the naming convention or with the ability of Puppet to cycle system services?
>
> Puppet restarts system services after updating configuration files, installing new packages, etc. In the absence of the interface Puppet is either unable to cycle system services or cycled services run in the puppet domain instead of the domain intended for the particular service. Not being able to cycle services would make Puppet not so usefu
>
> I had the interface contents in puppet.te, but moved them into an interface when I needed to pull in the init_script_file_type attribute. The move was based on my understanding that the use of interfaces and gen_require is preferred over using require blocks.
>
> > allow puppet_t self:capability { sys_admin fowner fsetid setuid setgid sys_rawio dac_override sys_nice sys_ptrace sys_tty_config };
> > Comment:
> > is that really required?
>
> Probably not all are required. Some were required to get the service to run, all appeared in the audit logs but are probably not all necessary for Puppet to function properly.
>
> --
> Craig Grube
> _______________________________________________
> 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: 197 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20090827/d51d0705/attachment.bin
On 08/27/2009 10:03 AM, Christopher J. PeBenito wrote:
> On Thu, 2009-08-27 at 09:16 -0400, Daniel J Walsh wrote:
>> On 08/26/2009 07:45 PM, Grube, Craig wrote:
>>>
>>> The attached patch contains policy for Puppet, a configuration
>>> management tool. It contains two new services, for the client and
>>> server components of Puppet, and adds a new network port type for
>>> Puppet's use.
>>>
>>> If any changes are desired please let me know and I will provide
>>> updated patches as my schedule permits.
>>
>> What is your security goals for puppet? Are you going to allow it to
>> write to anywhere on the system? Seems that a configuration system
>> like puppet needs to have full access unless a user can specify his
>> security goals.
>
> I don't agree with full access being needed. Its a configuration
> management system, so it seems that a reasonable starting policy would
> be able to manage files in /etc, in addition to doing things like run
> useradd, semanage, mount, ifconfig, etc.
>
Also needs to be able to install rpm, but I have seen puppet used to move files all over the place, such as apache content.
I am not sure you are getting a great increase in security if I have all of these capabilities.
I guess we could write policy that defaults puppet to unconfined_t and then have people choose to run a tighter policy around what puppet is actually doing on their machine.
My overall goal was to get Puppet and SELinux 'playing nice' together. By that I mean being able to constrain Puppet with SELinux and still have Puppet be functional for typical use, and being able to manage the configuration of SELinux clients with Puppet. I haven't done much work beyond what is already in Puppet on the second front (managing SELinux clients). The patch contains my work on the first front (constraining Puppet).
Constraining the Puppet server was relatively easy as it is a fairly simple network service; it needs to read its config, manage state, and communicate with networked clients.
Given the amount of access required by the client for even basic routine usage (add/remove packages, manage arbitrary files, start/stop services) the obvious choices were to run unconstrained or attempt to build a policy that provides a broad level of access but still constrains the client. I was also specifically interested in having SELinux related Puppet functionality working properly; specifically managing file labels, loading / unloading policy module, setting booleans, etc. and ended up trying to develop a policy that would constrain the Puppet client.
The current policy lets the client do several arguably scary things, specifically: manage all file types, load / unload SELinux policy, get / set SELinux booleans, execute arbitrary binaries, execute system shells (bash).
-c
From: Daniel J Walsh
Sent: Thu 8/27/2009 9:16 AM
To: Grube, Craig
Cc: refpolicy at oss1.tresys.com
Subject: Re: [refpolicy] puppet.patch
What is your security goals for puppet? Are you going to allow it to write to anywhere on the system? Seems that a configuration system like puppet needs to have full access unless a user can specify his security goals.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20090827/4a412067/attachment.html