Hello, there are two types of daemons in Puppet - agent and master. Agent process is responsible for applying desired configuration that is downloaded from the master server (as puppet manifests). This process should run unconfined as it is doing what manifests tell it to do - as root (changing configuration files usually, but Puppet can do much more - pretty much anything). Master process is the server that holds puppet manifests and hands them over via https to agents. This process should be confined. More info here: http://docs.puppetlabs.com/guides/tools.html There are two usual ways of deploying master process - the default one is via init script called puppetmaster, but for production the most scalable way is to use mod_passenger httpd plugin (which runs in passenger_t at the moment, version 4.0 - targetted Fedora 20 - will be able to start ruby processes via wrapper scripts). Historically, puppet agent service was named as "puppet" in RHEL6, but from Fedora 17+ the systemd unit is now called "puppetagent". Puppetmaster service remains the same as "puppetmaster": # rpm -ql puppet | grep \\.service /usr/share/puppet/ext/systemd/puppetagent.service /usr/share/puppet/ext/systemd/puppetmaster.service If you look into the services, you will find out they start daemons using "puppet" command which is unfortunate. ExecStart=/usr/bin/puppet agent and ExecStart=/usr/bin/puppet master We need to start agent as unconfined while master as confined. There is need to raise BZ against puppet package and create wrapper for that. There is another tool which is relevant for selinux and that is puppetca which historically (RHEL6) was in /usr/bin/puppetca, but now it is being called similarly: "puppet ca xyz". Since you are confining puppetca in your current policy, there is need for wrapper. On the other hand the question is if we want to confine this tool which is usually used when administrator is managing CA manually. In unattended installation, agent is usually used to exchange CA so there is no big point in confining the puppetca in my opinion. Now, you have three main domains in the current rawhide puppet policy: - puppet_t - puppetmaster_t - puppetca_t First, having puppet_t and puppetmaster_t is confusing - we are not confining puppet agent, only master process. There are two sets of rules for those domains, but it only make sense to confine puppet master. Puppetmaster service was always named as "puppetmaster" so for me it makes sense to rename all rules to puppetmaster_t and only to keep puppet_t for compatibility as an "alias" (if that's possible). I think since these domains are separated, we are missing lots of puppet_t rules now, or many of these are copied as puppetmaster_t. I did not review all of that, but I can see some rules that are copies. Second, puppetca_t will not work on Fedoras, I think puppetca can be put in unconfined mode for RHEL6 and rules can be removed. Or you need a wrapper around "puppet ca" command (but how to force users to use it?) and change swawning selinux policy. Third, puppet master is often run under httpd/mod_passenger for production setups. We will (Satellite 6.0) run that for our product as well. Since passenger older than 4.0 does not support wrappers, we need to make sure all the combined puppet_t and puppetmaster_t domains are also avaiable to passenger_t. For future version (Fedora 20 - mod_passenger 4.0) we will be finally able to make ruby wrappers and transition to puppetmaster_t. One final note, there is ongoing effort to upgrade Puppet from version 2.6 to 2.7 in EPEL. This will likely need some changes in the spawning policy (in RHEL6 there is no systemd so there will be init.d wrappers avaiable). We should keep an eye on that, no big changes to the policy are expected I think. I will ask my colleagues to review this bug and comment it. TL;DR - puppet_t and puppetmaster_t should be merged - get puppetmaster domain workihng on Fedoras - make all the combined rules avaiable to passenger_t - review the policy and spawning rules (we need to keep working in RHEL6 and Fedoras)
Ok, I agree that we could merge puppet_t and puppetmaster_t together. Then ExecStart=/usr/bin/puppet agent ExecStart=/usr/bin/puppet master is a problem. We don't label /usr/bin/puppet so we have the default bin_t label. It means you will end up with initrc_t/init_t domain. We can not label /usr/bin/puppet because it is an agent as you said. So we will need to have a helper script (which will have puppetmaster_exec_t label) to end up with puppetmaster_t.
*** Bug 1012360 has been marked as a duplicate of this bug. ***
I'm the primary Puppet maintainer in Fedora and I think this plan is a good one to be able to untwist the policy, which has been lagging pretty far behind the actual state of the upstream (and even the packages) for a long time. Ideally puppet_t will go away, leaving just puppetmaster_t since that's the only domain that's actually needed right now.
One additional point - ewoud from Foreman team noted that puppet service was renamed to puppetagent in Fedora 19+ (not F17+). We are able to help you with this testing, because we see many issues with Puppet and SELinux (users are reporting to us) and this would be great to improve. Also, soon we will need this to be resolved for our Satellite product.
Created attachment 809758 [details] Patch against fedpkg puppet Sam, I am attaching patch for puppet fedora package which introduces wrappers. I have decided to name them start-puppet-COMMAND because if we do puppet-COMMAND then shell completion will work weird for "puppet". Start is screwed up already, that is fine I guess. Please review and if you can merge that into F19 as well that would be awesome. In the next step, I would like to make first changes into the core puppet policy and get that reviewed by Foreman community. We need decent testing before we decide to merge this. My goal would be to get the change into RHEL6 and Fedora 19+ core policies, of course having that backward compatible.
So now we can add labeling for %{_bindir}/start-puppet-master and merge these domains. Should we end up with puppetmaster_t or puppet_t?
I'd prefer puppet_t since the agent will have the label, too.
Why would agent need a label? It will run unconfined, agent must not be confined. That is one of the points of this refactoring. I find puppet_t misleading since we are not confining puppet at all, we are confining puppetmaster and puppetca. Everything else should live unconfined. For this reason I suggest to merge all puppet_t staff into puppetmaster_t. Opinions?
Right, the agent shouldn't be confined because the point of the agent is to be able to make changes to the whole system. The master will just run under puppet_t. I'm going to commit lzap's patch to rawhide and then we can move forward with the labeling changes. Thanks again for all of your work on this.
The change is now in rawhide. I'm going to leave this as ASSIGNED since there's a dependent policy change.
I am going to work on it these days.
Any update on where this stands? I'm happy to work on the policy itself of any changes that we need to make to Puppet itself to get the master working properly in enforcing mode.
Mirek, please make sure the policy contains: # For memory-statistics and agent which executes /bin/ps (#3465) domain_read_all_domains_state(passenger_t) More info: http://projects.theforeman.org/issues/3465
commit 7b89fe1a561dd68be9ba4a35bb37bc03a1dc30cf Author: Miroslav Grepl <mgrepl> Date: Wed Apr 9 10:42:40 2014 +0200 Back port puppet fixes from rawhide
selinux-policy-3.12.1-153.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/FEDORA-2014-4933/selinux-policy-3.12.1-153.fc20
Package selinux-policy-3.12.1-153.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing selinux-policy-3.12.1-153.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-4933/selinux-policy-3.12.1-153.fc20 then log in and leave karma (feedback).
selinux-policy-3.12.1-153.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
Related puppet update: https://admin.fedoraproject.org/updates/puppet-3.4.3-3.fc20