Maja Wolniewicz wrote:

I'm testing the v3.0.x branch - FreeRADIUS Version 3.1.0 (git #21acbbf)

That isn't the v3.0.x branch. 3.1.0 is the "master" branch.

rpm -q --changelog openssl | grep CVE-2014-0160 - fix CVE-2014-0160 - information disclosure in TLS heartbeat extension

I'm getting Refusing to start with libssl version OpenSSL 1.0.1e-fips 11 Feb 2013 0x01000105f (1.0.1e-15) (in range 1.0.1-0 - 1.0.1f-15)

Yes. And if you read the NEXT message that the server prints out, it tells you how to work around the issue. There is no way for FreeRADIUS to tell that OpenSSL has been fixed. You have to configure the server to accept the problematic version of OpenSSL. Alan DeKok.

Maja, If you don't want to store the CUI in a SQL database (which is what it's trying to do), edit /etc/raddb/policy.d/cui and comment out the last three lines in the cui.post-auth stanza. :-) Stefan -----Original Message----- From: freeradius-users-bounces+stefan.paetow=ja.net@lists.freeradius.org [mailto:freeradius-users-bounces+stefan.paetow=ja.net@lists.freeradius.org] On Behalf Of Maja Wolniewicz Sent: 16 April 2014 19:33 To: FreeRadius users mailing list Subject: Re: Imminent release of 2.2.5 and 3.0.3 W dniu 16.04.2014, 17:03, Alan DeKok pisze:

Maja Wolniewicz wrote:

...

I'm testing the v3.0.x branch - FreeRADIUS Version 3.1.0 (git #21acbbf) That isn't the v3.0.x branch. 3.1.0 is the "master" branch. Right. I forgot to do git checkout -b v3.0.x origin/v3.0.x

Now I have another problem. The cui module is enabled (I have the link in mods-enabled), sql module isn't cui module instantiates the sql module with name cuisql. When starting radiusd I can see: # Instantiating module "cuisql" from file /opt/FR3.0/etc/raddb/mods-enabled/cui sql cuisql { driver = "rlm_sql_mysql" server = "localhost" port = "" login = "" password = <<< secret >>> radius_db = "radius" ... } while my mods-enabled/cui settings are different and the shown settings come from mods-available/sql Maja -- Maja Gorecka-Wolniewicz mgw@umk.pl Uczelniane Centrum Information & Communication Informatyczne Technology Centre Uniwersytet Mikolaja Kopernika Nicolaus Copernicus University Coll. Maximum, pl. Rapackiego 1, 87-100 Torun, Poland tel.: +48 56-611-27-40 fax: +48 56-622-18-50 tel. kom.: +48-693032574 Janet(UK) is a trading name of Jisc Collections and Janet Limited, a not-for-profit company which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238

Oh I see. Sorry, my misunderstanding. Stefan -----Original Message----- From: freeradius-users-bounces+stefan.paetow=ja.net@lists.freeradius.org [mailto:freeradius-users-bounces+stefan.paetow=ja.net@lists.freeradius.org] On Behalf Of Maja Wolniewicz Sent: 17 April 2014 11:52 To: FreeRadius users mailing list Subject: Re: Imminent release of 2.2.5 and 3.0.3 W dniu 17.04.2014 12:40, Stefan Paetow pisze:

Maja,

If you don't want to store the CUI in a SQL database (which is what it's trying to do), edit /etc/raddb/policy.d/cui and comment out the last three lines in the cui.post-auth stanza. I know that, but I want to store the CUI. I think that this problem with cuisql could mean that there is a general problem with instantiating sql module

Maja

:-)

Stefan

-----Original Message----- From: freeradius-users-bounces+stefan.paetow=ja.net@lists.freeradius.org [mailto:freeradius-users-bounces+stefan.paetow=ja.net@lists.freeradius .org] On Behalf Of Maja Wolniewicz Sent: 16 April 2014 19:33 To: FreeRadius users mailing list Subject: Re: Imminent release of 2.2.5 and 3.0.3

W dniu 16.04.2014, 17:03, Alan DeKok pisze:

...

Maja Wolniewicz wrote:

...

I'm testing the v3.0.x branch - FreeRADIUS Version 3.1.0 (git #21acbbf) That isn't the v3.0.x branch. 3.1.0 is the "master" branch. Right. I forgot to do git checkout -b v3.0.x origin/v3.0.x

Now I have another problem. The cui module is enabled (I have the link in mods-enabled), sql module isn't cui module instantiates the sql module with name cuisql. When starting radiusd I can see: # Instantiating module "cuisql" from file /opt/FR3.0/etc/raddb/mods-enabled/cui sql cuisql { driver = "rlm_sql_mysql" server = "localhost" port = "" login = "" password = <<< secret >>> radius_db = "radius" ... }

while my mods-enabled/cui settings are different and the shown settings come from mods-available/sql

Maja

-- Maja Gorecka-Wolniewicz mgw@umk.pl Uczelniane Centrum Information & Communication Informatyczne Technology Centre Uniwersytet Mikolaja Kopernika Nicolaus Copernicus University Coll. Maximum, pl. Rapackiego 1, 87-100 Torun, Poland tel.: +48 56-611-27-40 fax: +48 56-622-18-50 tel. kom.: +48-693032574 Janet(UK) is a trading name of Jisc Collections and Janet Limited, a not-for-profit company which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238

W dniu 20.04.2014 23:27, Alan DeKok pisze:

Maja Wolniewicz wrote:

...

The cui module is enabled (I have the link in mods-enabled), sql module isn't cui module instantiates the sql module with name cuisql. When starting radiusd I can see: # Instantiating module "cuisql" from file /opt/FR3.0/etc/raddb/mods-enabled/cui sql cuisql { driver = "rlm_sql_mysql" server = "localhost" port = "" login = "" password = <<< secret >>> radius_db = "radius" ... }

while my mods-enabled/cui settings are different and the shown settings come from mods-available/sql I don't see that at all. Are you sure you're using the right files? The default file raddb/mods-available/cui has:

dialect = "sqlite" driver = "rlm_sql_${dialect}" sqlite { filename = ${radacctdir}/cui.sqlite bootstrap = ${modconfdir}/${..:name}/cui/sqlite/schema.sql } I want to use the mysql driver, so I have there: dialect = "mysql" driver = "rlm_sql_${dialect}" mysql{ server = "localhost" login = "cuiuser" password = "....." radius_db = "eduroam" } and this file is linked in mod-enabled directory. This configuration does not work for me - the cuisql module is configured with a default 'radius' database. I used this configuration in my tests of the CUI some time ago and then it worked (it was FR3.0 git version). Is such a configuration good now? Is the sub-module model still working? Another thing that worries me is that when I'm trying to authenticate the server returns Access-Reject, in spite of PEAP success: (10) eap_peap : Success (10) eap_peap : Using saved attributes from the original Access-Accept Stripped-User-Name = 'mgw' Chargeable-User-Identity := '0e4114dc9ad1ac345c09e54c5e0fa4a1d04eb9da' (10) eap_peap : Saving session 4b43ce6e71f5ad08815e7a467eaa5e382e615376601e74388686c0748838c91c vps 0x1131ea0 in the cache (10) eap : Freeing handler (10) [eap] = ok (10) } # authenticate = ok (10) # Executing section post-auth from file /opt/FR3.0/etc/raddb/sites-enabled/default (10) post-auth { (10) cui.post-auth cui.post-auth { (10) if (!control:Proxy-To-Realm && Chargeable-User-Identity && !reply:Chargeable-User-Identity && (Operator-Name || ('no' != 'yes')) ) (10) if (!control:Proxy-To-Realm && Chargeable-User-Identity && !reply:Chargeable-User-Identity && (Operator-Name || ('no' != 'yes')) ) -> FALSE (10) update reply { (10) EXPAND %{reply:User-Name} (10) --> (10) User-Name -= '""' (10) } # update reply = noop (10) if (reply:Chargeable-User-Identity) (10) if (reply:Chargeable-User-Identity) -> TRUE (10) if (reply:Chargeable-User-Identity) { (10) cuisql : EXPAND .query (10) cuisql : --> .query (10) cuisql : Using query template 'query' rlm_sql (cuisql): Opening additional connection (0) rlm_sql_mysql: Starting connect to MySQL server rlm_sql_mysql: Couldn't connect socket to MySQL server @localhost:radius rlm_sql_mysql: Mysql error 'Access denied for user 'root'@'localhost' (using password: NO)' rlm_sql_mysql: Socket destructor called, closing socket rlm_sql (cuisql): Opening connection failed (0) (10) [cuisql] = fail (10) } # if (reply:Chargeable-User-Identity) = fail (10) } # cui.post-auth cui.post-auth = fail (10) } # post-auth = fail (10) Using Post-Auth-Type Reject (10) # Executing group from file /opt/FR3.0/etc/raddb/sites-enabled/default (10) Post-Auth-Type REJECT { .. } Sending Access-Reject of id 10 from 158.75.1.116 port 1812 to 158.75.1.40 port 41997 When the cuisql module is commented out authentication goes smoothly. Maja

Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

-- Maja Gorecka-Wolniewicz mgw@umk.pl Uczelniane Centrum Information & Communication Informatyczne Technology Centre Uniwersytet Mikolaja Kopernika Nicolaus Copernicus University Coll. Maximum, pl. Rapackiego 1, 87-100 Torun, Poland tel.: +48 56-611-27-40 fax: +48 56-622-18-50 tel. kom.: +48-693032574

Refusing to start with libssl version OpenSSL 1.0.1e-fips 11 Feb 2013 0x01000105f (1.0.1e-15) (in range 1.0.1-0 - 1.0.1f-15)

Hi Maja, that is expected. You should use openssl-1.0.1e-16 (which RHEL/CentOS have had since the day after Heartbleed). This however will not stop the server check, for that you must set allow_vulnerable_openssl in radius.conf to yes. Regards Stefan Janet(UK) is a trading name of Jisc Collections and Janet Limited, a not-for-profit company which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238

On 17/04/14 01:09, Arran Cudbard-Bell wrote:

Their arguments for applying patches to already released systems are bullshit. It makes it impossible to tell whether a given version of a library has the correct fixes applied.

Many, many people pay considerable quantities of money for long-term distros to do *exactly* what you're criticising. Personally I think the LTS distros provide a really useful buffer between open source projects and customers. This allows the project to proceed at the pace they want, and LTS customers to PAY someone to do the boring work of keeping an older, stable version secure against newly discovered bugs. I wonder if this checking for "bad" libraries inside FR is really useful or appropriate, especially if it's causing you major hassles. It's not obvious to me why OpenSSL is special - where's the blacklist for glibc or libpq or $whatever? Are other projects doing this? I think you guys already do more than enough - way more than most projects - to provide long-term stable releases. I don't think you need to do more, and I certainly don't think you need to be cleaning up OpenSSL's mess. That way lies moral hazard! Just my €0.03

Nick Lowe wrote:

I agree entirely with what Phil says. Is this not a layering violation? As much as you think you might be helping in this belt-and-braces way, I don't think it should be the concern of FreeRADIUS to care about this - and how far do you take it?

The goal is to have FreeRADIUS be secure. i.e. there is no installation which defaults to insecure. The way we do this is to either disable features, or disable vulnerabilities.

I am also curious who might actually tangibly benefit. Isn't the reality that a version of FreeRADIUS that contains these checks will only ever get packaged by the distributions with a non-vulnerable version of OpenSSL going forward anyway in a new major release that they make?

Most of the time, yes. But not everyone uses packages. Security is about *always* being secure. You don't say "well, this won't happen often, so we can ignore it". Alan DeKok.

There aren't massive security holes in other libraries. I'm not sure if other projects are doing this. I know for my sanity, I don't want people blaming FreeRADIUS because they've chosen to use a vulnerable version of OpenSSL.

Well, I doubt anyone reasonably active on the list will, and with sufficient disclaimers on the site, it's good enough what you do/have done.

Which will happen if FR doesn't check for "bad" versions of OpenSSL.

See above.

I'm more concerned with ongoing tests. I've spent much of the last two months adding more sanity checks to the parser, and then adding tests for the parser and sanity checks. That will do more than anything else to prevent future issues.

The good news is that Heartbleed has shocked the OpenSSL people into asking for more help, and it also has prompted people into starting a crowd-funded effort to audit OpenSSL and improve its... *ahem* code quality. So I'm fairly positive that this is going to improve things in the future. Stefan Janet(UK) is a trading name of Jisc Collections and Janet Limited, a not-for-profit company which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238

Hi,

...

I wonder if this checking for "bad" libraries inside FR is really useful or appropriate, especially if it's causing you major hassles. It's not obvious to me why OpenSSL is special - where's the blacklist for glibc or libpq or $whatever? Are other projects doing this?

There aren't massive security holes in other libraries. I'm not sure if other projects are doing this. I know for my sanity, I don't want people blaming FreeRADIUS because they've chosen to use a vulnerable version of OpenSSL.

ISC do similar thign with OpenSSL for named and have done so for years. alan

Phil Mayers wrote:

I do find it really very sad they're using open-source software and don't feel they can do:

./configure --prefix=/opt/fr-$version make make install

It's "policy". The system needs to be "stable", so it can't be upgraded. But they're looking for help, because the system doesn't work the way they want... which means it's not really "stable". This is the same attitude I saw at a previous company. We did a static analysis of the code base. When it found bugs (lots), the "senior" developers said in a review meeting: "We shouldn't change the code, because changing code creates bugs." I just looked at them, in awe of the blinding stupidity of the statement. Needless to say, FreeRADIUS uses static analysis. Alan DeKok.

On 18/04/2014 21:30, Stefan Paetow wrote:

Ouch!

You have misinterpreted the essence and scope of my complaint. I've got no problem with people who run LTS distros and vendor packages - we do that. It's extremely common, and I think it's a very sensible default, and that the LTS distros provide, in the main, a good service. I've got no (big) problem with people who mandate vendor packages entirely. I think the legit reasons for that are very few, and I think a lot of the time it's done for wrong reasons - "because ITIL" or "because PCI" - but regardless of what *I* think, that is a choice people are entitled to make themselves. (I will say that if "stability" is an argument, then you MUST presumably have local testing and signoff procedures. If so, it's unclear to me why those can't be used to Q&A a local rebuild, but I'm prepared to accept there are reasons. Like I said, local choice) The problem I have is people coming for free help, then rejecting the answers they get because they want to keep the old version that they are PAYING for support on. That is impolite and, arguably more important, it allows unfriendly vendors to free-ride and hides information from friendly vendors about customer priorities. Asking for help intially is fine, and asking for help building a new version is fine. If you can't or won't build a new version, the right thing to do is thank the free support for their time, then indicate you'll push your vendor to do what they're being paid to do. Hope this is clear. Regards, Phil

As the person starting the distribution thread by posting about having trouble with Ubuntu 12.04 LTS and FR 3.0.3 git version I certainly did not mean to start such a long thread. I encountered a problem and reported it, if I understood how to change the dependency in the debian package build stuff I would have happily done that. Since the thread went in the direction that it did I am in the process of upgrading to Ubuntu 14.04. Yeah I know it is bleeding edge, but since I am in the process of commissioning a new radius server I will have the opportunity to test it before I make it go live so decided why not. For the record I had no problem with the idea of building my own packages and that is exactly what I was trying to do when I encountered issues. For the limited number of radius servers I have it is really not a big deal having to do more manually on those machines, I was hoping to not need to install the build tools on all of the machines and just install the package. I will let everyone know how I fair with 14.04. I understand the desire for stability with LTS distributions which is part of the reason I started with that, however, I wanted to use a newer FR version than was available. I guess I wanted to have the best of both and it seems that I cannot do that. I am not really sure how staying in the same version number (1.0.1) with only a letter change is going to be less stable than bringing a patch for a bug back to an older version without an easily and reliable way to make sure the bug is fixed. If it was going from version 1.0.1 to version 3.0.1 yeah, I could see that being a problem. Now maybe OpenSSL's version numbering is insane in which case going from f to g might be that big of a change, but that becomes a problem with OpenSSL's version numbers. I do appreciate the efforts of those who have poured many hours of time into getting FR to where it is today. Michael