Skip to main content

Bash Script debugging and SELinux

OpenVPN can launch a script client-connect each time a client connect to the VPN.
The script used to work when OpenVPN is launched directly, but not when launched via /etc/init.d/openvpn start ...

A good way to debug is to put this at the beginning of the file:
exec > /tmp/debug.$$ 2>&1; set -x

Reading the /tmp/ will give a first hint: "Permission denied" when trying to launch "/bin/mail" in the script.

I put a ME=$(whoami) in the script but both (working and non-working) returned the same: nobody. So, it leaves only one suspect: SELinux. (I didn't though about SELinux because I didn't see it in the services. But it is there, in the Kernel.)

Quick info about SELinux:
  • sestatus to get information
  • setenforce Permissive will give only warning (it creates less problems than disabling it).
  • /usr/sbin/selinuxenabled && SEL="SELinux ON" to use in scripts.

To be really sure, I did the following:
# ls -Z /etc/init.d/openvpn gives: system_u:object_r:openvpn_initrc_exec_t:s0
# ls -Z myTest               gives: unconfined_u:object_r:openvpn_etc_t:s0

My test script runs "unconfined". If I copy the openvpn script into my folder while preserving the context cp -c ..., I change the content to be the same as my old working script and re-launch. It doesn't work anymore.
Conclusion: the file's context will confine openvpn so that the script it launches will fail to uses /bin/mail.

Solution 1 :
The "hard way" is to try to patch the policy to workaround your case:
$ grep client-connect /var/log/audit/audit.log | audit2allow -M openvpn_cc
This will create two files: a .pp to be run and a .te for your reading pleasure.
install the module: semodule -i openvpn_cc.pp

It goes a little further, but still fails and if you look at the policy in the .te file, it is quite complicated.
(I didn't repeat the process audit2allow ... to get further, but I guess that ultimately it would have worked.)

Solution 2:
Create a policy to send mail:

$ vi openvpn_cc.te
policy_module(openvpn_cc, 1.0)
require {
        type openvpn_t;

Compile: make -f /usr/share/selinux/devel/Makefile openvpn_cc.pp
Install: semodule -i openvpn_cc.pp

Simple and it works.



Unknown said…
Tried solution 2 in CentOS 7 and it works perfectly - thanks!

Popular posts from this blog

VirtualBox, CentOS, Network and Template

I have been working with VirtualBox and CentOS recently, here are some notes about this experience.
I used VirtualBox 4.2 and CentOS 6.3, but most of this should work with other products too. I created the first headless, minimal CentOS via NetInstall.
I cover two points: create a template machine and configure the Network.
Configure the NetworkWe want Internet access and a LAN local to the host.
For background information read: Networking in VirtualBox by Fat Bloke on June 2012.
The easiest is to enable two Network Adapters: One will be "Host-only" and the second "Nat". In the "Preference" menu you can see the DHCP server range for the Host-only Network. So you may set fixed addresses outside this range.
Next: start the guest. There may be various results at first, depending on a lot of things. Some problem might be solved by rm -f /etc/udev/rules.d/70-persistent-net.rules and a reboot.
Anyway, configure the two interfaces (set your own IP and MAC addresses)…

One in six IT projects ends up ‘out of control’

A surprisingly high number of projects are 'ticking time bombs', according to researchers at the University of Oxford. They analysed 1,500 global projects that had revamped their information technology systems within the last 10 years. They discovered that one in six projects in the sample went over budget by an average of 200 per cent (in real terms) or over ran by an average of almost 70 per cent.

Their conclusion is similar to previous studies:

TLS: Disabling legacy cipher suites

First: "A cipher suite is a named combination of authentication, encryption, and message authentication code (MAC) algorithms".If you are using TLS (for HTTPS typicaly) you may want to remove some Cipher Suites.You maybe a little bit less compatible, but also a bit more secure. Things will be better when TLS1.2 is implemented everywhere.You can also claim to be FIPS 140 compliant: !How to do it:From the command line: code: Look at the "ciphers" attribute in someone knows how to do it on the IBM J9 via configuration, I am interested.