selinux September 2015

selinux@lists.fedoraproject.org

21 participants
21 discussions

http process running as initrc_t
by Divya Vyas 17 Sep '15

17 Sep '15

Hi, run_init /usr/sbin/httpd -k start leads to system_u:system_r:initrc_t:s0 root 3977 1 0 19:57 ? 00:00:00 /usr/sbin/httpd -k start It should be httpd_t sesearch -ACT -t httpd_exec_t has the transition type_transition initrc_t httpd_exec_t : process httpd_t;

3 2

MCS labels not being enforced
by Mario Rosic 17 Sep '15

17 Sep '15

Hello, I have trouble understanding how MCS labels work, they are not being enforced on my RHEL7 system even though selinux is "enforcing" and the policy used is "targeted". I don't think I should be able to access those files: backup@test ~ $ ls -lZ /tmp/accounts-users /tmp/accounts-admin -rw-rw-r--. backup backup guest_u:object_r:user_tmp_t:s0:c3 /tmp/accounts-admin -rw-rw-r--. backup backup guest_u:object_r:user_tmp_t:s0:c99 /tmp/accounts-users backup@test ~ $ id uid=1000(backup) gid=1000(backup) groups=1000(backup) context=guest_u:guest_r:guest_t:s0:c1 root@test ~ # getenforce Enforcing I can still access them even though they have different labels (c3 and c99 as opposed to my user having c1). backup@test ~ $ cat /tmp/accounts-users domenico balance: -30 backup@test ~ $ cat /tmp/accounts-admin don't lend money to domenico Am I missing something? More info: # semanage user -l SELinux User Prefix MCS Level MCS Range SELinux Roles guest_u user s0 s0-s0:c0.c10 guest_r # semanage login -l Login Name SELinux User MLS/MCS Range Service __default__ user_u s0 * backup guest_u s0:c1 * Regards, Mario R

3 5

Re: /etc/php.ini and /etc/php.d labelled as etc_t
by Douglas Brown 17 Sep '15

17 Sep '15

Hi all, Is there any reason why the php config files in /etc don’t have their own php_etc_t type in RHEL 6? Thanks, Doug

2 3

Policy for Consul (Hashicorp)
by Jeremy Young 16 Sep '15

16 Sep '15

Hello everyone, I'm preparing to deploy a Consul cluster for the company at which I work, and while perusing the documentation, found that I'd like to have SELinux policy around my deployment. I've attached my first shot, and would like some feedback as to whether or not this is redundant or too permissive. I admittedly don't yet know enough about the application to speak to whether or not this breaks functionality but am asking the Consul mailing list for feedback as well. Can I get some input on the policy? Thank you for your help! -- Jeremy Young

1 1

Prevent Apache from binding to port 80
by Mario Rosic 16 Sep '15

16 Sep '15

Hello, by default Apache is allowed to bind to Ports 80, 81, 443, 488, 8008, 8009, 8443, 9000. What if I want to further restrict that? I can't find a way of doing that with semanage port. "semanage port -d" only allows the deletion of additional ports that I assigned to http_port_t earlier, it does not remove Ports 80, 81, 443, 488, 8008, 8009, 8443, 9000 from http_port_t. Is it possible to do this with semanage or do I have to modify the policy code? Regards, Mario Rosic

2 1

Fwd: Can I change default policy from targeted to minimum
by Divya Vyas 14 Sep '15

14 Sep '15

Hi, I have mls and targeted policy installed on my system. I want to have a minimum policy with all user unconfined and nothing restricted. I took a minimum policy from selinux-policy-minium noarch rpm and kept in /etc/selinux folder and edit SELINUXTYPE=minimum. Is this enough to load a new policy . load_policy SELinux: Could not open policy file <= /etc/selinux/minimum/policy/policy.28: No such file or directory load_policy: Can't load policy: No such file or directory Getting this error while the policy.28 exists in the path. Please guide me to have a minimum unrestricted policy.

3 3

libselinux is a liar!!!
by Daniel J Walsh 13 Sep '15

13 Sep '15

http://danwalsh.livejournal.com/73099.html

1 0

Re: RHEL 6 Confined Users Running Third-Party Services
by Douglas Brown 11 Sep '15

11 Sep '15

Hi all, In a PaaS environment where service administrators are confined using RBACs on RHEL 6, how should third-party services be supported at scale? Allowing a confined user to execute any arbitrary executable that transitions to system_r:unconfined_t would make breaking out of the user’s confinement trivial. In this way, executenotrans seems to be the best approach (assuming the service administrator role isn’t too restrictive), but on boot the default inirc_exec_t service script label would cause the service to run in the unconfined initrc_t domain, whereas if the service was started by the user it would be in the service administrator’s domain, leading to inconsistent application of policy. The init_labeled_script_domtrans macro could be used to allow the service administrator role to use initrc_exec_t labelled service scripts, but that would allow service administrators to start/stop a number of managed system services. Furthermore, if the user started their service manually (ie. not via the service script), it too would lead to the same inconsistent application of policy as noted above. These issues are resolved in RHEL 7 with the use of systemd? Your thoughts would be much appreciated. Thanks, Doug

2 2

SELinux is preventing pyzor from getattr access on the file /usr/bin/rpm
by Tom Rivers 09 Sep '15

09 Sep '15

Hello! I have posted information regarding the error message I'm seeing at Github.com in the Pyzor forum located here: https://github.com/SpamExperts/pyzor/issues/41#issuecomment-135539930 Basically, I was looking at the output of "journalctl -f" on my Fedora 21 system while trying to fine tune SpamAssassin the other day and found the following: Aug 27 09:33:16 impact-crater.com spamd[20895]: spamd: processing message <20150827133258.6E19C61B70D1(a)bastion01.phx2.fedoraproject.org> for sa-milt:986 Aug 27 09:33:17 impact-crater.com python[22066]: detected unhandled Python exception in '/usr/bin/pyzor' Aug 27 09:33:17 impact-crater.com setroubleshoot[7528]: SELinux is preventing pyzor from getattr access on the file /usr/bin/rpm. For complete SELinux messages. run sealert -l 09532028-c2c0-472e-b39f-c52ef00c5dc6 Aug 27 09:33:17 impact-crater.com python[7528]: SELinux is preventing pyzor from getattr access on the file /usr/bin/rpm. Running the sealert command referenced above yields the following: SELinux is preventing pyzor from getattr access on the file /usr/bin/rpm. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that pyzor should be allowed getattr access on the rpm file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep pyzor /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:spamc_t:s0 Target Context system_u:object_r:rpm_exec_t:s0 Target Objects /usr/bin/rpm [ file ] Source pyzor Source Path pyzor Port <Unknown> Host impact-crater.com Source RPM Packages Target RPM Packages rpm-4.12.0.1-7.fc21.x86_64 Policy RPM selinux-policy-3.13.1-105.20.fc21.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name impact-crater.com Platform Linux impact-crater.com 4.1.5-100.fc21.x86_64 #1 SMP Tue Aug 11 00:24:23 UTC 2015 x86_64 x86_64 Alert Count 33 First Seen 2015-08-27 08:35:55 EDT Last Seen 2015-08-27 09:36:08 EDT Local ID 09532028-c2c0-472e-b39f-c52ef00c5dc6 Raw Audit Messages type=AVC msg=audit(1440682568.916:5869): avc: denied { getattr } for pid=22308 comm="pyzor" path="/usr/bin/rpm" dev="dm-1" ino=1977835 scontext=system_u:system_r:spamc_t:s0 tcontext=system_u:object_r:rpm_exec_t:s0 tclass=file permissive=0 Hash: pyzor,spamc_t,rpm_exec_t,file,getattr Here is some relevant system info with respect to the system in question: kernel-4.1.5-100.fc21.x86_64 pyzor-0.5.0-10.fc21.noarch Python 2.7.8 (default, Apr 15 2015, 09:26:43) [GCC 4.9.2 20150212 (Red Hat 4.9.2-6)] on linux2 One of the guys at Github who initially responded indicated that, "There's nothing in Pyzor that would try to access /usr/bin/rpm." Evidently SELinux is upset at something so I figured it would be a good idea to also post on this list to see if anyone here knows anything I can do to help identify what's happening. Thanks! Tom

4 10

"Missing" Audit logging in permissive mode
by Ted Rule 07 Sep '15

07 Sep '15

Whilst trying to debug a Web application recently, I had cause to temporarily run the httpd_t domain in permissive mode in order to work out what extra ACLs/Labels might be required. In the audit log I noticed that there appeared to be very few AVC messages compared to the number of files and directories created and modified by the httpd_t domain within a user_home_t subtree. Having built a little test-bed for the issue, I found that with the system in fully-enforcing mode, I got an AVC for every type of every file access denied, as expected. However, in permissive mode, what seems to happen is that the audit contains only the first AVC corresponding to any given "policy quadruple" of Source Domain, Target Domain, Target Class and Permission. If I re-ran the test script, the audit log for the same events was quiet, even if I used different filenames. If I run a different test trying "httpd_t, user_home_t, file, read" instead of "httpd_t, user_home_t, file, write" after having previously seen a single log entry for "httpd_t, user_home_t, file, read", then I DO see the "write" being logged, but again, it's only the first instance that gets logged. If I turn the permissive mode off and on again, and re-run the tests, I get another single AVC in the audit log for each "policy quadruple". My reading of the results I see so far is that the action of permitting but logging an action within the SELinux engine causes the corresponding "policy quadruple" to be somehow cached in the kernel state after the first log entry is created, but that subsequent actions are not logged if a cache entry already exists. This presumably relates to SELinux's Access Vector Cache, given what I read elsewhere. One thought was that the quietness in the log was related to SELinux trying to avoid overloading auditd with messages, and that perhaps the cached state might timeout, but this didn't seem to occur. The kernel/SELinux/audit packages on this CentOS6.7 machine, assuming that these are relevant, under this test were: kernel-2.6.32-573.3.1.el6.x86_64 selinux-policy-targeted-3.7.19-279.el6_7.4.noarch audit-2.3.7-5.el6.x86_64 Is this a known "feature" of the way permissive mode is meant to work, and/or is there some other way to flush what I presume to be the cached AVC status? -- Ted Rule Director, Layer3 Systems Ltd http://www.layer3.co.uk/

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

selinux September 2015