7.3 SEAlert
So what is SEalert? This is an alerting tool that shows us what went wrong with SELinux, why it is blocking our actions and how we can resolve this.
To use SEalert, we need to install setroubleshoot-server. We can do this with the dnf install setroubleshoot-server -y command. More about the dnf command in a later chapter.
The sealert command requires a GUI. However, most servers do not have a GUI (Graphical User Interface), but the sealert command can also be used on the server with the -a option to analyze specific files. The most common use case is with the /var/log/audit/audit.log file. This is where SELinux reports the actions it has taken.
[root@rhcsa ssh]# cd /var/log/audit/
[root@rhcsa audit]# sealert -a audit.log
This should give you quite a lot of output. However, it is pretty easy to separate incidents, because of a long line of --------------------------------------------------------- icons.
If you did not generate anymore SELinux incidents since chapter 7.2, the bottom incident should look something like this:
--------------------------------------------------------------------------------
SELinux is preventing /usr/sbin/sshd from getattr access on the file /etc/ssh/sshd_config.
***** Plugin restorecon (99.5 confidence) suggests ************************
If you want to fix the label.
/etc/ssh/sshd_config default label should be etc_t.
Then you can run restorecon. The access attempt may have been stopped due to insufficient permissions to access a parent directory in which case try to change the following command accordingly.
Do
# /sbin/restorecon -v /etc/ssh/sshd_config
***** Plugin catchall (1.49 confidence) suggests **************************
If you believe that sshd should be allowed getattr access on the sshd_config 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:
# ausearch -c 'sshd' --raw | audit2allow -M my-sshd
# semodule -i my-sshd.pp
Additional Information:
Source Context system_u:system_r:sshd_t:s0-s0:c0.c1023
Target Context system_u:object_r:admin_home_t:s0
Target Objects /etc/ssh/sshd_config [ file ]
Source sshd
Source Path /usr/sbin/sshd
Port <Unknown>
Host <Unknown>
Source RPM Packages openssh-server-7.4p1-21.el7.x86_64
Target RPM Packages openssh-server-7.4p1-21.el7.x86_64
Policy RPM selinux-policy-3.13.1-266.el7.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name rhcsa
Platform Linux rhcsa 3.10.0-1127.10.1.el7.x86_64 #1
SMP Wed Jun 3 14:28:03 UTC 2020 x86_64 x86_64
Alert Count 1
First Seen 2020-07-17 11:28:31 CEST
Last Seen 2020-07-17 11:28:31 CEST
Local ID e06ef18c-8fa8-432a-a2be-838304ebec5b
Raw Audit Messages
type=AVC msg=audit(1594978111.867:478): avc: denied { getattr } for pid=3176
comm="sshd" path="/etc/ssh/sshd_config" dev="sda2" ino=34185937
scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023
tcontext=system_u:object_r:admin_home_t:s0 tclass=file permissive=1
type=SYSCALL msg=audit(1594978111.867:478): arch=x86_64 syscall=fstat success=yes exit=0
a0=3 a1=7fff4d537880 a2=7fff4d537880 a3=0 items=0 ppid=1 pid=3176 auid=4294967295 uid=0
gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=sshd
exe=/usr/sbin/sshd subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)
Hash: sshd,sshd_t,admin_home_t,file,getattr
Well this gives alot of information, but if we start from the top it explains itself pretty easily. Lets analyse the output
Analyse the output from sealert
Below tells us that SELinux blocked the ssh service from reading its config file /etc/ssh/sshd_config and without the config file it can’t start.
SELinux is preventing /usr/sbin/sshd from getattr access on the file /etc/ssh/sshd_config.
The next part provides us a solution how to fix the incident that SELinux is reporting; which happens to be the solution we used. The restorecon command to fix the sshd_config file.
***** Plugin restorecon (99.5 confidence) suggests ************************
If you want to fix the label.
/etc/ssh/sshd_config default label should be etc_t.
Then you can run restorecon. The access attempt may have been stopped due to insufficient permissions to access a parent directory in which case try to change the following command accordingly.
Do
# /sbin/restorecon -v /etc/ssh/sshd_config
The next part is the system asking if the incident is valid, or if it is a bug which you might want to report. This is usually not the case, so this can mostly be ignored.
***** Plugin catchall (1.49 confidence) suggests **************************
If you believe that sshd should be allowed getattr access on the sshd_config 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:
# ausearch -c 'sshd' --raw | audit2allow -M my-sshd
# semodule -i my-sshd.pp
Next is a detailed description of the file and the server details. With this, you can check if you agree that the incident should have occured.
Additional Information:
Source Context system_u:system_r:sshd_t:s0-s0:c0.c1023
Target Context system_u:object_r:admin_home_t:s0
Target Objects /etc/ssh/sshd_config [ file ]
Source sshd
Source Path /usr/sbin/sshd
Port <Unknown>
Host <Unknown>
Source RPM Packages openssh-server-7.4p1-21.el7.x86_64
Target RPM Packages openssh-server-7.4p1-21.el7.x86_64
Policy RPM selinux-policy-3.13.1-266.el7.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name rhcsa
Platform Linux rhcsa 3.10.0-1127.10.1.el7.x86_64 #1
SMP Wed Jun 3 14:28:03 UTC 2020 x86_64 x86_64
Alert Count 1
First Seen 2020-07-17 11:28:31 CEST
Last Seen 2020-07-17 11:28:31 CEST
Local ID e06ef18c-8fa8-432a-a2be-838304ebec5b
And the last part is the information from the audit.log file that was used to generate this report.
Raw Audit Messages
type=AVC msg=audit(1594978111.867:478): avc: denied { getattr } for pid=3176
comm="sshd" path="/etc/ssh/sshd_config" dev="sda2" ino=34185937
scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023
tcontext=system_u:object_r:admin_home_t:s0 tclass=file permissive=1
type=SYSCALL msg=audit(1594978111.867:478): arch=x86_64 syscall=fstat success=yes exit=0
a0=3 a1=7fff4d537880 a2=7fff4d537880 a3=0 items=0 ppid=1 pid=3176 auid=4294967295 uid=0
gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=sshd
exe=/usr/sbin/sshd subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)
Hash: sshd,sshd_t,admin_home_t,file,getattr
If you want to, you can use the less command and the grep AVC command on the audit.log file to analyse the log itself. But this is a lot more complicated than reading the sealert report.
[root@rhcsa audit]# less audit.log | grep AVC