Created attachment 605025 [details] avc denials in permissive mode Description of problem: I'm migrating my puppet master from EL6 to Fedora 17 and using the passenger package under review (https://bugzilla.redhat.com/show_bug.cgi?id=470696) to run it as a passenger/rack application. Some work on this was done previously for EL6 (https://bugzilla.redhat.com/show_bug.cgi?id=730837) but it was never complete. The passenger package ships a rubygem_passenger selinux module: ------ policy_module(rubygem-passenger, 1.1) require { type httpd_t, httpd_tmp_t; class capability sys_ptrace; }; # This should use interface macros allow httpd_t httpd_tmp_t:sock_file { create write unlink getattr setattr }; allow httpd_t self:capability { fowner sys_resource fsetid }; # These allow the watchdog to run ps, but also any other httpd_t # process, too (CGI scripts run in httpd_sys_script_t, but PHP, # mod_perl, etc run in httpd_t) bool httpd_use_ps true; if (httpd_use_ps) { domain_ptrace_all_domains(httpd_t) domain_dontaudit_search_all_domains_state(httpd_t) } #Used by Watchdog allow httpd_t self:capability sys_ptrace; ----- Don't know what effect that is having. Version-Release number of selected component (if applicable): selinux-policy-3.10.0-145.fc17.noarch
What does # ps -efZ |grep httpd
system_u:system_r:httpd_t:s0 root 16180 17487 0 Aug19 ? 00:00:00 PassengerWatchdog system_u:system_r:httpd_t:s0 root 16184 16180 0 Aug19 ? 00:00:00 PassengerHelperAgent system_u:system_r:httpd_t:s0 root 16187 16184 0 Aug19 ? 00:00:00 Passenger spawn server system_u:system_r:httpd_t:s0 nobody 16190 16180 0 Aug19 ? 00:00:00 PassengerLoggingAgent system_u:system_r:httpd_t:s0 apache 16220 17487 0 Aug19 ? 00:00:00 /usr/sbin/httpd -k start
Which is wrong. Could you paste paths to PassengerWatchdog, PassengerHelperAgent, PassengerLoggingAgent with labels. # ls -lZ PATHTO/PassengerWatchdog # ls -lZ PATHTO/PassengerHelperAgent # ls -lZ PATHTO/PassengerLoggingAgent
[root@gepetto puppet]# ls -lZ /usr/share/gems/gems/passenger-3.0.14/agents/ drwxr-xr-x. root root system_u:object_r:bin_t:s0 apache2 -rwxrwxr-x. root root system_u:object_r:httpd_exec_t:s0 PassengerLoggingAgent -rwxrwxr-x. root root system_u:object_r:httpd_exec_t:s0 PassengerWatchdog [root@gepetto puppet]# ls -lZ /usr/share/gems/gems/passenger-3.0.14/agents/apache2/ -rwxrwxr-x. root root system_u:object_r:httpd_exec_t:s0 PassengerHelperAgent /usr/share/selinux/packages/rubygem-passenger/rubygem-passenger.fc contains: /usr/share/gems/gems/passenger-3.0.14/agents/PassengerWatchdog gen_context(system_u:object_r:httpd_exec_t,s0) /usr/share/gems/gems/passenger-3.0.14/agents/PassengerLoggingAgent gen_context(system_u:object_r:httpd_exec_t,s0) /usr/share/gems/gems/passenger-3.0.14/agents/apache2/PassengerHelperAgent gen_context(system_u:object_r:httpd_exec_t,s0) /usr/share/gems/gems/passenger-3.0.14/ gen_context(system_u:object_r:bin_t,s0) /usr/share/gems/gems/passenger-3.0.14/agents gen_context(system_u:object_r:bin_t,s0) /usr/share/gems/gems/passenger-3.0.14/agents/apache2 gen_context(system_u:object_r:bin_t,s0) /usr/share/gems/gems/passenger-3.0.14/helper-scripts/prespawn gen_context(system_u:object_r:bin_t,s0) /usr/share/gems/gems/passenger-3.0.14/helper-scripts/passenger-spawn-server.spawnip gen_context(system_u:object_r:bin_t,s0) /usr/share/gems/gems/passenger-3.0.14/helper-scripts/passenger-spawn-server gen_context(system_u:object_r:bin_t,s0) I take it it shouldn't ship that? You might want to comment in the review, it would be helpful.
Yes, you got it. This is a problem. Could you try to disable this rubygem-passenger module? # semodule -d rubygem-passenger # restorecon -R -v /usr/share/gems and restart all passenger services.
That reset the labels to usr_t, but now I get: type=AVC msg=audit(1345649166.602:76): avc: denied { execute } for pid=1333 comm="httpd" name="PassengerWatchdog" dev="vda2" ino=8646 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=file type=AVC msg=audit(1345649166.602:76): avc: denied { execute_no_trans } for pid=1333 comm="httpd" path="/usr/share/gems/gems/passenger-3.0.14/agents/PassengerWatchdog" dev="vda2" ino=8646 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=file type=AVC msg=audit(1345649166.694:77): avc: denied { sys_resource } for pid=1333 comm="PassengerWatchd" capability=24 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:httpd_t:s0 tclass=capability type=AVC msg=audit(1345649174.040:79): avc: denied { fowner } for pid=1381 comm="chmod" capability=3 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:httpd_t:s0 tclass=capability type=AVC msg=audit(1345649174.040:79): avc: denied { fsetid } for pid=1381 comm="chmod" capability=4 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:httpd_t:s0 tclass=capability type=AVC msg=audit(1345649194.019:80): avc: denied { search } for pid=1389 comm="ruby" name="puppet" dev="vda2" ino=392393 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:puppet_etc_t:s0 tclass=dir type=AVC msg=audit(1345649194.019:80): avc: denied { getattr } for pid=1389 comm="ruby" path="/etc/puppet/modules" dev="vda2" ino=393326 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:puppet_etc_t:s0 tclass=dir type=AVC msg=audit(1345649194.019:81): avc: denied { read } for pid=1389 comm="ruby" name="modules" dev="vda2" ino=393326 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:puppet_etc_t:s0 tclass=dir type=AVC msg=audit(1345649194.019:81): avc: denied { open } for pid=1389 comm="ruby" path="/etc/puppet/modules" dev="vda2" ino=393326 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:puppet_etc_t:s0 tclass=dir
Ok, I see the labeling bug in F17. execute # chcon -t passenger_exec_t /usr/share/gems/gems/passenger-3.0.14/agents/PassengerWatchdog /usr/share/gems/gems/passenger-3.0.14/agents/apache2/PassengerHelperAgent /usr/share/gems/gems/passenger-3.0.14/agents/PassengerLoggingAgent
Created attachment 606667 [details] avc denials in permissive mode Not sufficient. I got: [ pid=3098 thr=140138351482688 file=ext/common/AgentBase.cpp:419 time=2012-08-23 11:34:51.747 ]: *** ERROR: Unexpected end-of-file encountered in 'void Passenger::VariantMap::readFrom(int)' (VariantMap.h:140) in 'Passenger::VariantMap Passenger::initializeAgent(int, char**, const char*)' (AgentBase.cpp:355) [Thu Aug 23 11:34:51 2012] [error] *** Passenger could not be initialized because of this error: Unable to start the Phusion Passenger watchdog: it seems to have crashed during startup for an unknown reason, with exit code 1 but no denials in audit.log. Switched to permissive and it works and I see the attached denials This may be further complicated because I moved the puppet rack config from /usr/share/puppet/rack to /var/lib/puppet/rack in the apache config, so from usr_t to puppet_var_lib_t.
I am adding fixes for passenger policy to F18 and will backport passenger policy to F17.
Note that the final install location for the agents is not yet set. Hopefully today though we'll get it. They don't belong in /usr/share though since they are binaries.
New install path will be in %{_libdir}: /usr/lib64/gems/exts/passenger-3.0.14/agents/: drwxr-xr-x. root root system_u:object_r:lib_t:s0 apache2 -rwxr-xr-x. root root system_u:object_r:lib_t:s0 PassengerLoggingAgent -rwxr-xr-x. root root system_u:object_r:lib_t:s0 PassengerWatchdog /usr/lib64/gems/exts/passenger-3.0.14/agents/apache2: -rwxr-xr-x. root root system_u:object_r:lib_t:s0 PassengerHelperAgent
Thanks. Added.
selinux-policy-3.10.0-149.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/selinux-policy-3.10.0-149.fc17
Package selinux-policy-3.10.0-149.fc17: * should fix your issue, * was pushed to the Fedora 17 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.10.0-149.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-14301/selinux-policy-3.10.0-149.fc17 then log in and leave karma (feedback).
The new paths don't have the proper contexts with this change: selinux-policy-3.10.0-149.fc17.noarch [root@gepetto ~]# ls -lZR /usr/lib64/gems/exts/passenger-3.0.14/agents/ /usr/lib64/gems/exts/passenger-3.0.14/agents/: drwxr-xr-x. root root system_u:object_r:lib_t:s0 apache2 -rwxr-xr-x. root root system_u:object_r:lib_t:s0 PassengerLoggingAgent -rwxr-xr-x. root root system_u:object_r:lib_t:s0 PassengerWatchdog /usr/lib64/gems/exts/passenger-3.0.14/agents/apache2: -rwxr-xr-x. root root system_u:object_r:lib_t:s0 PassengerHelperAgent So this update doesn't fix this bug.
The bug also exist on F18. Testing openshift, i have noticed a high cpu usage due to the number of avc triggered by passenger ( since it run ps to check the process, see ./ext/common/Utils/ProcessMetricsCollector.h function ProcessMetricsCollector::collect ). And same issue of label : # ls -lZ /usr/lib/gems/exts/passenger-3.0.17/agents drwxr-xr-x. root root system_u:object_r:lib_t:s0 apache2 -rwxr-xr-x. root root system_u:object_r:lib_t:s0 PassengerLoggingAgent -rwxr-xr-x. root root system_u:object_r:lib_t:s0 PassengerWatchdog # rpm -q selinux-policy selinux-policy-3.11.1-21.fc18.noarch
I just added the following labeling to F18. /usr/share/gems/.*/Passenger.* -- gen_context(system_u:object_r:passenger_exec_t,s0) /usr/lib/gems/.*/Passenger.* -- gen_context(system_u:object_r:passenger_exec_t,s0) Could you try this label for your machine. semanage fcontext -a -t passenger_exec_t -f -- '/usr/share/gems/.*/Passenger.*'
Added also labeling for ApplicationPoolServerExecutable
That labelling gets the agents. I have no idea what ApplicationPoolServerExecutable refers to. In permissive mode I see: type=AVC msg=audit(1348153395.886:44666): avc: denied { getattr } for pid=32415 comm="ruby" path="socket:[5796223]" dev="sockfs" ino=5796223 scontext=system_u:system_r:passenger_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=unix_stream_socket type=AVC msg=audit(1348153395.889:44667): avc: denied { ioctl } for pid=32415 comm="ruby" path="socket:[5796223]" dev="sockfs" ino=5796223 scontext=system_u:system_r:passenger_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=unix_stream_socket type=AVC msg=audit(1348153396.159:44668): avc: denied { write } for pid=32409 comm="httpd" name="socket" dev="tmpfs" ino=5797081 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:passenger_tmp_t:s0 tclass=sock_file type=AVC msg=audit(1348153434.513:44670): avc: denied { listen } for pid=32517 comm="ruby" laddr=127.0.0.1 lport=48117 scontext=system_u:system_r:passenger_t:s0 tcontext=system_u:system_r:passenger_t:s0 tclass=tcp_socket type=AVC msg=audit(1348153436.846:44671): avc: denied { execute } for pid=32715 comm="ruby" name="ifconfig" dev="vda2" ino=261296 scontext=system_u:system_r:passenger_t:s0 tcontext=system_u:object_r:ifconfig_exec_t:s0 tclass=file type=AVC msg=audit(1348153436.846:44671): avc: denied { read open } for pid=32715 comm="ruby" path="/usr/sbin/ifconfig" dev="vda2" ino=261296 scontext=system_u:system_r:passenger_t:s0 tcontext=system_u:object_r:ifconfig_exec_t:s0 tclass=file type=AVC msg=audit(1348153436.846:44671): avc: denied { execute_no_trans } for pid=32715 comm="ruby" path="/usr/sbin/ifconfig" dev="vda2" ino=261296 scontext=system_u:system_r:passenger_t:s0 tcontext=system_u:object_r:ifconfig_exec_t:s0 tclass=file type=AVC msg=audit(1348153436.849:44672): avc: denied { read } for pid=32715 comm="ifconfig" name="unix" dev="proc" ino=4026531999 scontext=system_u:system_r:passenger_t:s0 tcontext=system_u:object_r:proc_net_t:s0 tclass=file type=AVC msg=audit(1348153436.849:44673): avc: denied { search } for pid=32715 comm="ifconfig" name="net" dev="proc" ino=9067 scontext=system_u:system_r:passenger_t:s0 tcontext=system_u:object_r:sysctl_net_t:s0 tclass=dir type=AVC msg=audit(1348153436.850:44674): avc: denied { open } for pid=32715 comm="ifconfig" path="/proc/32715/net/dev" dev="proc" ino=4026531972 scontext=system_u:system_r:passenger_t:s0 tcontext=system_u:object_r:proc_net_t:s0 tclass=file type=AVC msg=audit(1348153436.850:44675): avc: denied { getattr } for pid=32715 comm="ifconfig" path="/proc/32715/net/dev" dev="proc" ino=4026531972 scontext=system_u:system_r:passenger_t:s0 tcontext=system_u:object_r:proc_net_t:s0 tclass=file type=AVC msg=audit(1348153447.092:44678): avc: denied { create } for pid=32517 comm="ruby" name="201209201504.yaml20120920-32517-125jb7a.lock" scontext=system_u:system_r:passenger_t:s0 tcontext=system_u:object_r:puppet_var_lib_t:s0 tclass=dir type=AVC msg=audit(1348153447.116:44679): avc: denied { rmdir } for pid=32517 comm="ruby" name="201209201504.yaml20120920-32517-125jb7a.lock" dev="vda2" ino=146896 scontext=system_u:system_r:passenger_t:s0 tcontext=system_u:object_r:puppet_var_lib_t:s0 tclass=dir type=AVC msg=audit(1348153447.233:44680): avc: denied { write } for pid=32445 comm="httpd" name="ruby.TgTGzwVFCSt9ptj29VZSFz5LJDWhpaZIw08mfdJDoCzDABxghVlyMHo" dev="tmpfs" ino=5797297 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:passenger_tmp_t:s0 tclass=sock_file
selinux-policy-3.10.0-149.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
Created attachment 626105 [details] avc denials in permissive mode Looking better with selinux-policy-3.10.0-153.fc17.noarch but still seeing denials. I suspect we still need a way to transition from passenger to puppet contexts.
You are going to be running puppet from a webserver?
The master, yes. So "puppet master" contexts.
Well this looks like something we had better think about. Isn't it kind of dangerous to allow puppet server to be launched by httpd? Since puppet_t can basically write anywhere it wants?
I think you are still confusing the puppet agent with the puppet master. I'm running the puppet master as a web service via passenger. I'm assuming that the puppet master would normally run in a different context than the puppet agent. There may be some denials in the messages I attached from a puppet agent run on that machine as well, but it is the passenger_t denials that are the issue. I believe this is essentially the puppet master processes under passenger: system_u:system_r:passenger_t:s0 puppet 10364 1 1 14:17 ? 00:00:14 Rack: /var/lib/puppet/rack/puppetmasterd But it is still running in passenger_t, not puppet_master_t(?).
Yes, this is a problem. Running the puppet master as a web service via passenger.
I just got pinged on this from inside, Should we add puppet_domtrans_master(passenger_t) Or puppet_domtrans?
We might want to add something like optional_policy(` tunable_policy(`passenger_run_puppet', ` puppet_manage_lib(passenger_t) puppet_read_config(passenger_t) puppet_append_log(passenger_t) puppet_create_log(passenger_t) puppet_read_log(passenger_t) puppet_search_pid(passenger_t) ',` puppet_domtrans(passenger_t) ') ')
Ok, probably it won't be so easy. I think we are not able to get a transition here. Could anybody try to test the following local policy # cat mypassenger.te policy_module(mypassenger, 1.0) require{ type puppetmaster_t; type puppetmaster_exec_t; } domtrans_pattern(passenger_t, puppetmaster_exec_t, puppetmaster_t) and run # make -f /usr/share/selinux/devel/Makefile mypassenger.pp # semodule -i mypassenger.pp and re-test it.
I needed to add "type passenger_t;" to the require block. With that change, no change: # ps -feZ | grep -Ei '(puppet|passenger)' system_u:system_r:passenger_t:s0 root 22963 22944 0 09:28 ? 00:00:00 PassengerWatchdog system_u:system_r:passenger_t:s0 root 22966 22963 0 09:28 ? 00:00:00 PassengerHelperAgent system_u:system_r:passenger_t:s0 root 22968 22966 0 09:28 ? 00:00:00 Passenger spawn server system_u:system_r:passenger_t:s0 nobody 22971 22963 0 09:28 ? 00:00:00 PassengerLoggingAgent system_u:system_r:passenger_t:s0 puppet 22986 22968 1 09:28 ? 00:00:01 master system_u:system_r:passenger_t:s0 puppet 23000 1 4 09:28 ? 00:00:03 Rack: /var/lib/puppet/rack/puppetmasterd I think that problem is that there isn't anything labeled "puppetmaster_exec_t" that is executed by passenger. As I understand it, Passenger runs /var/lib/puppet/rack/puppetmasterd/config.ru via ruby to start the puppet master process. So pid 23000 is just a "/usr/bin/ruby" process.
Can we get this changed to be a shell script with the ruby command so that we have an entrypoint?
I don't think so - I think this is pretty integral to how ruby Rack is designed. Anyway, would need someone much more familiar with these tools than me to say. Can SELinux trigger domain transitions in any other way?
Could the puppet master code request a transition to puppetmaster_t?
I am not sure, but what about using mod_selinux for that ? Since apache will run passenger, who will run puppet, we can directly make apache make the trnasition based on port/vhost with the configuration ?
Passenger could request a transition. fork() setexeccon("system_u:system_r:puppetmaster_t:s0") exec("ruby /var/lib/puppet/rack/puppetmasterd/config.ru") (policy would have to make bin_t an entrypoint for puppetmaster_t).
Making bin_t a entrypoint for puppetmaster_t doesn't sound like a good idea, as bin_t is widely used, and puppetmaster_t has read access to the private key of puppet to authenticate the master to agents ( puppet is using ssl and CA for that, and the puppetmaster is the CA ). This would permit to make MitM on a whole infrastucture. And since puppet agent is running as root, that's bad(tm).
Well if we can not get passenger to use a script to launch puppetmaster, and it is required we use the ruby command directly. Our choice is to allow passenger to to the setexeccon() and execute ruby. Labeling ruby something different does not help since ruby can execute anything it wants.
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
One way to solve this could be in Passenger 4.0 which introduced scoped PassengerRuby option. Now it is possible to configure applications with different ruby binaries. http://www.modrails.com/documentation/Users%20guide%20Apache.html#PassengerRuby One is able to create a wrapper with proper context and set it using this option. We are currently investigating this. Fedora 19 has Passenger 3.0 but hopefuly 20 will feature 4.0 which allows one to do this per-application (which we need - we also run another ruby application in a different context).
So the wrapper approach lzap's suggesting does appear to work. It requires Passenger 4.x in order to work per-VirtualHost/Location/Directory etc, which will allow you to run the puppetmaster in one configuration without affecting other apps within the same httpd. There's an RPM build[1] of 4.0.5 in the Katello Koji that we've been using for Foreman. The wrapper just execs the local Ruby interpreter, but has the puppetmaster_exec_t context, like the old /usr/sbin/puppetmasterd script used to: # ll -Z /usr/libexec/passenger/ruby-puppetmaster -rwxr-xr-x. root root unconfined_u:object_r:puppetmaster_exec_t:s0 /usr/libexec/passenger/ruby-puppetmaster # cat /usr/libexec/passenger/ruby-puppetmaster #!/bin/sh exec /usr/bin/ruby $* To the puppetmaster VirtualHost, we specify the wrapper as the Ruby to use: PassengerRuby /usr/libexec/passenger/ruby-puppetmaster In the policy, we permit this transition: type_transition passenger_t puppetmaster_exec_t : process puppetmaster_t; And the resulting process becomes puppetmaster_t: system_u:system_r:puppetmaster_t:s0 puppet 16676 1.5 6.8 287800 52408 ? Sl 10:32 0:00 Passenger RackApp: /etc/puppet/rack A couple of issues that I can think of with this: 1) wrappers need adding to each application package that's supported to run in its own domain. There's no package for Puppet Passenger configuration today, but perhaps this could be added to the core puppet package, or a new puppet-passenger subpackage is created (Debian has puppetmaster-passenger). 2) Passenger applications that aren't explicitly given a wrapper/context should probably not run in passenger_t, but some generic passenger_app_t domain. Else if they run in passenger_t, they could exec the wrapper, giving them a full Ruby interpreter transitioned to the puppetmaster_t domain (echoing the concerns in comment #36). We could provide a default wrapper to do this in the rubygem-passenger package and configure it in /etc/httpd/conf.d/passenger.conf. I'll file a BZ to request Passenger 4 is packaged. [1]http://koji.katello.org/koji/buildinfo?buildID=4848
So we need a workaround (add passenger_run_puppet_master boolean) until a new version.
(In reply to Miroslav Grepl from comment #42) > So we need a workaround (add passenger_run_puppet_master boolean) until a > new version. Yes, I think this is needed in F19 at least, along the lines of comment #28. It appears that passenger_t in F19 no longer has these permissions by default, unlike F18 or EL6.
FWIW - I still have to run in permissive on F18.
(In reply to Orion Poplawski from comment #44) > FWIW - I still have to run in permissive on F18. What AVCs are you getting? I thought passenger_t permitted access to all puppet_* types in F18 so it wouldn't be an issue.
Some samples: avc: denied { create } for pid=1074 comm="ruby" name="font1lin.cora.nwra.com.yaml20130724-1074-1wgvz9x.lock" scontext=system_u:system_r:passenger_t:s0 tcontext=system_u:object_r:puppet_var_lib_t:s0 tclass=dir avc: denied { rmdir } for pid=1074 comm="ruby" name="font1lin.cora.nwra.com.yaml20130724-1074-1wgvz9x.lock" dev="vda2" ino=131896 scontext=system_u:system_r:passenger_t:s0 tcontext=system_u:object_r:puppet_var_lib_t:s0 tclass=dir So no puppet_var_lib_t access? avc: denied { name_connect } for pid=668 comm="httpd" dest=8141 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:puppet_port_t:s0 tclass=tcp_socket Do I need to label the port differently? avc: denied { write } for pid=1900 comm="httpd" name="ruby.m2yHaKVLgM2DoTUmVDJYHcONfJVYL4vYFw0JDGk52g6uPOd3OM63r3LLB" dev="tmpfs" ino=16795 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:passenger_tmp_t:s0 tclass=sock_file ? Hmm, not as bad as I first thought actually. I've been playing around with the dashboard as well and seeing: avc: denied { name_connect } for pid=1090 comm="ruby" dest=3000 scontext=system_u:system_r:passenger_t:s0 tcontext=system_u:object_r:ntop_port_t:s0 tclass=tcp_socket
F18 and F19 passenger+puppet policies are almost the same.
(In reply to Orion Poplawski from comment #46) > Some samples: > > avc: denied { create } for pid=1074 comm="ruby" > name="font1lin.cora.nwra.com.yaml20130724-1074-1wgvz9x.lock" > scontext=system_u:system_r:passenger_t:s0 > tcontext=system_u:object_r:puppet_var_lib_t:s0 tclass=dir > avc: denied { rmdir } for pid=1074 comm="ruby" > name="font1lin.cora.nwra.com.yaml20130724-1074-1wgvz9x.lock" dev="vda2" > ino=131896 scontext=system_u:system_r:passenger_t:s0 > tcontext=system_u:object_r:puppet_var_lib_t:s0 tclass=dir > > So no puppet_var_lib_t access? It's limited, looks like it's missing dir create/rmdir permissions. allow passenger_t puppet_var_lib_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; allow passenger_t puppet_var_lib_t : dir { ioctl read write getattr lock add_name remove_name search open } ; > avc: denied { name_connect } for pid=668 comm="httpd" dest=8141 > scontext=system_u:system_r:httpd_t:s0 > tcontext=system_u:object_r:puppet_port_t:s0 tclass=tcp_socket > > Do I need to label the port differently? I can't think why that would be needed, it's httpd trying to connect to the puppetmaster port. Do you have some kind of reverse proxy config perhaps? > avc: denied { write } for pid=1900 comm="httpd" > name="ruby.m2yHaKVLgM2DoTUmVDJYHcONfJVYL4vYFw0JDGk52g6uPOd3OM63r3LLB" > dev="tmpfs" ino=16795 scontext=system_u:system_r:httpd_t:s0 > tcontext=system_u:object_r:passenger_tmp_t:s0 tclass=sock_file > > ? We saw this with Foreman under Passenger too, think it needs fixing.
(In reply to Miroslav Grepl from comment #47) > F18 and F19 passenger+puppet policies are almost the same. It does look OK in the policy source to me, but the compiled policy doesn't appear to be right: F18: # sesearch --allow -s passenger_t -t puppet_var_lib_t Found 2 semantic av rules: allow passenger_t puppet_var_lib_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; allow passenger_t puppet_var_lib_t : dir { ioctl read write getattr lock add_name remove_name search open } ; F19: # sesearch --allow -s passenger_t -t puppet_var_lib_t <no output> I've checked on a few machines, using selinux-policy-targeted-3.12.1-65.fc19.noarch.
Ok, there needs to be a bug in the policy. These rules exist.
Ok, I see a bug. Fixing.
commit 489691f664fa5e1afaf2f0f5cf26608d02c3dd6b Author: Miroslav Grepl <mgrepl> Date: Mon Jul 29 12:55:17 2013 +0200 Fix puppet_domtrans_master() to make all puppet calling working in passenger.te Good catch. Thanks.
Mirek, is this fix going to be backported into F19? We have couple of users reporting this AVCs to us constantly :-) http://projects.theforeman.org/issues/2896 Thanks!
Yes, it has been fixed also in F19. But these AVC msg look like a different issue.
Mirek, I have few more AVCs we are hitting on F19: [root@hp-dl585g5-01 foreman]# grep AVC /var/log/audit/audit.log type=AVC msg=audit(1380187411.432:224): avc: denied { search } for pid=29644 comm="httpd" name="puppet" dev="dm-4" ino=785677 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:puppet_etc_t:s0 tclass=dir type=AVC msg=audit(1380187411.438:225): avc: denied { name_connect } for pid=6396 comm="httpd" dest=8140 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:puppet_port_t:s0 tclass=tcp_socket type=AVC msg=audit(1380187412.637:228): avc: denied { search } for pid=29647 comm="httpd" name="puppet" dev="dm-4" ino=785677 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:puppet_etc_t:s0 tclass=dir type=AVC msg=audit(1380187412.879:229): avc: denied { search } for pid=29647 comm="httpd" name="puppet" dev="dm-4" ino=785677 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:puppet_etc_t:s0 tclass=dir type=USER_AVC msg=audit(1380187641.039:232): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc: received setenforce notice (enforcing=0) exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?' type=AVC msg=audit(1380187641.189:233): avc: denied { getattr } for pid=29739 comm="httpd" path="/etc/puppet/rack/public" dev="dm-4" ino=786158 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:puppet_etc_t:s0 tclass=dir type=AVC msg=audit(1380187641.194:234): avc: denied { name_connect } for pid=29647 comm="httpd" dest=8140 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:puppet_port_t:s0 tclass=tcp_socket type=AVC msg=audit(1380187642.581:236): avc: denied { getattr } for pid=29748 comm="ruby-mri" path="socket:[70141]" dev="sockfs" ino=70141 scontext=system_u:system_r:passenger_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=unix_stream_socket type=AVC msg=audit(1380187642.588:237): avc: denied { ioctl } for pid=29748 comm="ruby-mri" path="socket:[70141]" dev="sockfs" ino=70141 scontext=system_u:system_r:passenger_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=unix_stream_socket [root@hp-dl585g5-01 foreman]# grep AVC /var/log/audit/audit.log | audit2allow #============= httpd_t ============== allow httpd_t puppet_etc_t:dir { search getattr }; #!!!! This avc can be allowed using the boolean 'httpd_can_network_connect' allow httpd_t puppet_port_t:tcp_socket name_connect; #============= passenger_t ============== allow passenger_t init_t:unix_stream_socket { getattr ioctl }; [root@hp-dl585g5-01 foreman]# rpm -q selinux-policy mod_passenger foreman selinux-policy-3.12.1-74.4.fc19.noarch mod_passenger-3.0.21-4.fc19.x86_64 foreman-1.3.0-0.2.RC2.fc19.noarch
Created attachment 856689 [details] passenger_puppet.te Hi, I was having the same problem on an EL6.5 clone when using the mod_passenger-3.0.21-11.el6.x86_64 from EPEL, selinux policy 3.7.19-231.el6 and puppet-3.4.2-1.el6 from the puppetlabs' oficial yum repo. The attached selinux module fixes the problem for me (and for now :) ). I also had to explicitly configure passenger to use PassengerTempdir /var/run/passenger. Given that this is a dedicated VM with no other use but Puppet master, setting up PassengerRuby to a custom wrapper globally was acceptable. The wrapper had to have a selinux type of puppetmaster_exec_t, as suggested here.
Could a fix similar to the one mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=848939#c56 be incorporated into the official policy? I'm seeing similar problems on EL6.5: type=SYSCALL msg=audit(1398360203.810:19740344): arch=c000003e syscall=84 success=no exit=-13 a0=55cdda0 a1=7fd267de50a8 a2=55cde01 a3=20 items=0 ppid=1 pid=2124 auid=4294967295 uid=52 gid=52 euid=52 suid=52 fsuid=52 egid=52 sgid=52 fsgid=52 tty=(none) ses=4294967295 comm="ruby" exe="/usr/bin/ruby" subj=system_u:system_r:httpd_t:s0 key=(null) type=AVC msg=audit(1398360207.603:19740555): avc: denied { remove_name } for pid=2124 comm="ruby" name="201404241723.yaml20140424-2124-nt5fcu-0" dev=dm-2 ino=655474 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:puppet_var_lib_t:s0 tclass=dir type=SYSCALL msg=audit(1398360207.603:19740555): arch=c000003e syscall=87 success=no exit=-13 a0=6024f90 a1=0 a2=c a3=8 items=0 ppid=1 pid=2124 auid=4294967295 uid=52 gid=52 euid=52 suid=52 fsuid=52 egid=52 sgid=52 fsgid=52 tty=(none) ses=4294967295 comm="ruby" exe="/usr/bin/ruby" subj=system_u:system_r:httpd_t:s0 key=(null) type=AVC msg=audit(1398360208.022:19740556): avc: denied { remove_name } for pid=2124 comm="ruby" name="201404241723.yaml20140424-2124-2rw2rf-0.lock" dev=dm-2 ino=1179940 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:puppet_var_lib_t:s0 tclass=dir with the same versions, except for Puppet which is 2.7.22 from EPEL.
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.