sandbox -X broken on FC20?
by Robert Horovitz
Hi,
I'm using firefox in a sandbox.
It doesn't work anymore since today:
sandbox -X -t sandbox_web_t firefox
Failed to execute command /usr/share/sandbox/sandboxX.sh: Operation not
permitted
My installed versions:
policycoreutils-sandbox-2.2.5-3.fc20.x86_64
selinux-policy-targeted-3.12.1-153.fc20.noarch
libselinux-2.2.1-6.fc20.x86_64
libselinux-python-2.2.1-6.fc20.x86_64
libselinux-utils-2.2.1-6.fc20.x86_64
selinux-policy-3.12.1-153.fc20.noarch
Anyone having the same problem? Or a fix?
thanks!
Robert
8 years, 9 months
F2FS selinux contexts
by Brian Chadwick
Hi ... Fedora 20 here ... I am trying to get selinux-contexts working
with a F2FS filesystem . .
I have recompiled the kernel with f2fs security labels selected.
on mounting dmesg reports: .[ 8575.016144] SELinux: initialized (dev
sda6, type f2fs), not configured for labeling ... and consequently file
contexts aren't working
Is this something to do with fs_use_xattr in filesystem.te in
selinux-policy?
... is there a runtime fix or does this require recoding sections of
selinux-policy and recompiling.
someone also mentioned to e something about "ocontext" ... I have no
idea what that is
Thanks in advance
Brian
8 years, 11 months
X sandbox still broken in Fedora 20
by Florian Weimer
Running "sandbox -X -t sandbox_web_t xterm", I get this audit entries,
and the command exits without printing anything:
type=AVC msg=audit(1402310641.114:1228): avc: denied { connectto } for
pid=19943 comm="Xephyr" path=002F746D702F2E5831312D756E69782F5830
scontext=unconfined_u:unconfined_r:sandbox_web_t:s0:c38,c325
tcontext=system_u:system_r:xserver_t:s0-s0:c0.c1023
tclass=unix_stream_socket
type=SYSCALL msg=audit(1402310641.114:1228): arch=c000003e syscall=42
success=no exit=-13 a0=0 a1=7fffa6343c70 a2=14 a3=7fffa63439d0 items=0
ppid=19934 pid=19943 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000
fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=1 comm="Xephyr"
exe="/usr/bin/Xephyr"
subj=unconfined_u:unconfined_r:sandbox_web_t:s0:c38,c325 key=(null)
Relevant package versions:
libcap-ng-0.7.4-1.fc20.x86_64
policycoreutils-python-2.2.5-4.fc20.x86_64
selinux-policy-targeted-3.12.1-166.fc20.noarch
Downgrading to libcap-ng-0.7.3-6.fc20.x86_64 fixes this for me.
Does anybody else see this? If not, what might be causing this problem?
--
Florian Weimer / Red Hat Product Security Team
8 years, 12 months
Allowing httpd restart a service
by Watts M.R.
I am currently trying to setup the ‘nconf’ package (http://www.nconf.org/dokuwiki/doku.php); a configuration generator for Nagios/Icinga.
This is essentially a PHP/MySQL application which provides a GUI to create and deploy configuration files – we use it to manage Icinga configurations.
One of the capabilities this tool has is to automatically reload/restart Icinga after deploying a new config.
I’m struggling to get this part working in a sensible way with SELinux in enforcing mode.
Typically, everything works in permissive mode.
System is CentOS 6.5 with selinux-policy-targeted-3.7.19-231.el6_5.3.noarch
Nconf is configured to call "/usr/bin/sudo /etc/init.d/icinga reload"
Currently I have the following in /etc/sudoers:
Defaults:apache !requiretty
apache ALL=(root) NOPASSWD: /etc/init.d/icinga reload
The CGI script which calls this command is set with the httpd_sys_script_exec_t type.
The target directory for the configuration files (/etc/icinga/nconf) is set to public_content_rw_t
Execution of this script works up to a point; configuration file deployment works but restarting the service does not.
In the web interface we see the following:
sudo: unable to stat /var/db/sudo: Permission denied
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.
sudo: no tty present and no askpass program specified
We see the following denies in the audit.log:
type=AVC msg=audit(1401963326.235:38): avc: denied { sys_ptrace } for pid=1500 comm="sudo" capability=19 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:httpd_t:s0 tclass=capability
type=AVC msg=audit(1401963326.237:39): avc: denied { getattr } for pid=1500 comm="sudo" path="/etc/rc.d/init.d/icinga" dev=dm-0 ino=918346 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:initrc_exec_t:s0 tclass=file
type=AVC msg=audit(1401963326.238:40): avc: denied { getattr } for pid=1500 comm="sudo" path="/etc/rc.d/init.d/icinga" dev=dm-0 ino=918346 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:initrc_exec_t:s0 tclass=file
type=AVC msg=audit(1401963326.238:41): avc: denied { getattr } for pid=1500 comm="sudo" path="/etc/rc.d/init.d/icinga" dev=dm-0 ino=918346 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:initrc_exec_t:s0 tclass=file
type=AVC msg=audit(1401963326.239:42): avc: denied { getattr } for pid=1500 comm="sudo" path="/var/db/sudo" dev=dm-4 ino=259 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:sudo_db_t:s0 tclass=dir
type=AVC msg=audit(1401963326.255:46): avc: denied { getattr } for pid=1506 comm="sudo" path="/etc/rc.d/init.d/icinga" dev=dm-0 ino=918346 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:initrc_exec_t:s0 tclass=file
type=AVC msg=audit(1401963326.255:47): avc: denied { getattr } for pid=1506 comm="sudo" path="/etc/rc.d/init.d/icinga" dev=dm-0 ino=918346 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:initrc_exec_t:s0 tclass=file
type=AVC msg=audit(1401963326.256:48): avc: denied { getattr } for pid=1506 comm="sudo" path="/etc/rc.d/init.d/icinga" dev=dm-0 ino=918346 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:initrc_exec_t:s0 tclass=file
type=AVC msg=audit(1401963326.257:49): avc: denied { getattr } for pid=1506 comm="sudo" path="/var/db/sudo" dev=dm-4 ino=259 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:sudo_db_t:s0 tclass=dir
audit2allow suggests the use of the following:
allow httpd_t initrc_exec_t:file getattr;
allow httpd_t self:capability sys_ptrace;
allow httpd_t sudo_db_t:dir getattr;
Is this a sensible fix or is there a better way to approach this issue?
Regards,
Mark.
--
Mark Watts
Infrastructure Engineer, iSolutions
University of Southampton
Tel: (02380) 595788 Int: 25788
8 years, 12 months
