http process running as initrc_t
by Divya Vyas
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;
8 years, 7 months
MCS labels not being enforced
by Mario Rosic
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
8 years, 7 months
Policy for Consul (Hashicorp)
by Jeremy Young
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
8 years, 7 months
Prevent Apache from binding to port 80
by Mario Rosic
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
8 years, 7 months
Fwd: Can I change default policy from targeted to minimum
by Divya Vyas
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.
8 years, 7 months
Re: RHEL 6 Confined Users Running Third-Party Services
by Douglas Brown
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
8 years, 7 months
SELinux is preventing pyzor from getattr access on the file /usr/bin/rpm
by Tom Rivers
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
8 years, 7 months
"Missing" Audit logging in permissive mode
by Ted Rule
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/
8 years, 7 months
