[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Stop reporting non-bugs as bugs!



"Jakob Bøhm Jensen" <jbj@image.dk> writes:

> > #24895
> > 
> This is a summary post, please refer to all the other reports
> for details.

It is best not to duplicate bug reports.

> >   DOING AN INSTALL IS NOT THE SAME AS DOING AN UPGRADE.
> > 
> I *did* put in an apology in case my testing was flawed.

The same one in every post :-)

> > #24907
>
> I consider it a bug, because the documentation brags about its ability
> to hide information and because such hiding tactics is part of
> *my* security policy.
> I would not have complained if this was the only cfingerd bug.

It hides information finger normally reveals.  This type of thing can
easily be found out elsewhere.  If you prefer not to have it revealed, 
modify the configuration.  Because, as you say, it is *your* security
policy.

> > #24908 complaints that cfingerd runs programs from path.
> >   This is not a problem because cfingerd is started from inetd in
> >    Debian, so the path is KNOWN GOOD.
> > 
> This is one of those far-fetched ones. It was found when tracking down

Yes indeed :-)

> other issues and is reported because the documentation suggests
> different behaviour, by showing off all the places where this does
> not happen.

Anyway, it's not a problem from inetd.

> > #24909 complains that cfingerd reveals it is cfingerd.
> > 
> >   So what?  And it's hardly a "back door" as the submitter reports.
> >   Most daemons reveal their name and version number.
> 
> It is a back door because its existence is not documented (without
> my documentation patch that is).

A "back door" means a secret way for the author of the program to gain 
access to the system, intentionally placed in a program and unknown to 
the users/administrators of systems running that program.  (see Jargon 
file, I'm sure it's in there.)  Revealing that it's cfingerd is not a
back door.

I'm sure sendmail doesn't document that it reveal's it's sendmail when 
you telnet to the smtp port, but nevertheless, it does do that.

> > #24899 complains that the configuration refuses connections from
> >        machines with no identd.
> > 
> >   Not a bug.  Modify the configuration.
> > 
> I am complaining about a bad default, which is part of the package.

If you really want security, this is not bad, but good.  It can be
argued either way.  Our situation is an all-Unix house -- any fingers
from people with no ident are immediately suspect.

> > #24897 has changes to documentation.  Not a bug.  Send it upstream.
> > 
> The documentation is part of the package, the bug-reporting policy
> suggests including a fix if possible.  So I did.  There is no known
> alternate method for reporting bugs in documentation.
> 
> As for upstream, all recent development has been done by the
> Debian maintainer, and released as a Debian package.

This I did not realize at the time.  Your actions were correct then.
(although some of the changes to the docs need to be reexamined.)

> As for the setuid stuff, it seems the original developer got it
> wrong.  The package claims running all external programs as
> nobody, but leaves the real uid set to root, which allows the script
> to double back as illustrated.  Source code comments say that this

I saw no illustration.

> will happen, but the documentation says the opposite.

Yes, you say this now.... :-)

Before you were saying incorrect things about exec:

  "as long as cfingerd can issue a sequence of system calls to regain
   root privileges, so can any script invoked from cfingerd"

(which is false as I have demonstrated -- exec throws away some information).

Your example also pointed to the fakeuser scripts, which are written,
owned, and protected by root (and so are not good examples of any
incorrect behavior.)  Had you done an example with a user script
(which would be a security hole), included a believable reason for the
problem as you have done now, then the bug would have been fixed
before hamm was released.  As it was, your description was incorrect,
no bad behavior could be duplicated, and so it appeared to everyone
that you were somehow confused.

The problem you describe now is part of what I have fixed in my NMU,
and I agree with it (and gave you credit even before seeing this
latest message in my security warning, BTW).

(Note though that the relevant code also goofs up badly with gids,
which you didn't mention at all.)

In summary, thanks for reporting these two issues.  The bug reports at 
least put us on the right track. :-)

However, I do still believe that simply because the default
configuration settings do not agree with how you want it does not
provide grounds for submitting a bug.

(Just imagine if everybody submitted a bug because they want a
different background color in X.)

Thanks,
John

PS... please do not let this discourage you from submitting bug
reports in the future.  However, please do take a bit more time to
verify the correctness of your report first.

-- 
John Goerzen   Linux, Unix consulting & programming   jgoerzen@complete.org |
Developer, Debian GNU/Linux (Free powerful OS upgrade)       www.debian.org |
----------------------------------------------------------------------------+
Visit the Air Capital Linux Users Group on the web at http://www.aclug.org


--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


Reply to: