Re: Nomination question: Redhat
On Sun, Dec 13, 1998 at 03:03:39PM -0500, Michael Stone wrote:
> Quoting James Troup (james@nocrew.org):
> > This is the worst possible kind of FUD. Yes, Redhat did have some
> > programs inadvertently SUID, but then have you even bothered to check
> > how many SUID binaries we have and how valid their SUIDness is? It's
> > not a pretty sight. You also failed magnificently to remember the
> > recent fte fiasco, which was far worse than anything Redhat have
> > done[1].
>
> But IIRC, the fte thing wasn't in a release version, was it? If you're
> running a pre-release, you take what you get. OTOH, it's a good example
> of why an open development model is a Good Thing: it got caught _before_
> we sent it out on thousands of cd's.
It's been in there for a long time....it could have been reviewed and
caught first. It was purely by accident that it was caught. If I had not
been looking for a different editor with syntax highliting, it may have
been put into the release. If it was caught by being audited I might feel
better about your assumption.
Not to place blame, but i was really worried to find that the maintainer
was not concerned that it was doing this, and thought that it was working
as it should, even after I explained it to him. I definitely think we need
better auditing of these security critical packages starting with any new
package that contains a suid/sgid binary being checked before being placed
in the archive. Then any package that contains a binary that is suid or
sgid should be reviewed periodically.
It may even be prudent to review any packages that are run as root and
open a listening port (daemons of any kind). Problem is who and how.
Good thing is that the vfte binary (the bad binary) will no longer be
supported in the fte source, but will instead be replaced by a version
compiled against slang which wont need to be suid or have special
permissions (this according to the maintainer). IMO, this is better any
way since vfte can only be used on the console (not on a remote login
session such as telnet/rsh/ssh).
--
----- -- - -------- --------- ---- ------- ----- - - --- --------
Ben Collins <b.m.collins@larc.nasa.gov> Debian GNU/Linux
UnixGroup Admin - Jordan Systems Inc. bcollins@debian.org
------ -- ----- - - ------- ------- -- The Choice of the GNU Generation
Reply to: