Re: radiusd-freeradius history and future
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
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
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 21 ; 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 21 ; 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
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
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
Re: radiusd-freeradius history and future
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
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 http://www.tbble.com/freeradius/ 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: Security liabilities (Re: radiusd-freeradius history and future)
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: radiusd-freeradius history and future
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
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
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
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: Security liabilities (Re: radiusd-freeradius history and future)
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
Re: radiusd-freeradius history and future
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
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
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
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
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
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
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
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
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
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
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 http://www.tbble.com/freeradius/ 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
On Tue, Nov 11, 2003 at 11:52:00AM -0600, Steve Langasek wrote: The packages at http://www.tbble.com/freeradius/ 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
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
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 http://www.tbble.com/freeradius/ 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
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
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
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
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
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
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=bugtraqm=101537153021792w=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
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
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
Security liabilities (Re: radiusd-freeradius history and future)
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: radiusd-freeradius history and future
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 http://www.tbble.com/freeradius/ 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
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
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
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
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
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
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
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
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
