> Everyone should consider disabling searches if you're running cfingerd.
> Ken, would it be possible to have an additional option (if it's not
> already in a newer version) to disable any wildcard/regexp matches?
Right. The whole idea behind searches was to make it 'compatible' with
GNU Fingerism, but it seemed to have backfired.
> Also, I've heard various reports of cfingerd having security problems in
> the past. Has anyone considered sitting down with it and doing a complete
> security audit? It's a nice tool to have, but if it's insecure, it
> presents a problem. I'm mainly concerned with buffer overruns and other
> similar problems, since it does require that you run it as root.
cfingerd has been shot down many times by previous people, and I have shot
down their arguments, and offered bug reports. Buffer overruns are
probably still a problem, seeing as I've not upgraded the source to
snprintf.
> Rebuttal: False. It should be read-only by a user that you specify; in
> the case of cfingerd, I'd be more than happy to assign it a
> particular user (say, "finger") to own all of the files.
Yawn. This is the reply of a user that thinks running files as different
users in read-only mode will make any difference at all. With the
permission set at "root", I am assuring that ONLY root can read the
cfingerd.conf file, since ONLY root should run programs in inetd.
> Rebuttal: True, but what about those of us who don't want users running
> scripts anyway, or are willing to sacrifice that feature for
> security? This should be optional, or you might consider
> employing a modification of the minimal setuid wrapper that
> Apache 1.2 uses to execute CGI scripts for users. This would
> limit the necessity for a setuid binary to a single, tiny,
> auditable program, as opposed to your entire source tree.
Then, disable the script running ability. Besides, as far as I remember,
you can't allow users to run scripts; the scripts are created and run by
root, in a specific directory. I believe it was etc/cfingerd ...
> Rebuttal: Too bad. Seriously. This is a permissions issue; if the user
> in question doesn't want anything poking into their directory,
> they most certainly should be able to reject intrusions into it.
> As well, most users who make .plan and .project files available
> usually have other files in their home directory that are meant
> for public consumption (when is the last time you considered
> running a web server as root, so that users wouldn't have to
> worry about the permissions on their html directory trees?).
Then don't create a .plan or .project file. You're not forced to do this.
> Rebuttal: Ken, come on. This is a falsehood, pure and simple. I won't even
> go into this any further; this is attempting to make the users
> feel better about running as root.
How is running a program as nobody a falsehood? Are you a programmer?
Have you looked into these types of security when running a program as
setuid? Obviously you are not, otherwise you would KNOW that running a
program properly set as nobody CANNOT and WILL NOT read files owned by
root unless you screw up your permissions. But then, that comes down to a
system administration issue. If you're a good system administrator, this
will not even be an issue.
If they don't like the fact that cfingerd runs as root, then, my answer is
simple:
DON'T RUN CFINGERD.
> I understand that you've probably been careful with writing cfingerd, Ken,
> but running a server like this as root is asking for trouble. You compare
> cfingerd and sendmail; there's a reason I switched our systems over to
> qmail over sendmail. It's the same reason I'm considering scrapping
> cfingerd, and engineering one myself that does what I need.
Oh, okay, so is running telnetd, nfsd, rcpd, rsh, smail, mail, sendmail,
... shall I continue? Nothing in this world is perfect. Even qmail's
program runs setuid root and changes uids to the user in question. I'm
not a stupid coder, I'm not ignorant. I know what I was doing when I
designed it the way I did.
If you want to scrap cfingerd and write a finger daemon that does the same
things that cfingerd does with no security problems, I welcome to you to
do it. In fact, I would like to see another. I've stopped writing
cfingerd and any network protection related programs because of messages
like these. It's sad that there's people out there that think programs
should be perfect and bug free. If you think that, go run Microsoft
software.
> Plain and simple: cfingerd has no legitimate reason for running as root,
> but you have code in place to ensure that I, as the administrator, have no
> choice but to do so (the "this daemon must be run as root" problem).
Then don't run cfingerd. Plain and simple.
> Ken, have you found a new maintainer for cfingerd? If not...then David:
> would you be willing to integrate cfingerd into the NetKit package (with
> some security auditing)? Might make a nice addition...:-)
I've not found a new maintainer for cfingerd. And since I'm not going to
add any new features to it (ie. I have better things to do with my time
than handle a text parser that 80% of the people out there don't care
about anyway) I've thusly given up on the project, and 1.3.2 is the last
release.
Feel free to work on it.