Description of problem: I've set up a few instances of TurboGears2 app servers living behind an Apache httpd, which proxies connections to virtual hosts to them listening on ports 8090, 8091, 8100, 8101. These instances run as normal users, and are started as systemd services. I needed to generate local policy which allows systemd (or alternatively, supervisord) to start them automatically. Version-Release number of selected component (if applicable): selinux-policy-targeted-3.9.16-50.fc15.noarch TurboGears2-2.1.1-1.fc15.noarch python-paste-script-1.7.3-7.fc15.noarch How reproducible: Reproducible Steps to Reproduce: 1. Set up a TG2 app server (as a normal user, "paster quickstart" with python-repoze-what-quickstart installed) 2. create a systemd service unit file for it :-) 3. "systemctl start <name>.service", wait a moment 4. systemctl status <name>.service Actual results: Fails to start properly, "ausearch -sv no -c paster -ts recent" returns not empty (can't change to certain directories, nor connect to the PostgreSQL database, nor bind ports, ...). Expected results: Starts properly, no hits with ausearch Additional info: Created this local policy module with audit2allow etc., which fixed this for me: module localpaster 1.0; require { type user_home_t; type postgresql_t; type user_home_dir_t; type home_root_t; type port_t; type postgresql_tmp_t; type smtp_port_t; type piranha_web_t; type httpd_user_content_t; class unix_stream_socket connectto; class tcp_socket { name_bind name_connect }; class file { write read getattr open }; class sock_file write; class dir { search read open getattr }; } #============= piranha_web_t ============== allow piranha_web_t home_root_t:dir { search getattr }; allow piranha_web_t httpd_user_content_t:dir { read search open getattr }; allow piranha_web_t httpd_user_content_t:file { read getattr open }; allow piranha_web_t port_t:tcp_socket name_bind; allow piranha_web_t postgresql_t:unix_stream_socket connectto; allow piranha_web_t postgresql_tmp_t:sock_file write; allow piranha_web_t smtp_port_t:tcp_socket name_connect; allow piranha_web_t user_home_dir_t:dir { search getattr }; allow piranha_web_t user_home_t:file write;
Well, I think the paster should not be labeled as piranha_web_exec_t. Could you attach raw AVC msgs? Also could you try to execute # chcon -t bin_t /usr/bin/paster
(In reply to comment #1) > Well, I think the paster should not be labeled as piranha_web_exec_t. > > Could you attach raw AVC msgs? You mean like in "ausearch -c paster -sv no ..."?
I mean AVC msgs related to your local policy. So for example # ausearch -m avc -su piranha_web_t which probably will match with your command.
Created attachment 550483 [details] avc messages (abridged, the original file was >15MB in size)
Ok, and if you execute # chcon -t bin_t /usr/bin/paster is your server running as initrc_t? # systemctl status <name>.service # ps -eZ |grep initrc
(In reply to comment #5) > Ok, and if you execute > > # chcon -t bin_t /usr/bin/paster > > is your server running as initrc_t? It is. NB: Setting correct component again. Stupid AJAX component switcher setting 0xFFFF on error considered stupid ;-).
> NB: Setting correct component again. Stupid AJAX component switcher setting > 0xFFFF on error considered stupid ;-). This is probably bug #553189. Miroslav, which browser do you use?
(In reply to comment #7) > > NB: Setting correct component again. Stupid AJAX component switcher setting > > 0xFFFF on error considered stupid ;-). > > This is probably bug #553189. Miroslav, which browser do you use? Good catch. I use Chromium.
(In reply to comment #6) > (In reply to comment #5) > > Ok, and if you execute > > > > # chcon -t bin_t /usr/bin/paster > > > > is your server running as initrc_t? > > It is. Which is better. I will need to change paster label back to bin_t. But the way how to use paster to create a daemon should be also changed. The problem is with -- [Service] ExecStart= -- where paster is used. We would need a script instead of executing of paster directly. Then we could label this script as turbogears_exec_t.
> where paster is used. We would need a script instead of executing of paster > directly. Then we could label this script as turbogears_exec_t. Luke, Toshio, could we put a generic script called e.g. "tg2-paster" into TurboGears2 (or "paster-serve" into python-paste-script) which would just dispatch to /usr/bin/paster and which could be labeled correctly for starting web apps from init?
(In reply to comment #10) > Luke, Toshio, could we put a generic script called e.g. "tg2-paster" into > TurboGears2 (or "paster-serve" into python-paste-script) which would just > dispatch to /usr/bin/paster and which could be labeled correctly for starting > web apps from init? That makes me think: perhaps /usr/bin/paster could detour via this "paster-serve" script so that we'd always get appropriate labels for "serving stuff to the world" vs. "doing administrative stuff which needs more privileges"? E.g. like this: 1) "/usr/bin/paster ..." detects some "serving" command e.g. "paster serve", execs "/usr/bin/paster-serve" (or "/usr/libexec/paster-serve") if PASTER_SERVING is not in the environment (to avoid loops). 2) paster-serve sets PASTER_SERVING in the environment, then re-execs /usr/bin/paster, policy allows the latter to inherit the label from the former 3) like 1), only PASTER_SERVING is now set and paster operates normally Luke, Toshio, Miroslav?
(In reply to comment #10) > > where paster is used. We would need a script instead of executing of paster > > directly. Then we could label this script as turbogears_exec_t. > > Luke, Toshio, could we put a generic script called e.g. "tg2-paster" into > TurboGears2 (or "paster-serve" into python-paste-script) which would just > dispatch to /usr/bin/paster and which could be labeled correctly for starting > web apps from init? This part sounds okay if it is sufficient to work. (I like the more generic paster-serve, personally). I think paste upstream is 1) dead 2) when it was alive, was resistant to changes that were only needed on one platform, so I'm not certain that it would be upstreamable but I think that it would be okay to carry a patch for this purpose. However, I'm not sure if all of those SELinux switches should be turned on at all sites. Perhaps some of them need to be SELinux Booleans (similar to the httpd booleans for accessing home directories, for instance).
I think every apps should do this magic (a generic script) on own site. Then we can add labels for these scripts per project and create a policy for them.
(In reply to comment #13) > I think every apps should do this magic (a generic script) on own site. Then we > can add labels for these scripts per project and create a policy for them. I'm not sure, as many apps are really custom-built and you, or selinux-policy wouldn't know about them. Contrasting, the use cases usually boil down to: - read files in your project root - occasionally write files into designated areas (probably needs labeling and/or boolean defaulting to off) - talk HTTP, to e.g. apache httpd reverse proxy, or even other app servers - talk to databases ... and seem generic enough to use a generic wrapper. To me anyway.
I missed your last comment. Ok, let's say we have piranha and your apps. Both use paster and will execute /usr/bin/paster-serve which has a label. This means they will have the same domain.
Re comment 15 > This means they will have the same domain. Which is not so optimal... do I read this right? I have some ideas here (with luci, we are also affected). Mirek, with your SELinux insights, how the delegation of context (or how to call it) works in case of shebang (#!)? Is there some update mechanism while proceeding the chain to execute, or the file used to launch it implies everything?
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached 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 to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. 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. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping