Hi List,
there are a loot of web administration frontends (plesk, confixx,
ispconfig, webmin, ..) out there and nearly all of them start with
disabling SELinux which I think is a bad idea.
On the other hand it is a bit tricky to get around the various issue. I
already started to read for example the "Fedora Core 5 SELinux FAQ"
which already solved me some issues but as well opened a lot of new
questions.
There are in generally two problems:
1. Installing the web frontend in an SELinux enabled environment
Mostly this is done by extracting a tar archive and then calling a
script that starts to copy several files and modify configuration files
of several deamons and restarting them.
I already figured out that if I modify the domain of the script, I get
less warnings:
/home/downloads # chcon -R -t bin_t install
/home/downloads # php install.php
a.) I am not sure if the domain 'bin_t' is Ok at all
b.) I still get a couple of warnings when the script try to restart the
daemons like
type=AVC msg=audit(1241722547.281:24545):
avc: denied { read write } for pid=29460
comm="restorecon" path="socket:[121254]" dev=sockfs ino=121254
scontext=unconfined_u:system_r:setfiles_t:s0
tcontext=unconfined_u:unconfined_r:unconfined_t:s0
tclass=unix_stream_socket
type=SYSCALL msg=audit(1241722547.281:24545):
arch=c000003e syscall=59 success=yes exit=0
a0=1d0a630 a1=1d0a6e0 a2=1cd8e70 a3=8 items=0
ppid=29415 pid=29460 auid=500 uid=0 gid=0 euid=0 suid=0
fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=2
comm="restorecon" exe="/sbin/setfiles"
subj=unconfined_u:system_r:setfiles_t:s0 key=(null)
type=AVC msg=audit(1241722547.726:24546):
avc: denied { read write } for pid=29463
comm="mysqld_safe" path="socket:[121254]" dev=sockfs ino=121254
scontext=unconfined_u:system_r:mysqld_safe_t:s0
tcontext=unconfined_u:unconfined_r:unconfined_t:s0
tclass=unix_stream_socket
type=SYSCALL msg=audit(1241722547.726:24546):
arch=c000003e syscall=59 success=yes exit=0
a0=1d0a630 a1=1d07070 a2=1cd8e70 a3=0 items=0
ppid=29415 pid=29463 auid=500 uid=0 gid=0 euid=0 suid=0
fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=2
comm="mysqld_safe" exe="/bin/bash"
subj=unconfined_u:system_r:mysqld_safe_t:s0 key=(null)
c.) I already tried to create a policy via
# audit2allow -m local -l -i /var/log/audit/audit.log > local.te
the resulting file already contain several entries like:
...
#============= ftpd_t ==============
allow ftpd_t unconfined_t:unix_stream_socket { read write };
#============= httpd_t ==============
allow httpd_t initrc_exec_t:dir search;
allow httpd_t unconfined_t:unix_stream_socket { read write };
#============= mysqld_safe_t ==============
allow mysqld_safe_t initrc_exec_t:dir { search getattr };
allow mysqld_safe_t unconfined_t:unix_stream_socket { read write };
...
but the 'unconfined_t' sounds like this rule would be now generated for
ALL and everybody but I only want to give this rights to the install
script. So I guess I have to create an own domain 'install_t' and then
set the domain of the 'install.php' to that domain.
2. Running the web application below the httpd domain
This is the second tricky part. If one get this tools installed properly
one get several warnings of the application accessing several parts
which a common httpd may not be allowed to. Maybe one idea might already
be to have a second apache daemon running for the administration
frontend that run under a different extended domain than the default
apache ... but already this is not obvious to handle.
What I already was able to barely solve was the following. There is a
custom logging tool inside of the 'httpd.conf' using a perl script and
looking like:
CustomLog "| /usr/sbin/vlogger -s access.log
-t \"%Y%m%d-access.log\" /var/log/webadmin/httpd"
combined_webadmin
This produced in the default setup already several errors leading to the
log file placed there to be not written by apache. A small check with ls
already showed me why:
# ls -alZ /var/log
...
drwx------ root root system_u:object_r:httpd_log_t:s0 httpd
drwxr-xr-x root root unconfined_u:object_r:unconfined_t:s0 webadmin
...
changing the user and the domain of that folder already solved the
problem that apache now could write there:
# chcon -R -u system_u webadmin
# chcon -R -u httpd_sys_content_rw_t webadmin
# ls -alZ /var/log
...
drwx------ root root system_u:object_r:httpd_log_t:s0 httpd
drwxr-xr-x root root system_u:object_r:httpd_sys_content_rw_t:s0
webadmin
The follow up problem now is that 'logrotate' throw now warning/errors
that it is unable to rotate the log in that folder. Unfortunately if I
change 'httpd_sys_content_rw_t' to 'httpd_log_t' apache refuse to write
to that folder or better say ... apache is calling '/usr/sbin/vlogger'
in the httpd domain which then is not allowed to write there.
So there are some questions:
a.) how to install those files and folders by the previous mentioned
'install.php' script with the proper rights and
b.) does the issue of the logger man that I need to create an own domain
or can I 'fix' it by just setting a different domain tag to
'/usr/sbin/vlogger'?
thx in adavance
Goetz
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
