I've just finished building freeradius 2.2.9 from source on an Ubuntu 15.04 Server. Comments here are so other looking for info can find it here. I came across a few issues that one might want to solve in source or wiki. 1 - Build failed because it was unable to locate : /usr/include/isql.h There is an old thread on this list about removing the smart try entry but it now actually fails because of that removal. It is located on /usr/include/iodbc/isql.h on Ubuntu 15.04. (upgraded from 14.10) I had to enter the source of : freeradius-server-2.2.9/src/modules/rlm_sql/drivers/rlm_sql_iodbc/configure search for isql.h and change the data just above it to : smart_try_dir="$iodbc_include_dir /usr/include/iodbc /usr/local/iodbc/include" 2 - Dependancies were quite a few missing : quilt for one.. they are not all installed by apt-get build-dep freeradius but need to be installed apt-get install quilt 3 - Lots of errors caused by systemctl taking over on Ubuntu and service start/stop not functioning. Also caused by 4. 4- It will also fail to start because of openssl versioning : Put : allow_vulnerable_openssl = yes under Security in /etc/freeradius/radius.conf Hope this helps someone in the future.. Arjan Sinnige
It will also fail to start because of openssl versioning : Put : allow_vulnerable_openssl = yes under Security in /etc/freeradius/radius.conf
No. Read the debug output and see what CVE code is worried about and put only that in the allow_vulnerable..... string otherwise your leaving yourself open to all kinds of future things if your openssl doesn't get patched. That change certainly isn't going to be standard in the distro. Blame openssl and the distros for their naming convention :/ alan
On 10-10-15 18:44, Alan Buxey wrote:
It will also fail to start because of openssl versioning : Put : allow_vulnerable_openssl = yes under Security in /etc/freeradius/radius.conf
No. Read the debug output and see what CVE code is worried about and put only that in the allow_vulnerable..... string otherwise your leaving yourself open to all kinds of future things if your openssl doesn't get patched. That change certainly isn't going to be standard in the distro. Blame openssl and the distros for their naming convention :/
To be honest, these are the kinds of bugs where I trust my distro to have a fixed version before I've had the chance of compiling a new FreeRADIUS, just to discover that it won't start because it thinks the OpenSSL version is vulnerable. The OpenSSL version check might be useful for installations where you have a manual installation of OpenSSL, but as long as you're using OpenSSL from a supported distro (like Debian or Ubuntu), I don't think the checks in FreeRADIUS have any added value. -- Herwin Weststrate
I felt this at the time that the checks were introduced. Most people will be using distribution supplied versions of OpenSSL that will get patched in a way that FreeRADIUS cannot easily check. I don't think it should be FreeRADIUS's concern if a supporting library is -potentially- vulnerable.
On Oct 12, 2015, at 5:29 AM, Herwin Weststrate <herwin@quarantainenet.nl> wrote:
To be honest, these are the kinds of bugs where I trust my distro to have a fixed version before I've had the chance of compiling a new FreeRADIUS, just to discover that it won't start because it thinks the OpenSSL version is vulnerable.
FreeRADIUS thinks OpenSSL may be vulnerable because we want to err on the side of security. Anything else is bad practice.
The OpenSSL version check might be useful for installations where you have a manual installation of OpenSSL, but as long as you're using OpenSSL from a supported distro (like Debian or Ubuntu), I don't think the checks in FreeRADIUS have any added value.
Which is why you can do: ./configure --disable-openssl-version-check Alan DeKok.
participants (5)
-
Alan Buxey -
Alan DeKok -
Arjan Sinnige -
Herwin Weststrate -
Nick Lowe