On Sun, 7 Oct 2012, Elio Tondo wrote:
> On 07/10/2012 02:20, Tom Eastep ha wrote:
>
>> On 10/6/12 7:57 AM, [email protected] wrote:
>>>
>>> Are there some simple work around to use shorewall without disable
>>> selinux in Centos 6.3?
>>> ...
>>> Permission denied at /usr/share/shorewall/Shorewall/Config.pm line ...
>>
>> I just upgraded my 6.2 installation to 6.3 and I'm not seeing any
>> issues. As I recall, I had issues after installing 6.2; I simply ran the
>> selinux troubleshooting application and followed the instructions.
>
> I can confirm that I am running shorewall-4.5.4-1.el6.noarch from EPEL on a
> CentOS 6.3 x86_64 box with selinux in enforcing mode, with no problems at all.
>
> You can try "restorecon -vn /usr/share/shorewall/" that should do no
> modification, listing only any file that is not correctly labeled; the same
> command without the n flag would fix any error.
>
> Anyway, there is something strange in the message you see: in a normal
> installation there is no file named /usr/share/shorewall/Shorewall/Config.pm
> because there is no /usr/share/shorewall/Shorewall/ directory.
Ok, back to the right console ;-)
# rpm -qa|grep shorewall
shorewall-core-4.5.8-0base.noarch
shorewall-4.5.8-0base.noarch
# setenforce 1
[root@server Bk-D]# /etc/init.d/shorewall restart
Compiling...
Can't exec "/usr/lib/shorewall/getparams": Permission denied at
/usr/share/perl5/Shorewall/Config.pm line 4135.
ERROR: Processing of /etc/shorewall/params failed
# setenforce 0
# /etc/init.d/shorewall restart
Compiling...
Shorewall configuration compiled to /var/lib/shorewall/.restart
Restarting Shorewall....
done.
Not tried using shorewall from epel as Elio say; simply fetched last rpm
from the official ftp.
Surely it only a simple question of selinux tuning, but I haven't done
great investigation (I'm not an selinux guru and not tried something
related in a quick Internet and docs search).
The CentOS 6.3 box is a simple "Basic Server" install with some additional
standard packages. No strange confs.
# uname -a
Linux server 2.6.32-279.9.1.el6.x86_64 #1 SMP Tue Sep 25 21:43:11 UTC 2012
x86_64 x86_64 x86_64 GNU/Linux
The box doesn't have nor X neither setroubleshoot installed.
I install setroubleshoot, but I am not an selinux guru, so the
interpretation of the "human-readable format" of audit.log isn't an
activity than I consider myself reliable :-) so, better to report to
someone more reliable than me in this :-)
Tried to limit to the shorewall part, but ... I think you know selinux
better than me ... ;-)
--
Regards,
Paolo
____________________________________________
found 3 alerts in /var/log/audit/audit.log-121008shore
--------------------------------------------------------------------------------
SELinux is preventing /bin/bash from search access on the directory
/BK/Bk-D.
***** Plugin restorecon (82.4 confidence) suggests ***********************
If you want to fix the label.
/BK/Bk-D default label should be default_t.
Then you can run restorecon.
Do
# /sbin/restorecon -v /BK/Bk-D
***** Plugin file (7.05 confidence) suggests *****************************
If this is caused by a newly created file system.
Then you need to add labels to it.
Do
/sbin/restorecon -R -v /BK/Bk-D
***** Plugin file (7.05 confidence) suggests *****************************
If you think this is caused by a badly mislabeled machine.
Then you need to fully relabel.
Do
touch /.autorelabel; reboot
***** Plugin catchall_labels (4.59 confidence) suggests ******************
If you want to allow bash to have search access on the Bk-D directory
Then you need to change the label on /BK/Bk-D
Do
# semanage fcontext -a -t FILE_TYPE '/BK/Bk-D'
where FILE_TYPE is one of the following: cert_type, dirsrv_var_run_t,
abrt_var_run_t, abrt_var_run_t, nscd_var_run_t, nslcd_var_run_t,
slapd_var_run_t, sysctl_kernel_t, sssd_var_lib_t, sysctl_crypto_t,
httpd_sys_content_t, cfengine_var_lib_t, setrans_var_run_t, var_lock_t,
sysctl_t, sysctl_t, abrt_t, bin_t, bin_t, shorewall_t, lib_t, mnt_t,
root_t, winbind_var_run_t, tmp_t, tmp_t, tmp_t, usr_t, usr_t, var_t,
var_t, var_t, device_t, device_t, devpts_t, locale_t, shorewall_tmp_t,
etc_t, etc_t, sssd_public_t, proc_t, proc_t, logfile, shorewall_etc_t,
shorewall_log_t, likewise_var_lib_t, krb5_conf_t, rpm_script_tmp_t,
sysctl_net_t, security_t, default_t, modules_object_t,
shorewall_var_lib_t, rpm_tmp_t, var_lib_t,
var_lib_t, var_run_t, var_run_t, var_run_t, shorewall_lock_t,
abrt_var_cache_t,
configfile, domain, proc_net_t, rpm_log_t, var_log_t, samba_var_t,
avahi_var_run_t, ulogd_var_log_t, net_conf_t, nscd_var_run_t,
pcscd_var_run_t, bin_t, root_t, var_t, var_t, device_t, devpts_t,
var_run_t, var_run_t.
Then execute:
restorecon -v '/BK/Bk-D'
***** Plugin catchall (1.31 confidence) suggests *************************
If you believe that bash should be allowed search access on the Bk-D
directory 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 shorewall /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
--------------------------------------------------------------------------------
SELinux is preventing /bin/bash from search access on the directory /BK.
***** Plugin restorecon (82.4 confidence) suggests ***********************
If you want to fix the label.
/BK default label should be default_t.
Then you can run restorecon.
Do
# /sbin/restorecon -v /BK
***** Plugin file (7.05 confidence) suggests *****************************
If this is caused by a newly created file system.
Then you need to add labels to it.
Do
/sbin/restorecon -R -v /BK
***** Plugin file (7.05 confidence) suggests *****************************
If you think this is caused by a badly mislabeled machine.
Then you need to fully relabel.
Do
touch /.autorelabel; reboot
***** Plugin catchall_labels (4.59 confidence) suggests ******************
If you want to allow bash to have search access on the BK directory
Then you need to change the label on /BK
Do
# semanage fcontext -a -t FILE_TYPE '/BK'
where FILE_TYPE is one of the following: cert_type, dirsrv_var_run_t,
abrt_var_run_t, abrt_var_run_t, nscd_var_run_t, nslcd_var_run_t,
slapd_var_run_t, sysctl_kernel_t, sssd_var_lib_t, sysctl_crypto_t,
httpd_sys_content_t, cfengine_var_lib_t, setrans_var_run_t, var_lock_t,
sysctl_t, sysctl_t, abrt_t, bin_t, bin_t, shorewall_t, lib_t, mnt_t,
root_t, winbind_var_run_t, tmp_t, tmp_t, tmp_t, usr_t, usr_t, var_t,
var_t, var_t, device_t, device_t, devpts_t, locale_t, shorewall_tmp_t,
etc_t, etc_t, sssd_public_t, proc_t, proc_t, logfile, shorewall_etc_t,
shorewall_log_t, likewise_var_lib_t, krb5_conf_t, rpm_script_tmp_t,
sysctl_net_t, security_t, default_t, modules_object_t,
shorewall_var_lib_t, rpm_tmp_t, var_lib_t,
var_lib_t, var_run_t, var_run_t, var_run_t, shorewall_lock_t,
abrt_var_cache_t,
configfile, domain, proc_net_t, rpm_log_t, var_log_t, samba_var_t,
avahi_var_run_t, ulogd_var_log_t, net_conf_t, nscd_var_run_t,
pcscd_var_run_t, bin_t, root_t, var_t, var_t, device_t, devpts_t,
var_run_t, var_run_t.
Then execute:
restorecon -v '/BK'
***** Plugin catchall (1.31 confidence) suggests **************************
If you believe that bash should be allowed search access on the BK
directory 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 shorewall /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
--------------------------------------------------------------------------------
SELinux is preventing /usr/bin/perl from execute_no_trans access on the
file /usr/lib/shorewall/getparams.
***** Plugin leaks (86.2 confidence) suggests ****************************
If you want to ignore perl trying to execute_no_trans access the getparams
file, because you believe it should not need this access.
Then you should report this as a bug.
You can generate a local policy module to dontaudit this access.
Do
# grep /usr/bin/perl /var/log/audit/audit.log | audit2allow -D -M mypol
# semodule -i mypol.pp
***** Plugin catchall (14.7 confidence) suggests *************************
If you believe that perl should be allowed execute_no_trans access on the
getparams 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 perl /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users
