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.
