I was following this guide to install FreePBX on CentOS 6.9 (minimaslist), everything worked, until the last step to install FreePBX: ./install -n from /usr/src/freepbx, I keep getting the following error msg:
Assuming you are Database Root
Checking if SELinux is enabled...Error!
SELinux is enabled. Please disable SELinux before installing FreePBX.
I have disabled SELinux, by writing SELINUX=disabled in the following file /etc/sysconfig/selinux then rebooted, but I keep having the same problem.
For reference, here is the output of cat /etc/sysconfig/selinux:
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - No SELinux policy is loaded.
SELINUX=disabled
# SELINUXTYPE= can take one of these two values:
# targeted - Targeted processes are protected,
# mls - Multi Level Security protection.
SELINUXTYPE=targeted
I have found the solution, partially thanks to the #Dusan Bajic's comment, by running sestatus :
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: enforcing
Mode from config file: enforcing
Policy version: 24
Policy from config file: targeted
A quick search made me realise that in order to disable SELinux I have to modify /etc/selinux/config instead, doing that gave for sestatus:
SELinux status: disabled
Related
I am trying to configure mod_evasive in my CENTOS7 server (VPS) to prevent DDOS attacks.
I followed the steps mentioned in the following tutorial. (this link) Although I am not using IPTABLES, I am using firewalld instead.
In mod_evasive, the directive to execute a shell command when an IP is blacklisted is DOSSystemCommand. But when an IP is blocked, the script I want to run which will submit the IP address to firewalld to block, is blocked by SeLinux. According to what I understood after looking at the audit.log is, SeLinux does not allow apache user to run a command as sudo. Even though this is allowed via the sudoers file.
(mod_evasive is working properly, I verified this my running the test script provided by mod_evasive. I also get the email when an IP is blocked)
Following are the specifics;
mod_evasive.conf file (only the DOSSystemCommand directive shown below)
DOSSystemCommand "sudo /var/www/mod_evasive/ban_ip_mod_evasive.sh"
I have also tried the below variation (with different users too, Ex. root user)
DOSSystemCommand "sudo -u apache '/var/www/mod_evasive/ban_ip_mod_evasive.sh %s'"
Sudoers file (only the part I have modified for this purpose [allow apache to run as sudo)
apache ALL=(ALL) NOPASSWD:ALL
Defaults:apache !requiretty
I have allowed apache to run as any user for all scripts, just for testing purposes. Initially I had restricted the command as follows
apache ALL=NOPASSWD: /usr/local/bin/myscripts/ban_ip.sh
Defaults:apache !requiretty
My ban_ip.sh file
#!/bin/sh
# IP that will be blocked, as detected by mod_evasive
IP=$1
sudo firewall-cmd --add-rich-rule 'rule family="ipv4" source address="`$IP" service name="https" reject'
I have verified that the configuration is working by running the following
sudo -u apache '/usr/local/bin/myscripts/ban_ip.sh 111.111.111.111'
The above command successfully adds the rule to firewalld.
This entire setup works when I disable SeLinux.
After I enable SeLinux the following errors appear in the audit.log
type=AVC msg=audit(1593067671.808:1363): avc: denied { setuid } for pid=3332 comm="sudo" capability=7 scontext=system_u:system_r:httpd_sys_script_t:s0 tcontext=system_u:system_r:httpd_sys_script_t:s0 tclass=capability permissive=0
Was caused by:
Missing type enforcement (TE) allow rule.
You can use audit2allow to generate a loadable module to allow this access.
type=AVC msg=audit(1593067671.808:1364): avc: denied { setgid } for pid=3332 comm="sudo" capability=6 scontext=system_u:system_r:httpd_sys_script_t:s0 tcontext=system_u:system_r:httpd_sys_script_t:s0 tclass=capability permissive=0
Was caused by:
Missing type enforcement (TE) allow rule.
You can use audit2allow to generate a loadable module to allow this access.
The following flags are set in SeLinux
httpd_mod_auth_pam
httpd_setrlimit
I am not sure why SeLinux blocks this, therefore I am skeptical to create a custom policy to allow this behavior as audit2allow suggests.
audit2allow output
#============= httpd_sys_script_t ==============
allow httpd_sys_script_t self:capability { setgid setuid };
#============= httpd_t ==============
allow httpd_t systemd_logind_t:dbus send_msg;
I feel mod_evasive would not help in stopping a DDOS if we can not block the IP rather than merely sending a 403 forbidden response to the attacker. This will still consumer the server resources.
How can I solve this and what other alternatives I can implement to mitigate DDOS and enhance my VPS protection?
thanks for your help
I can use pg_ctlcluster ver cluster stop to stop the service of a given cluster but if the machine reboots it starts right back up again. I could do something like change the data directory in it's postgresql.conf file but that smells to me.
PostgreSQL installations that have pg_ctlcluster (Debian-based) look for a start.conf file in /etc/postgresql/<version>/<clustername> with these contents:
# Automatic startup configuration
# auto: automatically start/stop the cluster in the init script
# manual: do not start/stop in init scripts, but allow manual startup with
# pg_ctlcluster
# disabled: do not allow manual startup with pg_ctlcluster (this can be easily
# circumvented and is only meant to be a small protection for
# accidents).
auto
Put manual instead to avoid auto-starting at boot, per-cluster.
I'm using CentOS 7 via AWS.
I'd like to store MongoDB data on an attached EBS instead of the default /var/lib path.
However, when I edit /etc/mongod.conf to point to a new dbpath, I'm getting a permission denied error.
Permissions are set correctly to mongod.mongod on the dir.
What gives?
TL;DR - The issue is SELinux, which affects what daemons can access. Run setenforce 0 to temporarily disable.
You're using a flavour of Linux that uses SELinux.
From Wikipedia:
SELinux can potentially control which activities a system allows each
user, process and daemon, with very precise specifications. However,
it is mostly used to confine daemons[citation needed] like database
engines or web servers that have more clearly defined data access and
activity rights. This limits potential harm from a confined daemon
that becomes compromised. Ordinary user-processes often run in the
unconfined domain, not restricted by SELinux but still restricted by
the classic Linux access rights
To fix temporarily:
sudo setenforce 0
This should disable SELinux policies and allow the service to run.
To fix permanently:
Edit /etc/sysconfig/selinux and set this:
SELINUX=disabled
Then reboot.
The service should now start-up fine.
The data dir will also work with Docker, i.e. something like:
docker run --name db -v /mnt/path-to-mounted-ebs:/data/db -p 27017:27017 mongo:latest
Warning: Both solutions DISABLE the security that SELinux provides, which will weaken your overall security. A better solution is to understand how SELinux works, and create a policy on your new data dir that works with mongod. See https://wiki.centos.org/HowTos/SELinux for a more complete tutorial.
I am on a Windows7 machine and I'm trying to get graphic view on the centOS machine to be displayed on my current screen. When typing xclock, gedit... in terminal, I am getting the following error
-bash: xclock: command not found
and This the result of # vi /etc/ssh/sshd_config command
# Example of overriding settings on a per-user basis
#Match User anoncvs
# X11Forwarding no
# AllowTcpForwarding no
#tewayPorts no
#X11Forwarding no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
Also Xming is running on server:0.0 and I turned X11 forwarding on on putty
So what's the problem ?
sudo yum install xorg-x11-apps
Should cover it!
Do you have an .Xauthority file in your home directory?
I've recently found the answer for my issue, which might be similar to yours. I've seen quite a few open questions about this topic without resolution. You may have a few more things to work through, but SELinux settings ended up being my final hurdle. This among many other steps are covered here: ssh X11 forwarding won't work
That aside, you may need to change the Xming settings to match the default DisplayOffset of 10 for Centos. And after any changes to sshd_config, you'll need to restart the service via
/etc/init.d/sshd restart
I would like to emphasize that my situation is a non-critical operation within a (hopefully!) securely-managed intranet. I would NOT suggest turning off SELinux at work, or at home if you're hoping to open ports or configure VPN for your home network. Please consider: http://securityblog.org/2006/05/21/software-not-working-disable-selinux/
I am trying to COPY a file into a table in PostgreSQL. The table owner is postgres and the file owner is postgres.
The file is in /tmp.
Still I am getting the error message:
could not open file "/tmp/file" for reading: Permission denied
I don't understand what I am doing wrong as all the posts I've found say that if I have the file in /tmp and owner is postgres then the COPY command should work.
A guess: You are using Fedora, Red Hat Enterprise Linux, CentOS, Scientific Linux, or one of the other distros that enable SELinux by default.
Either and on your particular OS/version the SELinux policies for PostgreSQL do not permit the server to read files outside the PostgreSQL data directory, or the file was created by a service covered by a targeted policy so it has a label that PostgreSQL isn't allowed to read from.
You can confirm whether or not this is the problem by running, as root:
setenforce 0
then re-testing. Run:
setenforce 1
to re-enable SELinux after testing. setenforce isn't permanent; SELinux will be automatically re-enabled on reboot anyway. Disabling SELinux permanently is not usually a good solution for issues like this; if you confirm the issue is SELinux it can be explored further.
Since you have not specified the OS or version you are using, the PostgreSQL version, the exact command you're running, ls -al on the file, \d+ on the table, etc, it's hard to give any more detail, or to know if this is more than a guess. Try updating your answer to include all that and an ls --lcontext of the file too.
COPY with a file name instructs the PostgreSQL server to directly read from or write to a file. The file must be accessible by the PostgreSQL user (the user ID the server runs as) and the name must be specified from the viewpoint of the server. (source: postgresql documentation)
So the file should be readable (or writable) by the unix user under which postgresql server is running (i.e not your user!). To be absolutly sure, you can try to run sudo -u postgres head /tmp/test.csv (assuming you are allowed to used sudo and assuming the database user is postgres).
If that fails, it might be an issue related to SELinux (as mentioned by Craig Ringer). Under the most common SELinux policy (the "targeted" reference policy), used by Red Hat/Fedora/CentOS, Scientific Linux, Debian and others... the postgresql server process is confined : it can only read/write a few file types.
The denial might not be logged in auditd's log file (/var/log/audit/audit.log) due to a donaudit rule. So the usual SELinux quick test apply e.g: stop SELinux from confining any process by running getenforce;setengorce 0;getenforce, then test postgresql's COPY. Then re-activate SELinux by running setenforce 1 (this command modify the running state, not the configuration file, so SELinux will be active (Enforcing) after reboot.
The proper way to fix that is to change the SELinux context of the file to load. A quick hack is to run:
chcon -t postgresql_tmp_t /tmp/a.csv
But this file labelling will not survive if hte filesystem is relabel or if you create a new file. You will need to create a directory with an SELinux file context mapping :
which semanage || yum install policycoreutils-python
semanage fcontext -a -t postgresql_tmp_t '/srv/psql_copydir(/.*)?'
mkdir /srv/psql_copydir
chmod 750 /srv/psql_copydir
chgrp postgres /srv/psql_copydir
restorecon -Rv /srv/psql_copydir
ls -Zd /srv/psql_copydir
Any file created in that directory should have the proper file context automatically so postgresql server can read/write it.
(to check the SELinux context under which postgres is running, runps xaZ | grep "postmaste[r]" | grep -o "[a-z_]*_t", which should print postgresql_t. To list the context types to which postgresql_t can write, use sesearch -s postgresql_t -A | grep ': file.*write'. the command sesearch belong to the setools-console RPM package).