Exactly my point on signing - you’re not protected on silent loads or
installs of non-AV FS filters via an INF. I was merely pointing out that
the protection isn’t there if you have privileges to install drivers.
Yes, all drivers should be well written and any driver can crash the
system. Stability is not just an issue for FS filters and FSDs. However,
ask anyone who’s written device drivers then moved to FS filters or FSDs
about the complexity differences. I find it hard to believe that you’ll
find many who’ll say they’re the same. I don’t mean that as any kind of
putdown on non-FS drivers, it’s just based on my observations.
Administrators usually are very good about restricting installs on key
systems but there are still cases where things get installed that may
destabilize a system. That happens, it’s just human nature. I guess I
like to error on the side of a good defense and avoid anything that can
potentially bring down a system. It’s one thing to do it on a test
system but another if it “leaks” out and gets on a production system.
My goal is to protect my customer’s systems as much as possible even if
it means jumping through some hoops to do it. I’m motivated by the fact
that I am responsible for a product that protects a system and I’m just
naturally cautious in that respect.
I imagine everyone’s tired of our debate. I’ve enjoyed it even if it
seems otherwise. Thanks Peter. This has been a good exercise.
–jerry
-----Original Message-----
From: PeterB [mailto:xxxxx@inkvine.fluff.org]
Sent: Wednesday, November 28, 2001 9:35 AM
To: File Systems Developers
Subject: [ntfsd] RE: Converting NT Driver to XP
On Tue, 27 Nov 2001, Kelley, Jerry wrote:
I’d dare to say that many who use NT log in via an administrative
account and therefore installing drivers or services is allowed. Given
that, you could silently install drivers and/or services and not know
for sure what you’re putting on a system. Of course, there’s driver
signing but that only applies to AV FS filters.
Silently loading and unloading drivers doesn’t cause signing warnings
anyway; signatures are checked on installation, not on load; to avoid
the
warnings, don’t bother installing the thing with a .inf and all is
well. Driver signing has never provided protection against this kind of
activity.
Which brings me back to my original point, what happens if I install
an
application that silently inserts an FS filter in some IO stack
without
my knowledge? What also happens if that filter is poorly written or
malicious?
what happens if I install a regular filter/driver? What happens if that
driver is poorly written or malicious?
To be consistent, you should advocate that all driver development
require NDAs and expensive toolkits. These problems are by no means
unique to that particular kind of driver.
My reply would be that if you’re going to run as an Administrator, you
must bear some responsibility, and *be careful*. Yes, Administrators
can
install drivers and services. Reducing the ease with which one might
write an FSD on the off chance that someone might write a malicious FSD
is
missing the point, IMO. The point should be – Administrators, be
careful; you can compromise or crash the machine.
I have spent countless hours crawling through crash dumps and
debugging
deadlocked systems chasing after interop issues. It’s hard enough for
the commercial products to get all the issues addressed when you do
this
full-time. Invariably, someone installs a filter with all good
intentions and an interop issue pops up. You have to be very careful
writing FS filters or some very bad things can happen.
FS filters are not the only kind of filter. FSDs are not the only kind
of
driver. I’m not convinced that they’re significantly more dangerous
than
any other kind of driver; other drivers/filters can suffer interop
issues
too, other drivers/filters can crash your machine.
–
Peter
xxxxx@inkvine.fluff.org
http://www.inkvine.fluff.org/~peter/
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com