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.
Reply to: