Re: radiusd-freeradius history and future

[Javier Fernández-Sanguino Peña]

On Sun, Jan 12, 2003 at 01:21:53PM -0500, Chad Miller wrote:
> [cc debian-devel]
> 
> On Sun, Jan 12, 2003 at 05:07:41PM +0100, Toni Mueller wrote:
> >  [...]  Who withdrew [radiusd-freeradius] or caused it's
> > withdrewal, then? Curious minds want to know, and also, it's a bit
> > misty right now...
(...)
> 
> A few months ago, the Sarge release coordinator swept all gravely-buggy-
> older-than-3?-months packages from sid, including radiusd-freeradius.
> Wichert immediately asked for the package to be added back, but someone
> noted that freeradius, a GPL program, linked against libssl, so it
> couldn't go back in.

What is the current status of this issue? There are yet no 
radiusd-freeradius (or freeradius) packages either in sid or (even) in 
ftp://ftp.freeradius.org/pub/radius/. The issue on SSL linking (described 
in DWN [1]) doesn't look as it is has been fixed and the debian/ directory 
in the CVS has not seen any change for quite some time (+5 months)

Anyone?

Regards

Javi


[1] http://www.debian.org/News/weekly/2003/02/

Re: radiusd-freeradius history and future

[Chad Miller]

On Tue, Nov 11, 2003 at 10:13:22AM +0100, Javier Fern?ndez-Sanguino Pe?a wrote:
> On Sun, Jan 12, 2003 at 01:21:53PM -0500, Chad Miller wrote:
> > [cc debian-devel]
> > 
> > On Sun, Jan 12, 2003 at 05:07:41PM +0100, Toni Mueller wrote:
> > >  [...]  Who withdrew [radiusd-freeradius] or caused it's
> > > withdrewal, then? Curious minds want to know, and also, it's a bit
> > > misty right now...
> (...)
> > 
> > A few months ago, the Sarge release coordinator swept all gravely-buggy-
> > older-than-3?-months packages from sid, including radiusd-freeradius.
> > Wichert immediately asked for the package to be added back, but someone
> > noted that freeradius, a GPL program, linked against libssl, so it
> > couldn't go back in.
> 
> What is the current status of this issue? There are yet no 
> radiusd-freeradius (or freeradius) packages either in sid or (even) in 
> ftp://ftp.freeradius.org/pub/radius/. The issue on SSL linking (described 
> in DWN [1]) doesn't look as it is has been fixed and the debian/ directory 
> in the CVS has not seen any change for quite some time (+5 months)


Hi Javi.  I don't use RADIUS servers any more, so I've lost interest in
maintaining FreeRADIUS.  Someone in the freeradius-devel list (I don't
remember who, atm) seemed interested in packaging it, at least with a
sponsor.  

- chad

-- 
Chad Miller GPG: 9E6947D9Jabber: [EMAIL PROTECTED] (not email)
 et c. @ http://wiki.chad.org/ChadMiller 


pgp9Fp0QOOPsN.pgp
Description: PGP signature

Re: radiusd-freeradius history and future

[Steve Langasek]

On Tue, Nov 11, 2003 at 10:13:22AM +0100, Javier Fernández-Sanguino Peña wrote:
> On Sun, Jan 12, 2003 at 01:21:53PM -0500, Chad Miller wrote:
> > [cc debian-devel]
> > 
> > On Sun, Jan 12, 2003 at 05:07:41PM +0100, Toni Mueller wrote:
> > >  [...]  Who withdrew [radiusd-freeradius] or caused it's
> > > withdrewal, then? Curious minds want to know, and also, it's a bit
> > > misty right now...
> (...)

> > A few months ago, the Sarge release coordinator swept all gravely-buggy-
> > older-than-3?-months packages from sid, including radiusd-freeradius.
> > Wichert immediately asked for the package to be added back, but someone
> > noted that freeradius, a GPL program, linked against libssl, so it
> > couldn't go back in.

> What is the current status of this issue? There are yet no 
> radiusd-freeradius (or freeradius) packages either in sid or (even) in 
> ftp://ftp.freeradius.org/pub/radius/. The issue on SSL linking (described 
> in DWN [1]) doesn't look as it is has been fixed and the debian/ directory 
> in the CVS has not seen any change for quite some time (+5 months)

The packages at  will be sponsored
into the archive as soon as I've had a chance to review them (this
week).

-- 
Steve Langasek
postmodern programmer


pgp0dD2oxGG9R.pgp
Description: PGP signature

Re: radiusd-freeradius history and future

[Matt Zimmerman]

On Tue, Nov 11, 2003 at 11:52:00AM -0600, Steve Langasek wrote:

> The packages at  will be sponsored into
> the archive as soon as I've had a chance to review them (this week).

This thing is packed full of strcpy() and strcat(), which is the sort of
sloppiness that I don't like to see in a network server.  It was a great
blessing to find that we weren't shipping this in woody when the last batch
of security problems was discovered.

Have mercy...

-- 
 - mdz

Re: radiusd-freeradius history and future

[Paul Hampson]

On Tue, Nov 11, 2003 at 10:13:22AM +0100, Javier Fernández-Sanguino Peña wrote:
> On Sun, Jan 12, 2003 at 01:21:53PM -0500, Chad Miller wrote:
> > [cc debian-devel]

> > On Sun, Jan 12, 2003 at 05:07:41PM +0100, Toni Mueller wrote:
> > >  [...]  Who withdrew [radiusd-freeradius] or caused it's
> > > withdrewal, then? Curious minds want to know, and also, it's a bit
> > > misty right now...
> (...)

> > A few months ago, the Sarge release coordinator swept all gravely-buggy-
> > older-than-3?-months packages from sid, including radiusd-freeradius.
> > Wichert immediately asked for the package to be added back, but someone
> > noted that freeradius, a GPL program, linked against libssl, so it
> > couldn't go back in.

> What is the current status of this issue? There are yet no 
> radiusd-freeradius (or freeradius) packages either in sid or (even) in 
> ftp://ftp.freeradius.org/pub/radius/. The issue on SSL linking (described 
> in DWN [1]) doesn't look as it is has been fixed and the debian/ directory 
> in the CVS has not seen any change for quite some time (+5 months)

> Anyone?

The SSL linkage was solved (simply for the moment) by leaving out
postgresql, SNMP agent support, EAP/TLS and x.99 token support, and
build-conflicting against libssl-dev.

I plan to go back and try and convert what I can to libgcrypt/libgnutls,
and upgrade to libsnmp5 support. (This last one is what keeps _me_
using a local build. :-(

PostgreSQL requires license changes, and I've not had much luck buiding
impetus for this, nor even identified an exact change that would be
needed.

As for the debian/ directory in CVS, it's not been touched in a while
since it's pretty much built cleanly and happily for that long. Once
Steve Langasek is satisfied with my package, I'll be pulling those
changes back into CVS. (As seen at http://www.tbble.com/freeradius/)

There's no packages on ftp.freeradius.org since (a) I don't have access
to update that site; and (b) it never occurred to me to put them
there or ask for such to be done. I've been gunning for archive
re-entry instead.

> [1] http://www.debian.org/News/weekly/2003/02/

-- 
---
Paul "TBBle" Hampson, MCSE
6th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"

This email is licensed to the recipient for non-commercial
use, duplication and distribution.
---


signature.asc
Description: Digital signature

Re: radiusd-freeradius history and future

[Paul Hampson]

On Tue, Nov 11, 2003 at 02:02:49PM -0500, Matt Zimmerman wrote:
> On Tue, Nov 11, 2003 at 11:52:00AM -0600, Steve Langasek wrote:
> 
> > The packages at  will be sponsored into
> > the archive as soon as I've had a chance to review them (this week).
> 
> This thing is packed full of strcpy() and strcat(), which is the sort of
> sloppiness that I don't like to see in a network server.  It was a great
> blessing to find that we weren't shipping this in woody when the last batch
> of security problems was discovered.

> Have mercy...

Well, then don't use it. :-)

No, seriously, I'll put that on my TODO list. Mind you, we do some
rather heavy input validation and are particularly strict on the RADIUS
protocol, so I'm fairly confident that it's not going to be a problem.

I am however curious about this "last batch of security problems"? Can
you point me at that?

-- 
---
Paul "TBBle" Hampson, MCSE
6th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"

This email is licensed to the recipient for non-commercial
use, duplication and distribution.
---


signature.asc
Description: Digital signature

Re: radiusd-freeradius history and future

[Steve Langasek]

On Wed, Nov 12, 2003 at 08:00:40AM +1100, Paul Hampson wrote:

> PostgreSQL requires license changes, and I've not had much luck buiding
> impetus for this, nor even identified an exact change that would be
> needed.

As an aside, it should be possible to connect freeradius to a postgresql
server using the ODBC module, which is included in the packages (but not
as a separate binary package, the way the mysql and postgresql are --
Paul?)  This will obviously cause at least a slight performance hit, but
it may meet the needs of some users.  (We log to mysql here, so.)

-- 
Steve Langasek
postmodern programmer


pgpNa9cLf46CZ.pgp
Description: PGP signature

Re: radiusd-freeradius history and future

[Matt Zimmerman]

On Wed, Nov 12, 2003 at 08:03:28AM +1100, Paul Hampson wrote:

> On Tue, Nov 11, 2003 at 02:02:49PM -0500, Matt Zimmerman wrote:
> > This thing is packed full of strcpy() and strcat(), which is the sort of
> > sloppiness that I don't like to see in a network server.  It was a great
> > blessing to find that we weren't shipping this in woody when the last batch
> > of security problems was discovered.
> 
> > Have mercy...
> 
> Well, then don't use it. :-)

If it makes it back into Debian, I end up having to support it whether I use
it personally or not.

> No, seriously, I'll put that on my TODO list. Mind you, we do some rather
> heavy input validation and are particularly strict on the RADIUS protocol,
> so I'm fairly confident that it's not going to be a problem.
> 
> I am however curious about this "last batch of security problems"? Can you
> point me at that?

CAN-2001-1376 and CAN-2001-1377 made the rounds last Spring, with advisories
from Red Hat, FreeBSD, SuSE, Conectiva, CERT, etc.  These affected multiple
RADIUS implementations, of which FreeRADIUS was one, and required large
quantities of problematic code to be patched.

-- 
 - mdz

Re: radiusd-freeradius history and future

[Paul Hampson]

On Tue, Nov 11, 2003 at 03:23:24PM -0600, Steve Langasek wrote:
> On Wed, Nov 12, 2003 at 08:00:40AM +1100, Paul Hampson wrote:
> 
> > PostgreSQL requires license changes, and I've not had much luck buiding
> > impetus for this, nor even identified an exact change that would be
> > needed.
> 
> As an aside, it should be possible to connect freeradius to a postgresql
> server using the ODBC module, which is included in the packages (but not
> as a separate binary package, the way the mysql and postgresql are --
> Paul?)  This will obviously cause at least a slight performance hit, but
> it may meet the needs of some users.  (We log to mysql here, so.)

And excellent point, which I'll make sure to add to the Readme.
I'm including the PostgreSQL example DB in the package's docs, so that
should work all OK.

I've been splitting out ODBC support locally since the very beginning,
but everytime I mooted it, Wichert Akkerman (amongst others, but he was
at the time gatekeeper to the debian/ dir in CVS, if you're wondering
why I keep invoking him) disagreed on the grounds of archive bloat,
since rlm_sql_iodbc only pulls in the one package (libiodbc2).

I also promised that I would address _that_ once it was in the archive.
:-)

My personal inclination is to micro-packages, but I _like_ installing
packages. :-)

(I have a strange sense that my TODO list is starting to grow to match
my available time... :-)

-- 
---
Paul "TBBle" Hampson, MCSE
6th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"

This email is licensed to the recipient for non-commercial
use, duplication and distribution.
---


signature.asc
Description: Digital signature

Re: radiusd-freeradius history and future

[Oliver Elphick]

On Tue, 2003-11-11 at 21:00, Paul Hampson wrote:
> PostgreSQL requires license changes, and I've not had much luck buiding
> impetus for this, nor even identified an exact change that would be
> needed.

I'm intrigued as to how the PostgreSQL licence can conflict with
anything, since it's BSD.

-- 
Oliver Elphick[EMAIL PROTECTED]
Isle of Wight, UK http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
 
 "Therefore, my beloved brethren, be ye stedfast, 
  unmoveable, always abounding in the work of the Lord, 
  forasmuch as ye know that your labour is not in vain 
  in the Lord."1 Corinthians 15:58 

Re: radiusd-freeradius history and future

[Steve Langasek]

On Tue, Nov 11, 2003 at 09:39:52PM +, Oliver Elphick wrote:
> On Tue, 2003-11-11 at 21:00, Paul Hampson wrote:
> > PostgreSQL requires license changes, and I've not had much luck buiding
> > impetus for this, nor even identified an exact change that would be
> > needed.

> I'm intrigued as to how the PostgreSQL licence can conflict with
> anything, since it's BSD.

The libpq3 package in unstable links against OpenSSL, so this falls
under the umbrella of the happifun GPL/OpenSSL license conflict.

-- 
Steve Langasek
postmodern programmer


pgplZHcgjgIPv.pgp
Description: PGP signature

Re: radiusd-freeradius history and future

[Paul Hampson]

On Tue, Nov 11, 2003 at 04:30:50PM -0500, Matt Zimmerman wrote:
> On Wed, Nov 12, 2003 at 08:03:28AM +1100, Paul Hampson wrote:
> 
> > On Tue, Nov 11, 2003 at 02:02:49PM -0500, Matt Zimmerman wrote:
> > > This thing is packed full of strcpy() and strcat(), which is the sort of
> > > sloppiness that I don't like to see in a network server.  It was a great
> > > blessing to find that we weren't shipping this in woody when the last 
> > > batch
> > > of security problems was discovered.
> > 
> > > Have mercy...
> > 
> > Well, then don't use it. :-)
> 
> If it makes it back into Debian, I end up having to support it whether I use
> it personally or not.

*blink* Oh, Security Team. :-)

Well, I'll do what I can to make sure it never worries you.

> > I am however curious about this "last batch of security problems"? Can you
> > point me at that?

> CAN-2001-1376 and CAN-2001-1377 made the rounds last Spring, with advisories
> from Red Hat, FreeBSD, SuSE, Conectiva, CERT, etc.  These affected multiple
> RADIUS implementations, of which FreeRADIUS was one, and required large
> quantities of problematic code to be patched.

Last Spring? December 2001/March 2002? And I thought my sense of
time/space was poor. :-) [1]

The fixed FreeRADIUS was out December 2001[2], 6 days before the vendor
notifications came out.

These both came from an audit of FreeRADIUS. To be frank, the general
advice you'd get from the FreeRADIUS mailing list is "keep untrusted
IP addresses" away from your RADIUS server. Both by FreeRADIUS
configuration and firewall/TLS/VPN/RFC1918/whatever.

Hmm, we have cistron as well, don't we? _And_ xtradius. I can see how
you'd be glad we didn't have _three_ cistron-derived RADIUS servers to
do security updates for...

[1] http://marc.theaimsgroup.com/?l=bugtraq&m=101537153021792&w=2
[2] http://www.freeradius.org/getting.html

-- 
---
Paul "TBBle" Hampson, MCSE
6th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"

This email is licensed to the recipient for non-commercial
use, duplication and distribution.
---


signature.asc
Description: Digital signature

Re: radiusd-freeradius history and future

[Paul Hampson]

On Tue, Nov 11, 2003 at 09:39:52PM +, Oliver Elphick wrote:
> On Tue, 2003-11-11 at 21:00, Paul Hampson wrote:
> > PostgreSQL requires license changes, and I've not had much luck buiding
> > impetus for this, nor even identified an exact change that would be
> > needed.
> 
> I'm intrigued as to how the PostgreSQL licence can conflict with
> anything, since it's BSD.

The problem is that I'm an idiot...

PostgreSQL support in a Debian freeradius package requires a license
change in FreeRADIUS...

Because the FreeRADIUS PostgreSQL module is GPL, and I'm reliably
informed by all comers that means it can't link to libpgsql.

-- 
---
Paul "TBBle" Hampson, MCSE
6th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"

This email is licensed to the recipient for non-commercial
use, duplication and distribution.
---


signature.asc
Description: Digital signature

Re: radiusd-freeradius history and future

[Oliver Elphick]

On Tue, 2003-11-11 at 21:53, Steve Langasek wrote:
> On Tue, Nov 11, 2003 at 09:39:52PM +, Oliver Elphick wrote:
> > On Tue, 2003-11-11 at 21:00, Paul Hampson wrote:
> > > PostgreSQL requires license changes, and I've not had much luck buiding
> > > impetus for this, nor even identified an exact change that would be
> > > needed.
> 
> > I'm intrigued as to how the PostgreSQL licence can conflict with
> > anything, since it's BSD.
> 
> The libpq3 package in unstable links against OpenSSL, so this falls
> under the umbrella of the happifun GPL/OpenSSL license conflict.

One solution then would be a libpq3-nossl package (and -dev).  Is there
sufficient demand for that?

-- 
Oliver Elphick[EMAIL PROTECTED]
Isle of Wight, UK http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
 
 "Therefore, my beloved brethren, be ye stedfast, 
  unmoveable, always abounding in the work of the Lord, 
  forasmuch as ye know that your labour is not in vain 
  in the Lord."1 Corinthians 15:58 

Re: radiusd-freeradius history and future

[Javier Fernández-Sanguino Peña]

On Tue, Nov 11, 2003 at 02:02:49PM -0500, Matt Zimmerman wrote:
> On Tue, Nov 11, 2003 at 11:52:00AM -0600, Steve Langasek wrote:
> 
> > The packages at  will be sponsored into
> > the archive as soon as I've had a chance to review them (this week).
> 
> This thing is packed full of strcpy() and strcat(), which is the sort of
> sloppiness that I don't like to see in a network server.  It was a great

Which flawfinder flawlessly points out, but this also appears in the
current radiusd servers we are shipping. In any case, I'm also worried
about these:

./src/main/mainconfig.c:267  [5] (race) chown:
[shouldn't fchown() be used instead?]

and

./src/modules/rlm_krb5/rlm_krb5.c:201  [3] (tmpfile) tmpnam:
  Temporary file race condition.
[tmpnam should be avoided and tempfile() used instead]


> blessing to find that we weren't shipping this in woody when the last batch
> of security problems was discovered.
> 

Also, just another question. Is there any reason why it needs to run as
root? (as I believe it does in the current Debian package) Would it be
unreasonable to ask it to run as a 'radiusd' user? 

Maybe I'm mistaken, but the rpm spec file seems to use a 'radiusd' user
whileas the Debian rules package does not. I would be more confident with
the package if it was built this way. At least a security problem in
its code (if found) would lead to a remote 'radiusd' compromise (but not
'root') an important difference.

However, this is the way that currently the radiusd packages we provide 
(radiusd-cistron and radiusd-livingston) seem to operate. Is this at all 
necessary? (after all they use their separate users database)

Regards

Javi

PS: I'm not particularly worried about freeradius, I'm just raising some
questions.  It seems that our radiusd packages suffer from similar (if not
worst) security issues and, furthermore, are not (I believe) that actively
maintained upstream.

Re: radiusd-freeradius history and future

[Matt Zimmerman]

On Wed, Nov 12, 2003 at 02:07:27AM +0100, Javier Fernández-Sanguino Peña wrote:

> Also, just another question. Is there any reason why it needs to run as
> root? (as I believe it does in the current Debian package) Would it be
> unreasonable to ask it to run as a 'radiusd' user? 

I can almost guarantee that it shouldn't be running as root.  I hope that
the new maintainer plans to change this.

> However, this is the way that currently the radiusd packages we provide 
> (radiusd-cistron and radiusd-livingston) seem to operate. Is this at all 
> necessary? (after all they use their separate users database)

The only reason I can think of for running a RADIUS server as root would be
to authenticate against UNIX passwords or such, which is a pretty bad idea
anyway.  They should all run as non-root.

> PS: I'm not particularly worried about freeradius, I'm just raising some
> questions.  It seems that our radiusd packages suffer from similar (if not
> worst) security issues and, furthermore, are not (I believe) that actively
> maintained upstream.

Packages which represent an attack vector and are not actively maintained
are a liability, and I think that they should not be included in Debian
releases.  There are several packages in woody that we might have been
better off without, and I hope that we can do better with sarge.

-- 
 - mdz

Re: radiusd-freeradius history and future

[Russell Coker]

On Wed, 12 Nov 2003 12:40, Matt Zimmerman wrote:
> The only reason I can think of for running a RADIUS server as root would be
> to authenticate against UNIX passwords or such, which is a pretty bad idea
> anyway.  They should all run as non-root.

Allowing a RADIUS server to authenticate local users against /etc/shadow is 
standard and expected functionality IMHO.  I consider any RADIUS server which 
can't authenticate against the local accounts database to be severely broken.

This does not necessarily have to require root access.  The unix_chkpwd helper 
program for the pam_unix.so module allows checking a password for an account 
with the current UID.  Giving all local accounts for the RADIUS server the 
same UID as the RADIUS server won't work for several reasons (including the 
fact that the unix_chkpwd helper has broken checks which fail when two 
accounts have the same UID).

One possible solution to this is to have a special GID for non-root programs 
which are allowed to check passwords.  I would be happy to code this if 
someone else wants to do the testing...

Another issue that has to be addressed is the unix_acct code (checking for 
accounts with expired passwords).  I've already written a helper for that.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: radiusd-freeradius history and future

[Matt Zimmerman]

On Wed, Nov 12, 2003 at 01:23:02PM +1100, Russell Coker wrote:

> Allowing a RADIUS server to authenticate local users against /etc/shadow
> is standard and expected functionality IMHO.  I consider any RADIUS server
> which can't authenticate against the local accounts database to be
> severely broken.

I disagree; I wouldn't let any of these RADIUS implementations near my
shadow file.

> One possible solution to this is to have a special GID for non-root
> programs which are allowed to check passwords.  I would be happy to code
> this if someone else wants to do the testing...

We already have such a group, named "shadow".  In fact, I don't know why
unix_chkpwd is setuid root rather than setgid shadow.

-- 
 - mdz

Re: radiusd-freeradius history and future

[Javier Fernández-Sanguino Peña]

On Wed, Nov 12, 2003 at 01:23:02PM +1100, Russell Coker wrote:
> On Wed, 12 Nov 2003 12:40, Matt Zimmerman wrote:
> > The only reason I can think of for running a RADIUS server as root would be
> > to authenticate against UNIX passwords or such, which is a pretty bad idea
> > anyway.  They should all run as non-root.
> 
> Allowing a RADIUS server to authenticate local users against /etc/shadow is 
> standard and expected functionality IMHO.  I consider any RADIUS server which 
> can't authenticate against the local accounts database to be severely broken.

Well. IMHO that used to be a standard way of doing this when directories 
where not available. Now it is quite common to validate against an LDAP, 
MySQL or whatever server. YMMV. But you are right in that all these 
implementations assume that checking against the local user database is the 
default action.

> This does not necessarily have to require root access.  The unix_chkpwd 
> helper 
> program for the pam_unix.so module allows checking a password for an account 
> with the current UID.  Giving all local accounts for the RADIUS server the 
(...)

That would need a reimplementation of some (all?) of the servers. Wouldn't
it? Old ones (cistron, livingston) call getpwnam()|getspnam() to retrieve
the user's encrypted passwords. New ones (freeradius) can alternatively
talk with a myriad of authentication services...

Regards

Javi

Re: radiusd-freeradius history and future

[Matt Zimmerman]

On Wed, Nov 12, 2003 at 04:11:38AM +0100, Javier Fernández-Sanguino Peña wrote:

> On Wed, Nov 12, 2003 at 01:23:02PM +1100, Russell Coker wrote:
> > Allowing a RADIUS server to authenticate local users against /etc/shadow
> > is standard and expected functionality IMHO.  I consider any RADIUS
> > server which can't authenticate against the local accounts database to
> > be severely broken.
> 
> Well. IMHO that used to be a standard way of doing this when directories 
> where not available. Now it is quite common to validate against an LDAP, 
> MySQL or whatever server. YMMV. But you are right in that all these 
> implementations assume that checking against the local user database is the 
> default action.

Even before these directories were common, it was usually preferred to have
a separate database for RADIUS authentication (at least, I preferred it).

-- 
 - mdz

Re: radiusd-freeradius history and future

[Russell Coker]

On Wed, 12 Nov 2003 13:47, Matt Zimmerman wrote:
> On Wed, Nov 12, 2003 at 01:23:02PM +1100, Russell Coker wrote:
> > Allowing a RADIUS server to authenticate local users against /etc/shadow
> > is standard and expected functionality IMHO.  I consider any RADIUS
> > server which can't authenticate against the local accounts database to be
> > severely broken.
>
> I disagree; I wouldn't let any of these RADIUS implementations near my
> shadow file.

unix_chkpwd is a reasonable solution to this.

> > One possible solution to this is to have a special GID for non-root
> > programs which are allowed to check passwords.  I would be happy to code
> > this if someone else wants to do the testing...
>
> We already have such a group, named "shadow".  In fact, I don't know why
> unix_chkpwd is setuid root rather than setgid shadow.

Bug report #155583 has been open for over a year.  I have repeated the tests 
of Lee and Robert and verified that it works fine as SETGID rather than 
SETUID.

Also I believe that Lee's statement regarding NIS is incorrect, unix_chkpwd 
only does /etc/shadow.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: radiusd-freeradius history and future

[Russell Coker]

On Wed, 12 Nov 2003 14:11, Javier Fernández-Sanguino Peña wrote:
> That would need a reimplementation of some (all?) of the servers. Wouldn't
> it? Old ones (cistron, livingston) call getpwnam()|getspnam() to retrieve
> the user's encrypted passwords. New ones (freeradius) can alternatively
> talk with a myriad of authentication services...

Cistron in woody uses PAM so does not appear to have any problems in this 
regard.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: radiusd-freeradius history and future

[Matt Zimmerman]

On Wed, Nov 12, 2003 at 03:36:40PM +1100, Russell Coker wrote:

> On Wed, 12 Nov 2003 13:47, Matt Zimmerman wrote:
> > We already have such a group, named "shadow".  In fact, I don't know why
> > unix_chkpwd is setuid root rather than setgid shadow.
> 
> Bug report #155583 has been open for over a year.  I have repeated the tests 
> of Lee and Robert and verified that it works fine as SETGID rather than 
> SETUID.
> 
> Also I believe that Lee's statement regarding NIS is incorrect, unix_chkpwd 
> only does /etc/shadow.

I agree completely; this seems long overdue.  Sam, do you have any
reservations about this?

-- 
 - mdz

Re: radiusd-freeradius history and future

[Francesco P. Lovergine]

On Wed, Nov 12, 2003 at 03:37:29PM +1100, Russell Coker wrote:
> On Wed, 12 Nov 2003 14:11, Javier Fernández-Sanguino Peña wrote:
> > That would need a reimplementation of some (all?) of the servers. Wouldn't
> > it? Old ones (cistron, livingston) call getpwnam()|getspnam() to retrieve
> > the user's encrypted passwords. New ones (freeradius) can alternatively
> > talk with a myriad of authentication services...
> 
> Cistron in woody uses PAM so does not appear to have any problems in this 
> regard.
> 

The same for my yardradius and probably xtradius.

System  password  checking is  present  for  portability with  non-linux
platform essentially,  and for historical  reasons, too. A lots  of those
servers are derived from the original livingston's implementation, but all
add alternatives forms of authentication and accounting. It's an admin's
choice.

-- 
Francesco P. Lovergine

Re: radiusd-freeradius history and future

[Paul Hampson]

On Wed, Nov 12, 2003 at 02:07:27AM +0100, Javier Fernández-Sanguino Peña wrote:
> On Tue, Nov 11, 2003 at 02:02:49PM -0500, Matt Zimmerman wrote:
> > On Tue, Nov 11, 2003 at 11:52:00AM -0600, Steve Langasek wrote:

> > > The packages at  will be sponsored into
> > > the archive as soon as I've had a chance to review them (this week).

> > This thing is packed full of strcpy() and strcat(), which is the sort of
> > sloppiness that I don't like to see in a network server.  It was a great

> Which flawfinder flawlessly points out, but this also appears in the
> current radiusd servers we are shipping. In any case, I'm also worried
> about these:

> ./src/main/mainconfig.c:267  [5] (race) chown:
> [shouldn't fchown() be used instead?]
> 
> and
> 
> ./src/modules/rlm_krb5/rlm_krb5.c:201  [3] (tmpfile) tmpnam:
>   Temporary file race condition.
> [tmpnam should be avoided and tempfile() used instead]

Also on my TODO list now. Thankyou.

I'll have to go look into flawfinder as well. That looks interesting.

> > blessing to find that we weren't shipping this in woody when the last batch
> > of security problems was discovered.

> Also, just another question. Is there any reason why it needs to run as
> root? (as I believe it does in the current Debian package) Would it be
> unreasonable to ask it to run as a 'radiusd' user? 

FreeRADIUS hasn't run as root since I got my hands on it in the upstream
CVS. It wasn't supposed to run as root in the 0.71 packages that were
NMU'd, nor did it intend run as root in the 0.5 packages... It did run
as root in the latter one, due to a change in the upstream config (The
default upstream config now runs as root, but the debian/rules script
un-comments the lines in the config during build.)

> Maybe I'm mistaken, but the rpm spec file seems to use a 'radiusd' user
> whileas the Debian rules package does not. I would be more confident with
> the package if it was built this way. At least a security problem in
> its code (if found) would lead to a remote 'radiusd' compromise (but not
> 'root') an important difference.

I don't know what debian/rules file you're looking at, since the bug
report in the DBS relating to this has my patch to fix it, and both the
current stable and unstable debian/ filesets do not run as root.

It does adduser freerad shadow on first installation, but not after that
(on the advice of Steve Langasek) to allow the local authentication code
to work, and to give the admin the freedom to disable this for added
security if they're not using the local authentication code.

> However, this is the way that currently the radiusd packages we provide 
> (radiusd-cistron and radiusd-livingston) seem to operate. Is this at all 
> necessary? (after all they use their separate users database)

> PS: I'm not particularly worried about freeradius, I'm just raising some
> questions.  It seems that our radiusd packages suffer from similar (if not
> worst) security issues and, furthermore, are not (I believe) that actively
> maintained upstream.

Livingston begat YardRADIUS. I'd assumed Livingston was dead upstream,
although I did see one of the Bugtraq postings mention RADIUS (Formerly
livingston) although the version number was the same as the Livingston
RADIUS server listed...

Cistron begat FreeRADIUS. FreeRADIUS is certainly actively maintained
upstream.  xtRADIUS is also begat of Cistron. I'd assumed that Cistron
is dead upstream too, and xtRADIUS active.

There's also gnuradius, which doesn't appear in Debian.

This is why so many of them suffer similar security bugs, as soon as one
finds one, the others go look in the same place.

-- 
---
Paul "TBBle" Hampson, MCSE
6th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"

This email is licensed to the recipient for non-commercial
use, duplication and distribution.
---


signature.asc
Description: Digital signature

Re: radiusd-freeradius history and future

[Miquel van Smoorenburg]

In article <[EMAIL PROTECTED]>,
Paul Hampson <[EMAIL PROTECTED]> wrote:
>Cistron begat FreeRADIUS. FreeRADIUS is certainly actively maintained
>upstream.  xtRADIUS is also begat of Cistron. I'd assumed that Cistron
>is dead upstream too, and xtRADIUS active.

Cistron radius is not dead. It's just in maintenance mode - only
bugfixes will be made, no major new functionality. That's what
freeradius is for.

Mike.

Re: radiusd-freeradius history and future

[Javier Fernández-Sanguino Peña]

On Thu, Nov 13, 2003 at 12:19:02AM +1100, Paul Hampson wrote:
> On Wed, Nov 12, 2003 at 02:07:27AM +0100, Javier Fernández-Sanguino Peña 
> wrote:
> 
> > Maybe I'm mistaken, but the rpm spec file seems to use a 'radiusd' user
> > whileas the Debian rules package does not. I would be more confident with
> > the package if it was built this way. At least a security problem in
> > its code (if found) would lead to a remote 'radiusd' compromise (but not
> > 'root') an important difference.
> 
> I don't know what debian/rules file you're looking at, since the bug
> report in the DBS relating to this has my patch to fix it, and both the
> current stable and unstable debian/ filesets do not run as root.

You are right.

> 
> It does adduser freerad shadow on first installation, but not after that
> (on the advice of Steve Langasek) to allow the local authentication code
> to work, and to give the admin the freedom to disable this for added
> security if they're not using the local authentication code.

Yes, I missed the 'adduser' calls in postinst. In any case, it would be 
nice if, instead of 'freerad' a generic 'radiusd' user was used so that it 
could be "shared" by different radius packages. Not that one would want to 
install different Radius servers and share the users file, but just for 
consistency and to avoid having multiple 'freerad', 'cistronrad', 
'livingston' users. It might help if you have a cluster of servers and want 
ot have uniform usernames between them (even if running different 
implementations). Just a thought (maybe worthless)

Regards

Javi

Re: radiusd-freeradius history and future

[Andreas Metzler]

On Wed, Nov 12, 2003 at 03:36:40PM +1100, Russell Coker wrote:
> On Wed, 12 Nov 2003 13:47, Matt Zimmerman wrote:
[...] 
> unix_chkpwd is a reasonable solution to this.
>>> One possible solution to this is to have a special GID for
>>> non-root programs which are allowed to check passwords.  I would
>>> be happy to code this if someone else wants to do the testing...

>> We already have such a group, named "shadow".  In fact, I don't
>> know why unix_chkpwd is setuid root rather than setgid shadow.
 
> Bug report #155583 has been open for over a year.  I have repeated
> the tests of Lee and Robert and verified that it works fine as
> SETGID rather than SETUID.
 
> Also I believe that Lee's statement regarding NIS is incorrect, unix_chkpwd 
> only does /etc/shadow.

testing.

You are wrong, unix_chkpwd does NIS (at least in the szenario I just
tested). After changing unix_chkpwd from 4755 root:root to 2755
root:shadow a NIS user can not unlock the terminal he has just locked
himself with vlock anymore.

The NIS-server is configured with
*  : *   : shadow.byname: port
*  : *   : passwd.adjunct.byname : port

and

MERGE_PASSWD=false
cu andreas

Re: radiusd-freeradius history and future

[Steve Langasek]

On Wed, Nov 12, 2003 at 05:23:09PM +0100, Javier Fernández-Sanguino Peña wrote:
> > It does adduser freerad shadow on first installation, but not after that
> > (on the advice of Steve Langasek) to allow the local authentication code
> > to work, and to give the admin the freedom to disable this for added
> > security if they're not using the local authentication code.

> Yes, I missed the 'adduser' calls in postinst. In any case, it would be 
> nice if, instead of 'freerad' a generic 'radiusd' user was used so that it 
> could be "shared" by different radius packages. Not that one would want to 
> install different Radius servers and share the users file, but just for 
> consistency and to avoid having multiple 'freerad', 'cistronrad', 
> 'livingston' users.

Are you kidding?  And link the security of freeradius processes to that
of those old, crufty, scary packages? ;)

[Over the years, I've had occasion to use each of these RADIUS
implementations.  While Livingston RADIUS is the granddaddy of them all,
I don't think it ever got much peer review except in the form of forks
-- like Cistron.  And while Cistron was good at the time, and I trust
Miquel's abilities, the security bar has been moved significantly from
where it was when the freeradius reimplementation began.]

-- 
Steve Langasek
postmodern programmer


pgpG6eB480LDx.pgp
Description: PGP signature

Re: radiusd-freeradius history and future

[Steve Langasek]

On Wed, Nov 12, 2003 at 08:35:53AM +1100, Paul Hampson wrote:
> On Tue, Nov 11, 2003 at 03:23:24PM -0600, Steve Langasek wrote:
> > On Wed, Nov 12, 2003 at 08:00:40AM +1100, Paul Hampson wrote:

> > > PostgreSQL requires license changes, and I've not had much luck buiding
> > > impetus for this, nor even identified an exact change that would be
> > > needed.

> > As an aside, it should be possible to connect freeradius to a postgresql
> > server using the ODBC module, which is included in the packages (but not
> > as a separate binary package, the way the mysql and postgresql are --
> > Paul?)  This will obviously cause at least a slight performance hit, but
> > it may meet the needs of some users.  (We log to mysql here, so.)

> And excellent point, which I'll make sure to add to the Readme.
> I'm including the PostgreSQL example DB in the package's docs, so that
> should work all OK.

> I've been splitting out ODBC support locally since the very beginning,
> but everytime I mooted it, Wichert Akkerman (amongst others, but he was
> at the time gatekeeper to the debian/ dir in CVS, if you're wondering
> why I keep invoking him) disagreed on the grounds of archive bloat,
> since rlm_sql_iodbc only pulls in the one package (libiodbc2).

And rlm_sql_mysql only pulls in libmysqlclient10, and rlm_krb5 only
pulls in libkrb53. :)  These dependencies should be regarded with
parity.

> I also promised that I would address _that_ once it was in the archive.
> :-)

> My personal inclination is to micro-packages, but I _like_ installing
> packages. :-)

I'm personally rather indifferent on the question.  Embedded systems
developers and ftp masters are known to have stronger opinions.

> (I have a strange sense that my TODO list is starting to grow to match
> my available time... :-)

You'll have that...

-- 
Steve Langasek
postmodern programmer


pgpoM0JMHKExl.pgp
Description: PGP signature

Re: radiusd-freeradius history and future

[Russell Coker]

On Thu, 13 Nov 2003 03:59, Andreas Metzler wrote:
> > Also I believe that Lee's statement regarding NIS is incorrect,
> > unix_chkpwd only does /etc/shadow.
>
> testing.
>
> You are wrong, unix_chkpwd does NIS (at least in the szenario I just
> tested). After changing unix_chkpwd from 4755 root:root to 2755
> root:shadow a NIS user can not unlock the terminal he has just locked
> himself with vlock anymore.

I've just read the code more carefully.  It seems that the only NIS specific 
code is the following:
if (strcmp(pwd->pw_passwd, "*NP*") == 0) {  /* NIS+ */
  uid_t save_uid;
  save_uid = geteuid();
  seteuid(pwd->pw_uid);
  spwdent = getspnam(name);
  seteuid(save_uid);
  salt = x_strdup(spwdent->sp_pwdp);
} else {
  salt = x_strdup(pwd->pw_passwd);
}

Now if the program is SGID shadow (same as vlock incidentally) then the UID of 
the process should already be the same as pwd->pw_uid and therefore it should 
all work.

Or do you have to be root for getpwnam() to work on NIS accounts?

Could you please do some more tests on this?

Re: radiusd-freeradius history and future

[Paul Hampson]

On Wed, Nov 12, 2003 at 01:24:32PM +, Miquel van Smoorenburg wrote:
> In article <[EMAIL PROTECTED]>,
> Paul Hampson <[EMAIL PROTECTED]> wrote:
> >Cistron begat FreeRADIUS. FreeRADIUS is certainly actively maintained
> >upstream.  xtRADIUS is also begat of Cistron. I'd assumed that Cistron
> >is dead upstream too, and xtRADIUS active.
> 
> Cistron radius is not dead. It's just in maintenance mode - only
> bugfixes will be made, no major new functionality. That's what
> freeradius is for.

I apologise, and now feel fully justified in using the past tense of
'assume'. :-)

-- 
---
Paul "TBBle" Hampson, MCSE
6th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"

This email is licensed to the recipient for non-commercial
use, duplication and distribution.
---


signature.asc
Description: Digital signature

Re: radiusd-freeradius history and future

[Paul Hampson]

On Wed, Nov 12, 2003 at 12:53:39PM -0600, Steve Langasek wrote:
> On Wed, Nov 12, 2003 at 08:35:53AM +1100, Paul Hampson wrote:

> > I've been splitting out ODBC support locally since the very beginning,
> > but everytime I mooted it, Wichert Akkerman (amongst others, but he was
> > at the time gatekeeper to the debian/ dir in CVS, if you're wondering
> > why I keep invoking him) disagreed on the grounds of archive bloat,
> > since rlm_sql_iodbc only pulls in the one package (libiodbc2).

> And rlm_sql_mysql only pulls in libmysqlclient10, and rlm_krb5 only
> pulls in libkrb53. :)  These dependencies should be regarded with
> parity.

True. And I was too afraid of turning that discussion into "Why don't
we unsplit mysql" to persue that path. Besides, just because the
previous maintainer thought a certain package split was correct, doesn't
absolve me of having to argue it through convincingly myself.

> > I also promised that I would address _that_ once it was in the archive.
> > :-)

> > My personal inclination is to micro-packages, but I _like_ installing
> > packages. :-)

> I'm personally rather indifferent on the question.  Embedded systems
> developers and ftp masters are known to have stronger opinions.

Which, if I have been following correctly, come into direct conflict...

Or can do, depending on which FTP master you get.
-- 
---
Paul "TBBle" Hampson, MCSE
6th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"

This email is licensed to the recipient for non-commercial
use, duplication and distribution.
---


signature.asc
Description: Digital signature

Re: radiusd-freeradius history and future

[Andreas Metzler]

On Thu, Nov 13, 2003 at 10:43:58AM +1100, Russell Coker wrote:
> On Thu, 13 Nov 2003 03:59, Andreas Metzler wrote:
>>> Also I believe that Lee's statement regarding NIS is incorrect,
>>> unix_chkpwd only does /etc/shadow.

>> testing.

>> You are wrong, unix_chkpwd does NIS (at least in the szenario I just
>> tested). After changing unix_chkpwd from 4755 root:root to 2755
>> root:shadow a NIS user can not unlock the terminal he has just locked
>> himself with vlock anymore.

> I've just read the code more carefully.  It seems that the only NIS specific 
> code is the following:
> if (strcmp(pwd->pw_passwd, "*NP*") == 0) {  /* NIS+ */
[...]
> } else {
>   salt = x_strdup(pwd->pw_passwd);
> }

This seems to be code for NIS+, not NIS.

> Now if the program is SGID shadow (same as vlock incidentally) then the UID 
> of 
> the process should already be the same as pwd->pw_uid and therefore it should 
> all work.

> Or do you have to be root for getpwnam() to work on NIS accounts?

In certain NIS configurations you can only access the hashed password
if your query to the NIS server comes from a privileged port <=1024,
i.e. afaict yes.

I should have stated this more clearly in my initial mail. I was in a
hurry, sorry.

> Could you please do some more tests on this?

If you tell me what exactly you want me to test I can run the test
(not tomorrow, but soon enough)
   cu andreas
PS: I am subscribed to -devel, please don't cc me, thanks.
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"

Re: radiusd-freeradius history and future

[Russell Coker]

On Thu, 13 Nov 2003 11:15, Andreas Metzler <[EMAIL PROTECTED]> 
wrote:
> > Or do you have to be root for getpwnam() to work on NIS accounts?
>
> In certain NIS configurations you can only access the hashed password
> if your query to the NIS server comes from a privileged port <=1024,
> i.e. afaict yes.

This is so ugly.

Maybe we should have a debconf option for whether the program in question is 
to be SETUID root or SETGID shadow?  Then the minority of people who use NIS 
can have full functionality, while the majority of people who don't use NIS 
can have better security.

Re: radiusd-freeradius history and future

[Henning Makholm]

Scripsit Russell Coker <[EMAIL PROTECTED]>

> Maybe we should have a debconf option for whether the program in question is 
> to be SETUID root or SETGID shadow?  Then the minority of people who use NIS 
> can have full functionality, while the majority of people who don't use NIS 
> can have better security.

Would it be feasible to have the program be suid root, but start by
trying to parse /etc/nsswitch.conf and drop root privileges
immediately unless it finds NIS for passwd/shadow?

-- 
Henning Makholm "Vend dig ikke om! Det er et meget ubehageligt syn!"

Re: radiusd-freeradius history and future

[Steve Langasek]

On Thu, Nov 13, 2003 at 11:50:05AM +1100, Russell Coker wrote:
> On Thu, 13 Nov 2003 11:15, Andreas Metzler <[EMAIL PROTECTED]> 
> wrote:
> > > Or do you have to be root for getpwnam() to work on NIS accounts?

> > In certain NIS configurations you can only access the hashed password
> > if your query to the NIS server comes from a privileged port <=1024,
> > i.e. afaict yes.

> This is so ugly.

Last I looked, there wasn't much in NIS that wasn't.  I think the amount
of pain we should put other users through on account of NIS is very
small (e.g., no longer asking about non-md5 passwords on install).

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: radiusd-freeradius history and future

[Russell Coker]

On Thu, 13 Nov 2003 12:54, Steve Langasek <[EMAIL PROTECTED]> wrote:
> > This is so ugly.
>
> Last I looked, there wasn't much in NIS that wasn't.  I think the amount
> of pain we should put other users through on account of NIS is very
> small (e.g., no longer asking about non-md5 passwords on install).

Sounds reasonable.

I guess we could make it all install for non-NIS systems by default and assume 
that anyone who knows how to get NIS properly installed can sort out the 
necessary changes.

When comparing distributions they sometimes count the number of questions 
asked at installation, by such a comparison Debian does very badly.  While I 
don't think that we should be aiming for a dozen questions on an install, I 
think that we can productively remove some of the less common options.

Re: radiusd-freeradius history and future

[Miquel van Smoorenburg]

In article <[EMAIL PROTECTED]>,
Steve Langasek  <[EMAIL PROTECTED]> wrote:
>-=-=-=-=-=-
>
>On Thu, Nov 13, 2003 at 11:50:05AM +1100, Russell Coker wrote:
>> On Thu, 13 Nov 2003 11:15, Andreas Metzler <[EMAIL PROTECTED]> 
>> wrote:
>> > > Or do you have to be root for getpwnam() to work on NIS accounts?
>
>> > In certain NIS configurations you can only access the hashed password
>> > if your query to the NIS server comes from a privileged port <=1024,
>> > i.e. afaict yes.
>
>> This is so ugly.
>
>Last I looked, there wasn't much in NIS that wasn't.  I think the amount
>of pain we should put other users through on account of NIS is very
>small (e.g., no longer asking about non-md5 passwords on install).

Sure. NIS works fine with md5 passwords. It's just that NIS is
ofcourse a network protocol, and on the network there might be
non-linux systems that do not support md5 passwords.

However in that case, usually the Linux box isn't the NIS
server but the Solaris box is. So it doesn't matter.

So go ahead, let Debian use md5 by default.

Mike.

Re: radiusd-freeradius history and future

[Andreas Metzler]

Russell Coker <[EMAIL PROTECTED]> wrote:
> On Thu, 13 Nov 2003 11:15, Andreas Metzler <[EMAIL PROTECTED]> 
> wrote:
>> > Or do you have to be root for getpwnam() to work on NIS accounts?

>> In certain NIS configurations you can only access the hashed password
>> if your query to the NIS server comes from a privileged port <=1024,
>> i.e. afaict yes.

> This is so ugly.

> Maybe we should have a debconf option for whether the program in
> question is to be SETUID root or SETGID shadow?  Then the minority
> of people who use NIS can have full functionality, while the
> majority of people who don't use NIS can have better security.

Sounds feasible. (Of course if you insist you can already use
dpkg-statoverride today), a patch would look like this:

config
if ! dpkg-statoverride --list /sbin/unix_chkpwd 1>/dev/null 2>&1 ; then
# check if we are installing suid or not
RET=false
db_input medium libpam-modules/unix_chkpwd_SUID_bit || true
db_go
fi

postinst:
if [ "$1" = "configure" ] ; then
  # do nothing if local admin has overriden the permissions
  if ! dpkg-statoverride --list /sbin/unix_chkpwd 1>/dev/null 2>&1 ; then
RET=false
db_get libpam-modules/unix_chkpwd_SUID_bit
if [ "$RET" = "true" ]; then
  chown root:root /sbin/unix_chkpwd
  chmod 4755 /sbin/unix_chkpwd
else
  chown root:shadow /sbin/unix_chkpwd
  chmod 2755 /sbin/unix_chkpwd
fi
  fi
fi

 cu andreas

Re: radiusd-freeradius history and future

[Andreas Metzler]

Steve Langasek <[EMAIL PROTECTED]> wrote:
> On Thu, Nov 13, 2003 at 11:50:05AM +1100, Russell Coker wrote:
>> On Thu, 13 Nov 2003 11:15, Andreas Metzler <[EMAIL PROTECTED]> 
>> wrote:
 Or do you have to be root for getpwnam() to work on NIS accounts?

>>> In certain NIS configurations you can only access the hashed password
>>> if your query to the NIS server comes from a privileged port <=1024,
>>> i.e. afaict yes.

>> This is so ugly.

> Last I looked, there wasn't much in NIS that wasn't.  I think the amount
> of pain we should put other users through on account of NIS is very
> small (e.g., no longer asking about non-md5 passwords on install).

Just for reference: NIS basically works fine with MD5-passwords as
long as all involved parties (server/clients) could handle them in
their local /etc/shadow or /etc/passwd.
   cu andreas

Re: radiusd-freeradius history and future

[Matt Zimmerman]

On Thu, Nov 13, 2003 at 05:52:13PM +1100, Russell Coker wrote:

> On Thu, 13 Nov 2003 12:54, Steve Langasek <[EMAIL PROTECTED]> wrote:
> > > This is so ugly.
> >
> > Last I looked, there wasn't much in NIS that wasn't.  I think the amount
> > of pain we should put other users through on account of NIS is very
> > small (e.g., no longer asking about non-md5 passwords on install).
> 
> Sounds reasonable.
> 
> I guess we could make it all install for non-NIS systems by default and
> assume that anyone who knows how to get NIS properly installed can sort
> out the necessary changes.
> 
> When comparing distributions they sometimes count the number of questions
> asked at installation, by such a comparison Debian does very badly.  While
> I don't think that we should be aiming for a dozen questions on an
> install, I think that we can productively remove some of the less common
> options.

I think a single "Will you be using NIS?" question would be justified; this
could provide defaults for md5 vs. crypt passwords and setuid-ness of
unix_chkpwd, and so those questions could be suppressed by default.

-- 
 - mdz

Security liabilities (Re: radiusd-freeradius history and future)

[Matt Zimmerman]

On Wed, Nov 12, 2003 at 09:18:38AM +1100, Paul Hampson wrote:

> On Tue, Nov 11, 2003 at 04:30:50PM -0500, Matt Zimmerman wrote:
> > CAN-2001-1376 and CAN-2001-1377 made the rounds last Spring, with advisories
> > from Red Hat, FreeBSD, SuSE, Conectiva, CERT, etc.  These affected multiple
> > RADIUS implementations, of which FreeRADIUS was one, and required large
> > quantities of problematic code to be patched.
> 
> Last Spring? December 2001/March 2002? And I thought my sense of
> time/space was poor. :-) [1]

Spring of last year is when the vendor advisories were coming out to fix
these bugs.  I don't recall which were about freeradius, cistron, etc.  They
were a lot of the same bugs in many implementations, including freeradius.

> The fixed FreeRADIUS was out December 2001[2], 6 days before the vendor
> notifications came out.

A new release is nice enough for those who are installing from source and
want the latest features, but this:

  294 files changed, 13608 insertions(+), 2238 deletions(-)

is not acceptable for a security update.

> These both came from an audit of FreeRADIUS. To be frank, the general
> advice you'd get from the FreeRADIUS mailing list is "keep untrusted IP
> addresses" away from your RADIUS server. Both by FreeRADIUS configuration
> and firewall/TLS/VPN/RFC1918/whatever.

Properly filtering UDP traffic by source requires a level of features that
is generally lacking in low-end edge equipment like NAS boxes.  If I recall
correctly, one of the two vulnerabilities mentioned above did not require
that the attacker know the shared secret, either, so I don't think that
security is something that a RADIUS implementation can punt on.

> Hmm, we have cistron as well, don't we? _And_ xtradius. I can see how
> you'd be glad we didn't have _three_ cistron-derived RADIUS servers to do
> security updates for...

We ship cistron, livingston/lucent, xtradius and yardradius in woody.
freeradius was in unstable until recently.  I'm sure they all share at least
some code.

I can't even remember whether xtradius was properly reviewed or not.  Of
course, we never heard from the maintainer, even in the year following the
disclosure of the bugs.

This is exactly the kind of situation I don't want going forward...there is
so much neglected software in Debian that bugs like these sometimes go
unnoticed, or even if they are noticed, the maintainer doesn't care enough
about stable to let anyone know about it.  Maintainers are our first line of
defense against security problems, and usually the best informed about their
status, and yet maintainers who actively participate in the security update
process represent a minority (a valuable one).

-- 
 - mdz

Re: Security liabilities (Re: radiusd-freeradius history and future)

[Paul Hampson]

On Tue, Nov 11, 2003 at 07:44:01PM -0500, Matt Zimmerman wrote:
> On Wed, Nov 12, 2003 at 09:18:38AM +1100, Paul Hampson wrote:
> > On Tue, Nov 11, 2003 at 04:30:50PM -0500, Matt Zimmerman wrote:
> > > CAN-2001-1376 and CAN-2001-1377 made the rounds last Spring, with 
> > > advisories
> > > from Red Hat, FreeBSD, SuSE, Conectiva, CERT, etc.  These affected 
> > > multiple
> > > RADIUS implementations, of which FreeRADIUS was one, and required large
> > > quantities of problematic code to be patched.

> > The fixed FreeRADIUS was out December 2001[2], 6 days before the vendor
> > notifications came out.

> A new release is nice enough for those who are installing from source and
> want the latest features, but this:
> 
>   294 files changed, 13608 insertions(+), 2238 deletions(-)
> 
> is not acceptable for a security update.

True. Since I'm already being fairly hard-line about what goes into
stable versions of FreeRADIUS, I don't expect to have too much trouble
backporting security fixes if and when this ends up in a stable Debian
release.

I wholehartedly agree that a security update isn't an oportunity to
upgrade stable to the latest version. I love stable because it's stable.

> We ship cistron, livingston/lucent, xtradius and yardradius in woody.
> freeradius was in unstable until recently.  I'm sure they all share at least
> some code.

Well, there's two RADIUS families there... I mentioned this in another
email, and most of that knowledge comes from the descriptions of the
Debian packages involved.

> I can't even remember whether xtradius was properly reviewed or not.  Of
> course, we never heard from the maintainer, even in the year following the
> disclosure of the bugs.

> This is exactly the kind of situation I don't want going forward...there is
> so much neglected software in Debian that bugs like these sometimes go
> unnoticed, or even if they are noticed, the maintainer doesn't care enough
> about stable to let anyone know about it.  Maintainers are our first line of
> defense against security problems, and usually the best informed about their
> status, and yet maintainers who actively participate in the security update
> process represent a minority (a valuable one).

Indeed. Since I'm actively targetting stable with this package, as
that's where my primary production RADIUS server is, I expect to stay
clear of the category "doesn't care enough about stable". I hope the six
months or so I've been hammering away at the upstream debian/ directory
(amongst other things) stands me in good stead for this. :-)

-- 
---
Paul "TBBle" Hampson, MCSE
6th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"

This email is licensed to the recipient for non-commercial
use, duplication and distribution.
---


signature.asc
Description: Digital signature

Re: Security liabilities (Re: radiusd-freeradius history and future)

[Steve Langasek]

On Tue, Nov 11, 2003 at 07:44:01PM -0500, Matt Zimmerman wrote:

> This is exactly the kind of situation I don't want going forward...there is
> so much neglected software in Debian that bugs like these sometimes go
> unnoticed, or even if they are noticed, the maintainer doesn't care enough
> about stable to let anyone know about it.  Maintainers are our first line of
> defense against security problems, and usually the best informed about their
> status, and yet maintainers who actively participate in the security update
> process represent a minority (a valuable one).

While I also deplore the general lack of support package maintainers
provide to the Security Team, given that there are several DDs tracking
freeradius upstream (including, at last glance, at least one member of
the Security Team), I have a hard time believing this particular package
will be a problem.  Given that my own interest in this package comes
from a desire to reduce the number of packages I maintain locally,
ensuring the security of the Debian packages implicitly becomes part of
my day job. ;)

-- 
Steve Langasek
postmodern programmer


pgp1OTQMAvmQs.pgp
Description: PGP signature