By default, the SELinux policy will only allow services access to recognized ports associated with those services:
# semanage port -l | egrep '(^http_port_t|6379)'
http_port_t tcp 80, 81, 443, 488, 8008, 8009, 8443, 9000
# curl http://localhost/redis.php
Cannot connect to redis server.
- add Redis port (6379) to SELinux policy
To check SELinux
To see what flags are set on httpd processes
getsebool -a | grep httpd
To allow Apache to connect to remote database through SELinux
setsebool httpd_can_network_connect_db 1
Use -P option makes the change permanent. Without this option, the boolean would be reset to 0 at reboot.
setsebool -P httpd_can_network_connect_db 1
SELinux is not namespaced, so individual containers cannot have their own separate SELinux policies. SELinux will always appear to be "disabled" in a container, though it is running on the host.
If your application requires SELinux, you cannot use it inside Docker. You will need to use a regular virtual machine.
It seems ridiculous that you can't set up a policy that allows nginx to write to a socket without first having an attempt denied and then running a tool that enables things that were denied.
Well no, SELinux is Mandatory Access Control, things are denied by default and you have to explicitly allow something. If the policy authors have not considered a ...
So I found that another service had a defined status for TCP port 5000.
But by replacing the -a option with -m for modify, added tcp port 5000 to http_port_t
So the command that worked was:
# semanage port -m -t http_port_t -p tcp 5000
As already stated, you should instruct SELINUX to allow writing to that file. The right thing to do is to mark /var/www/webapp/k/site/ as of type httpd_sys_rw_content_t
To permanently mark that directory as httpd_sys_rw_content_t, you can use the command semanage fcontext -a -t httpd_sys_rw_content_t /var/www/webapp/k/site(/.*)?; restorecon -RF /var/www/...
Yes, SELinux makes Red Hat (and any other Linux distribution that actually uses it) more secure, assuming it's actually in use.
SELinux implements mandatory access control. Normal Unix permissions, ACLs, etc., implement discretionary access control. The two complement each other.
In order to work, SELinux requires a policy, defining what actions on the ...
A SELinux policy module is built by following steps:
generate a set of policy rules: audit2allow
Assuming that I have a postgreylocal.te file with belows content:
module postgreylocal 1.0;
I've often encountered a similar bug on CentOS 6 machines involving ssh-copy-id and SELinux.
When ssh-copy-id creates the authorized keys files it creates it with the proper permissions, but with the wrong SELinux label. The fix for this is restoring the labels to their policy defaults using this command:
restorecon -R ~/.ssh
I was able to duplicate this issue in a freshly installed CentOS 7.5 system.
Here is what is happening:
When you boot with init=/bin/bash there are two issues you may run into:
The root filesystem may be mounted readonly. In this case passwd will complain of an Authentication token manipulation error.
This is pretty obvious: If the filesystem is not ...
According this issue report on the CentOS web site, this is caused by an upstream "feature" in SELinux; if SELinux is enforcing, it will prevent the server from using pubkey authentication. There is no indication that this behavior will change in the near future. To see if this problem applies to you, type sestatus and see if it reports "Current mode" as ...
These things are always much easier debugged from the server side, if that is possible. If you can start a sshd on another port in debug mode, it will tell you immediately why the key is being rejected (my wild guess is that your home directory is group writable). You can, for example, start a sshd in debug mode on port 2222 with /usr/sbin/sshd -d -p 2222, ...
The Actual Problem
To translate the second line of the log you provided:
The rotatelogs process with PID 64617 tried to search in the home directory, which is on device md2 and on inode 7208961. Access was denied.
The security context of the rotatelogs process is: unconfined_u:system_r:httpd_rotatelogs_t:s0
The security context of the home ...
The place to start is to look at your /var/log/audit/audit.log for AVC denied messages relating to mysqld. These can be passed to audit2why to gather more information to help you decide what to do.
You have your mysql files in a non standard location and although the directories have the correct context it's likely that the files in them are not. The best ...
Your VPS runs on OpenVZ, a container based "virtualization" which has no support for SELinux. If you need SELinux, you will need to switch to another hypervisor which supports SELinux in guests, such as Hyper-V, VMware, KVM, Xen, and possibly others.
Some of the commands to obtain this info are (examples use httpd_log_t):
# seinfo -x --type=httpd_log_t /etc/selinux/default/policy/policy.26
# sesearch --dontaudit -t httpd_log_t /etc/selinux/default/policy/policy.26 | head
Found 35 semantic av rules:
If you want to share files with multiple domains (Apache, FTP, rsync,
Samba), you can set a file context of public_content_t and public_content_rw_t.
These context allow any of the above domains to read the
content. If you want a particular domain to write to the public_con‐
tent_rw_t domain, you must set the ...
httpd_read_user_content allows any confined web server to read files in user home directories in /home.
httpd_enable_homedirs allows Apache to use its UserDir directive (i.e. URLs that look like http://www.example.com/~username/).
If you are just mapping domain names to users' directories, it should be sufficient to enable the first one, ...
The kernel makes the following procedure to determine what the file type of a newly created file will be.
There exists in policy a specific file transition rule. So apply this.
Make the newly created file acquire the type of the parent directory.
In the vast majority of cases, new files inherit the parent directories type. Sometimes this is not desirable --...
Not confirmed if this is the right answer yet...
/usr/sbin/semanage fcontext -a -t sysfs_t "/www(/.*)";
/usr/sbin/semanage fcontext -a -t httpd_sys_content_t "/www/live/.*/.*";
/usr/sbin/semanage fcontext -a -t httpd_log_t "/www/live/.*/logs(/.*)?";
/sbin/restorecon -vr "/www";
There the sysfs_t is the important bit.
I can find the domains that LogRotate ...
On the systems I have to hand (C6, C7 and F24), tcp port 5000 has an SELinux context of commplex_port_t. This will be why, when you try to add it you get the error message
/usr/sbin/semanage: Port tcp/5000 already defined
To change the context of tcp port 5000 from commplex_port_t to http_port_t you will need to use the -m | --modify switch
-m, --modify ...
You are quick to jump on SELinux....are you sure you have /etc/ssh/sshd_config properly set to allow root access via ssh? Have you restarted the sshd service if you have made any changes to the configuration files.
Have you tried setting SELinux to permissive and testing this.
You know, if SELinux was denying access I'd expect to see some type of AVC (...
After editing file /etc/sysconfig/selinux, for the changes to take effect, you need to reboot your system to get SELinux fully disabled. You can do setenforce 0 to get the system into "permissive" mode until a reboot occurs.
make sure you change SELinux=enforcing to SELinux=disabled
The script is in the policycoreutils-python:
[root@kerberos home]# rpm -qf /usr/sbin/semanage
Installing via yum will give you the following: