SELinux isn’t a technology that’s easy to tackle for newcomers. However, there’s been a lot of work to smooth out the rough edges while still keeping a tight grip on what applications and users are allowed to do on a Linux system. One of the biggest efforts has been around setroubleshoot.
The purpose behind setroubleshoot is to let users know when access has been denied, help them resolve it if necessary, and to reduce overall frustration while working through tight security restrictions in the default SELinux policies. The GUI frontend for setroubleshoot is great for users who run Linux desktops or those who run servers with a display attached. Don’t worry, you can configure setroubleshoot on remote servers to send alerts elsewhere when a GUI alert isn’t an option.
Install a few packages to get started:
|
1 |
yum install setroubleshoot{-server,-plugins,-doc} |
Open /etc/setroubleshoot/setroubleshoot.conf in your favorite text editor and adjust the [email] section to fit your server:
|
1 2 3 4 5 |
recipients_filepath = /var/lib/setroubleshoot/email_alert_recipients smtp_port = 25 smtp_host = localhost from_address = selinux@myserver.com subject = [MyServer] SELinux AVC Alert |
You could probably see it coming, but you need to put the e-mail addresses for your recipients into /var/lib/setroubleshoot/email_alert_recipients:
|
1 |
You’ll notice that setroubleshoot doesn’t have an init script and it doesn’t exist in systemd in Fedora 15. It runs through the dbus-daemon and a quick bounce of the messagebus via its init script brings in the necessary components to run setroubleshoot:
|
1 |
service messagebus restart |
A really easy (and safe) test is to ask sshd to bind to a non-standard port. Simply define an additional port on in your /etc/ssh/sshd_config like this:
|
1 2 |
Port 22 Port 222 |
When you restart sshd, it will bind to port 22 with success, but it won’t be allowed to bind to port 222 (since that’s blocked by SELinux as a non-standard port for the ssh_port_t port type). DON’T WORRY! Your sshd server will still be listening on port 22. If you wait a moment, you’ll get an e-mail (perhaps two) that not only notify you of the denial, but they make suggestions for how to fix it:
|
1 2 3 4 5 6 7 8 9 |
SELinux is preventing /usr/sbin/sshd from name_bind access on the tcp_socket port 222. ***** Plugin bind_ports (99.5 confidence) suggests ************************* If you want to allow /usr/sbin/sshd to bind to network port 222 Then you need to modify the port type. Do # semanage port -a -t PORT_TYPE -p tcp 222 where PORT_TYPE is one of the following: ... |
For this particular example, the quick fix would be to run:
|
1 |
semanage port -a -t ssh_port_t -p tcp 222 |
Much of this post’s information was gathered from the detailed documentation on Fedora’s setroubleshoot User’s FAQ as well as Dan Walsh’s setroubleshoot blog post.
Definitely an interesting read. It looks like selinux is your new baby, eh? :) Looks fun. I’ll give it a whirl one of these days.
I recommend allways to turn on SELinux in all servers that I have under my responsability (CentOS, Red Hat, even Debian), but this advice is simpy awesome. I have to manage a large number of servers and this trick can help to divide the work between the other guys that I manage, sending the right message to the right person.
Thanks a lot for share it with us.
Note: I twitted this blog post to all my fellows.
Marcos –
Thanks for the comment! I’m glad the post helped!
Cheers for this.
Perhaps this may be helpful for others.
# bin/selinux_emails.sh
echo Set to permissive or enforcing in /etc/sysconfig/selinux/config
vi /etc/sysconfig/selinux/config
echo Check out the SELinux boolean settings in use
getsebool -a | grep httpd
yum install setroubleshoot{-server,-plugins,-doc}
echo Set email settings in /etc/setroubleshoot/setroubleshoot.conf
echo being reciepiets_file_path and subject server
vi /etc/setroubleshoot/setroubleshoot.conf
echo “[email protected]”
hostname>> /var/lib/setroubleshoot/email_alert_recipientsservice messagebus restart
If you are having trouble making this work (no email sent/received) then read this:
http://blog.slacknet.ca/planet-cdot/selinuxs-setroubleshoot-install-on-a-rhel6-server/
In summary you may just need to restart auditd.
If you are on a systemd system you will find this can’t be done using systemctl – service auditd restart will work however (horrid reasoning).
Rather than restarting the sshd with an altered configuration, I find on Oracle Linux 7 that ~/.ssh/authorized_keys can be used to trigger alerts:
# ll -Z
-rw-r–r–. luser lgrp unconfined_u:object_r:home_root_t:s0 authorized_keys
-rw——-. luser lgrp unconfined_u:object_r:ssh_home_t:s0 authorized_keys.orig
-rw-r–r–. luser lgrp unconfined_u:object_r:home_root_t:s0 known_hosts
Attempts by the keypair against authorized keys will generate denials and alerts until “chcon -t ssh_home_t authorized_keys” is executed.
It would be interesting to see what is necessary to get these alerts inside of an nspawn where busybox is acting as init. I use those from time to time for Oracle database recoveries.
My intial reaction to seeing this post was: “Wow, finally I can make SELinux a bit more maintainable”
Then I saw that there is no way to set authentication for SMTP…
I shouldn’t have raised my expectations for selinux -.-
dermaniac, use the local mta (sendmail/postfix)?