Initial context for init
by Philip Seeley
Hi all,
Quick question is:
In the targeted policy should init run SystemHigh as it does in the mls
policy?
The background:
We're setting up a targeted system where we confine all users and remove
the unconfined policy module, but we also enable polyinstantiation of /tmp
and /var/tmp.
If we ssh in as a staff_u user phil and elevate to root/sysadm_r then we
have a context of:
staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023
And therefore /var/tmp is:
drwxrwxrwt. root root system_u:object_r:tmp_t:s0-s0:c0.c1023 /var/tmp
Which is really:
drwxrwxrwt. root root
system_u:object_r:tmp_t:s0-s0:c0.c1023 /var/tmp-inst/system_u:object_r:tmp_t:s0-s0:c0.c1023_phil
The real /var/tmp is:
drwxrwxrwt. root root system_u:object_r:tmp_t:s0 /var/tmp
Now if we use run_init to update an RPM that contains a post install
script, rpm can't create the temporary script file:
# run_init bash -c 'rpm -i
--force /root/libselinux-2.0.94-7.el6.x86_64.rpm'
Authenticating phil.
Password:
error: error creating temporary file /var/tmp/rpm-tmp.atkHTf: Permission
denied
error: Couldn't create temporary file for %post
(libselinux-2.0.94-7.el6.x86_64): Permission denied
Note: you need to use run_init as the rpm might restart a service, e.g. the
sssd rpm.
We've traced this to the /etc/selinux/targeted/contexts/initrc_context file
which contains:
system_u:system_r:initrc_t:s0
So we transition to initrc_t and then to rpm_t without any categories, but
because the polyinstantiated /var/tmp directory has c0.c1023 we get denied.
Normally in targeted init runs unconfined, but we've removed this.
type=AVC msg=audit(1467342325.016:716): avc: denied { read } for
pid=2779 comm="rpm" name="system_u:object_r:tmp_t:s0-s0:c0.c1023_phil"
dev=dm-0 ino=1966082 scontext=system_u:system_r:rpm_t:s0
tcontext=system_u:object_r:tmp_t:s0-s0:c0.c1023 tclass=dir
It works if we change initrc_context to:
system_u:system_r:initrc_t:s0-s0:c0.c1023
We don't see the issue under mls because the default initrc_context is:
system_u:system_r:initrc_t:s0-s15:c0.c1023
We've traces this back through the selinux-policy src RPM and to the
upstream refpolicy and see that config/appconfig-mcs/initrc_context is:
system_u:system_r:initrc_t:s0
whereas config/appconfig-mls/initrc_context is:
system_u:system_r:initrc_t:s0-mls_systemhigh
So under mls init's context is SystemHigh, but under mcs/targeted it
doesn't have any categories.
So the long question is should config/appconfig-mcs/initrc_context really
be:
system_u:system_r:initrc_t:mcs_systemhigh
as it seems odd that the more secure mls policy would run init at
SystemHigh but targeted doesn't.
Thanks
Phil Seeley
4 years, 4 months
Re: RHEL 7 consoletype_exec interface issue
by Douglas Brown
Hi,
In RHEL 7 when using the userdom_unpriv_user_template interface to create a new role, it in turn uses the consoletype_exec interface; but when I attempt to insert a policy compiled with this, it says the type consoletype_exec_t doesn’t exist.
N.B. This works on RHEL 6.
Thanks,
Doug
6 years, 8 months
How to allow nginx communicate with python application over socket?
by Yuri Kanivetsky
Hi,
I'm trying to make nginx talk to an app over socket. Actually, I seem
to have succeeded, but I'm concerned if the policy I installed is a
good one.
Here's what I see in audit.log when nginx tries to connect to my app:
type=AVC msg=audit(1473789962.311:2330): avc: denied { write } for
pid=16814 comm="nginx" name="a1.sock" dev="dm-0" ino=525810
scontext=system_u:system_r:httpd_t:s0
tcontext=system_u:object_r:httpd_sys_content_t:s0 tclass=sock_file
type=SYSCALL msg=audit(1473789962.311:2330): arch=c000003e syscall=42
success=no exit=-13 a0=d a1=188a730 a2=6e a3=7ffde6992400 items=0
ppid=16813 pid=16814 auid=4294967295 uid=995 gid=993 euid=995 suid=995
fsuid=995 egid=993 sgid=993 fsgid=993 tty=(none) ses=4294967295
comm="nginx" exe="/usr/sbin/nginx" subj=system_u:system_r:httpd_t:s0
key=(null)
And here's what audit2allow has generated:
module nginx 1.0;
require {
type httpd_t;
type httpd_sys_content_t;
class sock_file write;
}
#============= httpd_t ==============
allow httpd_t httpd_sys_content_t:sock_file write;
The question is, "Is httpd_sys_content_t an appropriate type for the
task?" Is there the one, that suits better? Or should I create a
separate one?
Regards,
Yuri
7 years, 2 months
emby-server on f24
by Isaac Hailperin
Hi,
I am trying to get emby-server to run on f24 with selinux in enforcing mode
(which was fine on f23).
Now I am getting denials:
Sep 11 14:32:40 sh01 audit[796]: AVC avc: denied { create } for pid=796
comm="emby-server.sh" name="emby-server.log"
scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:var_log_t:s0 tclass=file permissive=0
Sep 11 14:32:40 sh01 audit[796]: AVC avc: denied { getattr } for pid=796
comm="emby-server.sh" path="/usr/bin/su" dev="dm-0" ino=1580514
scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:su_exec_t:s0 tclass=file permissive=0
Sep 11 14:32:40 sh01 audit[796]: AVC avc: denied { getattr } for pid=796
comm="emby-server.sh" path="/usr/bin/su" dev="dm-0" ino=1580514
scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:su_exec_t:s0 tclass=file permissive=0
audit2allow gives me the following policy:
#============= init_t ==============
allow init_t su_exec_t:file getattr;
allow init_t var_log_t:file create;
I am wondering what this implies. Just guessing, this would allow anything
which is started at boot time to use "su" and create a log file in
/var/log. I would not mind the latter, but the former seems a bit too broad
from a security perspective.
What other options do I have? Any recommendations?
Isaac
7 years, 3 months
qemu 9p/virtfs and selinux
by lejeczek
hi all,
I'm trying qemu's virtfs passthrough, first time but pretty
regular setup, and guests mount that mount tag, I can list
in a guest mountpoint's content, I see files & dirs but when
I try to add/create/remove content in the mountpoint then it
gets denied:
$ touch DDD
touch: setting times of `DDD': No such file or directory
I believe I've fished out all selinux denials, also have
disabled silent denials, I see no selinux denials in logs
yet that kvm guest still cannot write to that passed-through
host's filesystem.
Would you have some suggestions how to troubleshoot?
many thanks.
L
7 years, 3 months
