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

Re: SECURITY PROBLEM: autofs [all versions]



Mark Brown wrote:
> 
> On Mon, Jul 03, 2000 at 11:54:52PM -0400, Christopher W. Curtis wrote:
> 
> > I did a "chmod -x /sbin/portmap" and the init script barfed.  I saw that
> > it was testing '-f' instead of '-x'.  I suggested this change and
> > someone actually told me that this was correct behavior because it
> > *should* fail if it was -f and not not -x.  I consider that complete
> > garbage because if it was supposed to fail, what was the purpose of
> > checking at all?  Why not just do a "-z /dev/zero" because if it's not
> > there, it should fail anyway, right?
> 
> It's not so silly as all that.  The init script needs to perform some
> kind of test since it will persist if the package is removed but not
> purged.  Changes to the init script will also persist over upgrades,
> which can't be said for permission changes on binaries (dpkg will
> happily overwrite them).  If the test in the init script was for
> executability people who wanted to disable portmap would probably do
> that, find it works and then wonder why portmap suddenly started running
> again after they upgraded netbase.  Having it fail noisily is annoying
> but pervents nasty surprises.

You're reasoning seems almost plausible, but still flawed.  Again, if
that is the intent, then instead of failing at all, it should print a
warning that says, "You have disabled foo.  If this package is upgraded,
it will be reenabled." because it is not an error.  It was disabled
intentionally and intentionally not removed so programs like tripwire
don't get upset, or maybe smart package managers will perform an md5 sum
and do something special if the binary was modified (or in this case,
removed).

Besides, failing noisily requires that someone be sitting in front of
the machine at boot time and watching messages.  If that is the case, I
can assure you that they are going to notice things starting up that
they know they disabled, and failing noisily doesn't do anything to
change that situation over an update.  Instead of failing noisily, it'll
just start up as usual anyway.  You're only asserting that the lack of
an error will be more noticable as an error.  This may be reasonable for
a single package, but if it is the case for 4 or 5 packages, things are
going to scroll off the screen so fast that the user won't be able to
make heads or tails of it at all.

Christopher



Reply to: