So I just upgraded to F19, which means I get Puppet 3 (yay!).
I'm running with unconfined disabled.
Unfortunately, it looks like the policy hasn't been updated for puppet in quite a while. For example, from serefpolicy-contrib-3.12.1/puppet.fc (which I got from selinux-policy-3.12.1-66.fc19.src.rpm ) I see:
/etc/rc.d/init.d/puppet -- gen_context(system_u:object_r:puppet_initrc_exec_t,s0) /etc/rc.d/init.d/puppetmaster -- gen_context(system_u:object_r:puppetmaster_initrc_exec_t,s0)
/usr/sbin/puppetca -- gen_context(system_u:object_r:puppetca_exec_t,s0) /usr/sbin/puppetd -- gen_context(system_u:object_r:puppet_exec_t,s0) /usr/sbin/puppetmasterd -- gen_context(system_u:object_r:puppetmaster_exec_t,s0)
Not a one of those files exists anymore.
This means that things go quite poorly. For example, "sudo systemctl restart puppetmaster.service" gets me:
type=AVC msg=audit(07/29/2013 22:07:49.780:2300368) : avc: denied { open } for pid=28302 comm=ruby-mri path=/var/lib/puppet/ssl/ca/ca_key.pem dev="dm-1" ino=401335 scontext=system_u:system_r:initrc_t:s0 tcontext=system_u:object_r:puppet_var_lib_t:s0 tclass=file type=AVC msg=audit(07/29/2013 22:07:49.780:2300368) : avc: denied { read } for pid=28302 comm=ruby-mri name=ca_key.pem dev="dm-1" ino=401335 scontext=system_u:system_r:initrc_t:s0 tcontext=system_u:object_r:puppet_var_lib_t:s0 tclass=file ---- type=AVC msg=audit(07/29/2013 22:07:49.780:2300369) : avc: denied { ioctl } for pid=28302 comm=ruby-mri path=/var/lib/puppet/ssl/ca/ca_key.pem dev="dm-1" ino=401335 scontext=system_u:system_r:initrc_t:s0 tcontext=system_u:object_r:puppet_var_lib_t:s0 tclass=file ---- type=AVC msg=audit(07/29/2013 22:07:49.966:2300370) : avc: denied { create } for pid=28307 comm=ruby-mri name=master.pid scontext=system_u:system_r:initrc_t:s0 tcontext=system_u:object_r:puppet_var_run_t:s0 tclass=file type=AVC msg=audit(07/29/2013 22:07:49.966:2300370) : avc: denied { add_name } for pid=28307 comm=ruby-mri name=master.pid scontext=system_u:system_r:initrc_t:s0 tcontext=system_u:object_r:puppet_var_run_t:s0 tclass=dir ---- type=SOCKADDR msg=audit(07/29/2013 22:07:49.982:2300371) : saddr=inet host:0.0.0.0 serv:8140 type=AVC msg=audit(07/29/2013 22:07:49.982:2300371) : avc: denied { name_bind } for pid=28307 comm=ruby-mri src=8140 scontext=system_u:system_r:initrc_t:s0 tcontext=system_u:object_r:puppet_port_t:s0 tclass=tcp_socket
because it's running as initrc_t instead of puppetmaster_t:
system_u:system_r:initrc_t:s0 puppet 28307 0.0 0.5 309556 43464 ? Ssl 22:07 0:00 /usr/bin/ruby-mri /usr/bin/puppet master
My knowledge of puppet is considerable, but my selinux is only decent. In particular, the Right Thing here is for the systemd launch of puppetmaster to put things into the right context, but I've no idea how to accomplish that.
Is there someone I can work with to fix up this policy?
-Robin
On 07/30/2013 07:10 AM, Robin Lee Powell wrote:
So I just upgraded to F19, which means I get Puppet 3 (yay!).
I'm running with unconfined disabled.
Unfortunately, it looks like the policy hasn't been updated for puppet in quite a while. For example, from serefpolicy-contrib-3.12.1/puppet.fc (which I got from selinux-policy-3.12.1-66.fc19.src.rpm ) I see:
/etc/rc.d/init.d/puppet -- gen_context(system_u:object_r:puppet_initrc_exec_t,s0) /etc/rc.d/init.d/puppetmaster -- gen_context(system_u:object_r:puppetmaster_initrc_exec_t,s0)
/usr/sbin/puppetca -- gen_context(system_u:object_r:puppetca_exec_t,s0) /usr/sbin/puppetd -- gen_context(system_u:object_r:puppet_exec_t,s0) /usr/sbin/puppetmasterd -- gen_context(system_u:object_r:puppetmaster_exec_t,s0)
Not a one of those files exists anymore.
This means that things go quite poorly. For example, "sudo systemctl restart puppetmaster.service" gets me:
type=AVC msg=audit(07/29/2013 22:07:49.780:2300368) : avc: denied { open } for pid=28302 comm=ruby-mri path=/var/lib/puppet/ssl/ca/ca_key.pem dev="dm-1" ino=401335 scontext=system_u:system_r:initrc_t:s0 tcontext=system_u:object_r:puppet_var_lib_t:s0 tclass=file type=AVC msg=audit(07/29/2013 22:07:49.780:2300368) : avc: denied { read } for pid=28302 comm=ruby-mri name=ca_key.pem dev="dm-1" ino=401335 scontext=system_u:system_r:initrc_t:s0 tcontext=system_u:object_r:puppet_var_lib_t:s0 tclass=file
type=AVC msg=audit(07/29/2013 22:07:49.780:2300369) : avc: denied { ioctl } for pid=28302 comm=ruby-mri path=/var/lib/puppet/ssl/ca/ca_key.pem dev="dm-1" ino=401335 scontext=system_u:system_r:initrc_t:s0 tcontext=system_u:object_r:puppet_var_lib_t:s0 tclass=file
type=AVC msg=audit(07/29/2013 22:07:49.966:2300370) : avc: denied { create } for pid=28307 comm=ruby-mri name=master.pid scontext=system_u:system_r:initrc_t:s0 tcontext=system_u:object_r:puppet_var_run_t:s0 tclass=file type=AVC msg=audit(07/29/2013 22:07:49.966:2300370) : avc: denied { add_name } for pid=28307 comm=ruby-mri name=master.pid scontext=system_u:system_r:initrc_t:s0 tcontext=system_u:object_r:puppet_var_run_t:s0 tclass=dir
type=SOCKADDR msg=audit(07/29/2013 22:07:49.982:2300371) : saddr=inet host:0.0.0.0 serv:8140 type=AVC msg=audit(07/29/2013 22:07:49.982:2300371) : avc: denied { name_bind } for pid=28307 comm=ruby-mri src=8140 scontext=system_u:system_r:initrc_t:s0 tcontext=system_u:object_r:puppet_port_t:s0 tclass=tcp_socket
because it's running as initrc_t instead of puppetmaster_t:
system_u:system_r:initrc_t:s0 puppet 28307 0.0 0.5 309556 43464 ? Ssl 22:07 0:00 /usr/bin/ruby-mri /usr/bin/puppet master
My knowledge of puppet is considerable, but my selinux is only decent. In particular, the Right Thing here is for the systemd launch of puppetmaster to put things into the right context, but I've no idea how to accomplish that.
Is there someone I can work with to fix up this policy?
-Robin
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
Could you please open a new bug with updated paths.
Thank you.
On Tue, Jul 30, 2013 at 08:56:39AM +0200, Miroslav Grepl wrote:
Could you please open a new bug with updated paths.
If it was just a matter of changing paths, I wouldn't have bothered with the email :).
What used to be puppetd is now run as "puppet agent", and what used to be run as puppetmasterd is now run as "puppet master". There are a bunch of other options too.
This could, I guess, be fixed by having wrapper scripts to get to the old functions, but the systemd config does, in fact, do it the new way: ExecStart=/usr/bin/puppet master
I have no idea, at all, how to handle this properly.
-Robin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/30/2013 03:09 AM, Robin Lee Powell wrote:
On Tue, Jul 30, 2013 at 08:56:39AM +0200, Miroslav Grepl wrote:
Could you please open a new bug with updated paths.
If it was just a matter of changing paths, I wouldn't have bothered with the email :).
What used to be puppetd is now run as "puppet agent", and what used to be run as puppetmasterd is now run as "puppet master". There are a bunch of other options too.
This could, I guess, be fixed by having wrapper scripts to get to the old functions, but the systemd config does, in fact, do it the new way: ExecStart=/usr/bin/puppet master
I have no idea, at all, how to handle this properly.
-Robin -- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
Well if we want to get separation between the master and the agent we will either need different entrypoints into the domain (Scripts). Or we will need to build SELinux knowledge into puppet.
Another solution would be to just make puppet into a single (very powerful domain). One thing we have talked about with puppet was to make i easy to extend puppetd policy to allow it to manage certain domains. puppetd_t would be an unconfined domain but if you disabled the unconfined module then you would use a tool like sepolicy generate to generate policy modules for the domains puppetd_t will be administrating.
On Tue, Jul 30, 2013 at 08:01:43AM -0400, Daniel J Walsh wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/30/2013 03:09 AM, Robin Lee Powell wrote:
On Tue, Jul 30, 2013 at 08:56:39AM +0200, Miroslav Grepl wrote:
Could you please open a new bug with updated paths.
If it was just a matter of changing paths, I wouldn't have bothered with the email :).
What used to be puppetd is now run as "puppet agent", and what used to be run as puppetmasterd is now run as "puppet master". There are a bunch of other options too.
This could, I guess, be fixed by having wrapper scripts to get to the old functions, but the systemd config does, in fact, do it the new way: ExecStart=/usr/bin/puppet master
I have no idea, at all, how to handle this properly.
Well if we want to get separation between the master and the agent we will either need different entrypoints into the domain (Scripts). Or we will need to build SELinux knowledge into puppet.
Another solution would be to just make puppet into a single (very powerful domain). One thing we have talked about with puppet was to make i easy to extend puppetd policy to allow it to manage certain domains. puppetd_t would be an unconfined domain but if you disabled the unconfined module then you would use a tool like sepolicy generate to generate policy modules for the domains puppetd_t will be administrating.
Making puppet into a one giant super domain would be by far the easiest, since it would also cover things like "puppet apply", where puppet is used to run a puppet script file.
What's the right way for me to present a patch for this? Is there a github or something for the current policy?
-Robin
On Wed, Jul 31, 2013 at 10:57:31AM -0700, Robin Lee Powell wrote:
On Tue, Jul 30, 2013 at 08:01:43AM -0400, Daniel J Walsh wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/30/2013 03:09 AM, Robin Lee Powell wrote:
On Tue, Jul 30, 2013 at 08:56:39AM +0200, Miroslav Grepl wrote:
Could you please open a new bug with updated paths.
If it was just a matter of changing paths, I wouldn't have bothered with the email :).
What used to be puppetd is now run as "puppet agent", and what used to be run as puppetmasterd is now run as "puppet master". There are a bunch of other options too.
This could, I guess, be fixed by having wrapper scripts to get to the old functions, but the systemd config does, in fact, do it the new way: ExecStart=/usr/bin/puppet master
I have no idea, at all, how to handle this properly.
Well if we want to get separation between the master and the agent we will either need different entrypoints into the domain (Scripts). Or we will need to build SELinux knowledge into puppet.
Another solution would be to just make puppet into a single (very powerful domain). One thing we have talked about with puppet was to make i easy to extend puppetd policy to allow it to manage certain domains. puppetd_t would be an unconfined domain but if you disabled the unconfined module then you would use a tool like sepolicy generate to generate policy modules for the domains puppetd_t will be administrating.
Making puppet into a one giant super domain would be by far the easiest, since it would also cover things like "puppet apply", where puppet is used to run a puppet script file.
What's the right way for me to present a patch for this? Is there a github or something for the current policy?
Help, please. Is there any docs on how to submit policy patches?
-Robin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/03/2013 04:26 AM, Robin Lee Powell wrote:
On Wed, Jul 31, 2013 at 10:57:31AM -0700, Robin Lee Powell wrote:
On Tue, Jul 30, 2013 at 08:01:43AM -0400, Daniel J Walsh wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/30/2013 03:09 AM, Robin Lee Powell wrote:
On Tue, Jul 30, 2013 at 08:56:39AM +0200, Miroslav Grepl wrote:
Could you please open a new bug with updated paths.
If it was just a matter of changing paths, I wouldn't have bothered with the email :).
What used to be puppetd is now run as "puppet agent", and what used to be run as puppetmasterd is now run as "puppet master". There are a bunch of other options too.
This could, I guess, be fixed by having wrapper scripts to get to the old functions, but the systemd config does, in fact, do it the new way: ExecStart=/usr/bin/puppet master
I have no idea, at all, how to handle this properly.
Well if we want to get separation between the master and the agent we will either need different entrypoints into the domain (Scripts). Or we will need to build SELinux knowledge into puppet.
Another solution would be to just make puppet into a single (very powerful domain). One thing we have talked about with puppet was to make i easy to extend puppetd policy to allow it to manage certain domains. puppetd_t would be an unconfined domain but if you disabled the unconfined module then you would use a tool like sepolicy generate to generate policy modules for the domains puppetd_t will be administrating.
Making puppet into a one giant super domain would be by far the easiest, since it would also cover things like "puppet apply", where puppet is used to run a puppet script file.
What's the right way for me to present a patch for this? Is there a github or something for the current policy?
Help, please. Is there any docs on how to submit policy patches?
-Robin
If we just change the label on /usr/bin/puppet to puppetmaster_exec_t what happens?
On Mon, Aug 05, 2013 at 11:10:06AM -0400, Daniel J Walsh wrote:
Help, please. Is there any docs on how to submit policy patches?
If we just change the label on /usr/bin/puppet to puppetmaster_exec_t what happens?
As far as I can tell that's working perfectly on both client and server sides (although I'm running the client with sudo, which turns unconfined back on, so it's hard to be absolutely sure).
Nice!
-Robin
selinux@lists.fedoraproject.org