Longhorn Blogs: let MS know that this is NOT what we want

"... I am tired of Windows being catered to idiots, if I want to run unsigned drivers then I will.  It is my computer, STOP telling me what I can and cannot do with it."

http://www.longhornblogs.com/chris123nt/archive/2006/07/23/16462.aspx

*Although this article refers to vista64bit - i couldnt help but feel an Un-User in Control disturbance in the force... 32/64 or otherwize

jamie wrote:

"... I am tired of Windows being catered to idiots, if I want to run unsigned drivers then I will.  It is my computer, STOP telling me what I can and cannot do with it."

Couldn't agree more....

most people know well enough to not mess with things they don't understand

Ang3lFir3 wrote:

most people know well enough to not mess with things they don't understand

I erased my first two replies on the grounds that they came off too cynical and/or inappropriate. Let's just say I disagree with you on this one.

...but if they do understand - they should be able to do it

..not prohibited from it
?

Yggdrasil wrote:



Ang3lFir3 wrote: most people know well enough to not mess with things they don't understand

I erased my first two replies on the grounds that they came off too cynical and/or inappropriate. Let's just say I disagree with you on this one.

i was dreaming a little there wasn't I?... the truth is tho that they may not know well enough to leave it alone, but honestly I'm of the group that feels if they don't leave it alone then they get what they deserve.....

re-reading my first comment i really shouldn't give people so much benefit of the doubt....

It's this or john doe searching the internet to find how to install unsigned drivers, and go next, next, next. Because some provider of a product doesn't got signed drivers, and when it is possible to use unsigned drivers, it will be used. Then the situation will never improve, some products might even give you a howto install our unsigned driver on the readme page. This way security will never improve.

"64-Bit Security Enhancements: Kernel Patch Protection and Mandatory Driver Signing

Some of the most dire security issues arise from malicious software that manipulates the operating system “kernel,” rendering malicious software undetectable to anti-virus software and running unnoticed on a user’s system. These “rootkits” are often used to cloak other potentially unwanted software, such as bots and spyware. Beyond the serious security implications of rootkits, this class of malicious software can reduce the stability, reliability and performance of the entire system, including all user programs.

Addressing these problems has been difficult because many 32-bit Windows drivers are not identified with a digital signature, or they modify the kernel for legitimate purposes but by unsupported means. Implementing stricter control over these modifications could create major compatibility and performance issues. Some 32-bit security products that provide behavior-blocking capabilities modify the kernel through unsupported methods; accordingly, Microsoft is partnering with third-party security vendors to investigate robust, secure and supported alternative platform mechanisms.

However, as computing moves from a 32-bit to a 64-bit architecture, the smaller installed base of 64-bit software makes it possible to make significant enhancements to the security of the kernel, reducing the potential for rootkits and similar types of malicious software to negatively impact users’ systems."

"Mandatory Kernel Module and Driver Signing for x64.

To give users visibility into the source of drivers and other software running in the operating system kernel, Microsoft introduced the concept of “signed drivers” beginning with Windows 2000. Although it was possible to prevent unsigned drivers from installing, the default configuration only warned users if they were about to install an unsigned driver. IT administrators could also block installation of unsigned drivers via Group Policy, but the large installed base of unsigned drivers made this impractical in most situations. Malicious kernel software typically tries to install silently, with no user consent — and because no kernel load-time check existed before Windows Vista, malicious kernel software was likely to run successfully, assuming these actions were performed by a user with administrative privileges.

With Windows Vista on 64-bit systems, security at the kernel level has been greatly enhanced by requiring that all kernel-mode drivers be digitally signed. Digital signing provides identity as well as integrity for code. A kernel module that is corrupt or has been subject to tampering will not load. Any driver that is not properly signed cannot enter the kernel space and will fail to load.

Although a signed driver is not a guarantee of security, it does help identify and prevent many malicious attacks, while allowing Microsoft to help developers improve the overall quality of drivers and reduce the number of driver-related crashes.

Mandatory driver signing also helps improve the reliability of Windows Vista because many system crashes result from vulnerabilities in kernel-mode drivers. Requiring the authors of these drivers to identify themselves makes it easier for Microsoft to determine the cause of system crashes and work with the responsible vendor to resolve the issue. System administrators also benefit from digitally signed and identified drivers because they get additional visibility into software inventory and install state on client machines. From a compatibility perspective, existing Windows Hardware Quality Labs certified x64 kernel drivers are considered validly signed in Windows Vista."

from Microsoft Windows Vista Security Advancements (June 2006) page 7-8
http://download.microsoft.com/download/c/2/9/c2935f83-1a10-4e4a-a137-c1db829637f5/WindowsVistaSecurityWP.doc

My impression is that Microsoft's working to find the proper carrot/stick balance to improve the "hygiene" of their system. In the case of drivers, I can see why Microsoft wants to be careful with anything that runs in kernel mode. It may be drastic, but in light of the "dancing bunnies" phenomenon, I don't think it's as outrageous as the blogger wants to make it seem.

As to the more general question of whether or not users should be allowed to shoot themselves in the foot, I'm ambivalent. I strongly believe that software should be designed to "just work" as often as possible. If the conceptual model is flawed, then the onus should be on the developers, not the user, to fix it. OTOH, it's not unreasonable to accept that sometimes you may not be able to come up with a one size fits all solution.

It may sound condescending--and I certainly don't mean to come off that way--but experience has taught me that you can't take most things you hear from users at face value. When someone says "I want to arrange things this way because it's more logical to me", it's a good idea to take a step back for a moment and think. Often you'll find that either (1) your usage model is broken or (2) the user's understanding of the usage model is incomplete or even flawed. I once met someone who was convinced that keyboard keys should be arranged in alphabetical order; he was otherwise brillaint, but he didn't understand the rationale behind the current arrangement (nevermind the fact that the QWERTY layout is supposedly suboptimal).

Again, I'm not saying everything has to be one size fits all, but people are more alike than different in terms of human factors (with some exceptions for disabilities).

jamie wrote:

...but if they do understand - they should be able to do it

..not prohibited from it
?

I believe setting the "allow installation of unsigned drivers" local policy default to "off" instead of "ask" will be good enough.

Be able to change local/group policy settings could be used as a sign that they "know enough".

cheong wrote:



jamie wrote: ...but if they do understand - they should be able to do it ..not prohibited from it ?

I believe setting the "allow installation of unsigned drivers" local policy default to "off" instead of "ask" will be good enough.

Be able to change local/group policy settings could be used as a sign that they "know enough".

This will break there idea for the improved security step => only providing a selected group (signed drivers) access to kernel parts of vista. (Well as far as I can understand the concept.)

It might look like a high step up, but I gues it needs to be done sometime. And this isn't a bad moment, because the x64 platform is still 'fresh' and not filled with drivers. 
 
While as a user I would really like the option to turn it off, but this time it's not about me. It's about restricting or prohibit the manufactors of hardware to create unsigned drivers and you will only archive that if they need to provide signed drivers instead of having a choice. As soon as there is a choice there will be a group that won't provide signed drivers.

Yes, atm this looks like a big problem, because Vista is still in beta and there probaly aren't that many signed drivers as there are unsigned. The introduction of windows xp also gave problems with drivers for the first year, most works fine today except for real old hardware.

I wish there was a driver signing blog so we could understand the processe.

 

I want all my drivers to be signed, but the manufactures need follow steps and procedures that cost them more money then they care to pay.  

In 5472 ye olde "bcdedit /set nointegritychecks on" doesn't work anymore (bcdedit claims it succeeded but it has no effect) so now I have to remember to press F8 and choose "disable driver signature enforcement" every time I start the computer otherwise my sound won't work (stupid unsigned Creative drivers).

cheong wrote:


I believe setting the "allow installation of unsigned drivers" local policy default to "off" instead of "ask" will be good enough.

Be able to change local/group policy settings could be used as a sign that they "know enough".

Won't work.

There are a large number of driver installers that change the setting to "enable" before installing, so the users don't get prompted. Some of them are kind enough to put it back afterwards, but don't count on it. There are probably almost as many that just hack around in the registry to install the driver without doing so correctly.

In any case, I disagree that this is about a user choice issue. It's about forcing manufacturers to start doing some actual quality testing on their kernel mode code, something which is all too often lacking. If there is one place you really need good reliable code it's in the kernel, so it makes good sense to put in place measures to improve the quality of third party code that runs there. Hopefully this will eventually lead to more and more user-mode driver support, which will ultimately improve things.

The side-effect of reducing the attack surface for rootkits and spyware is another positive benefit.

Ang3lFir3 wrote:

most people know well enough to not mess with things they don't understand

You've never done IT work or tech support have you?

Jason Cox wrote:



Ang3lFir3 wrote: most people know well enough to not mess with things they don't understand

You've never done IT work or tech support have you?

QFT.

Ang3lFir3 wrote:

I'm of the group that feels if they don't leave it alone then they get what they deserve.....

If the consequences only went as far as "User made a mistake, user screws up his computer" then I would say we can leave well enough alone. The problem is that a user who compromises his system becomes a vector for further infection, and in effect becomes a part of the spread of malware. Saying "it's the user's fault" doesn't mean the customer can't legitimately come to the software vendor with a demand to reduce the attack surface as much as possible.

_I_ want to be able to run unsigned beta drivers on my machine, however MS is preventing me from doing to because it's catering to the raging moron. What's even the point in restricting this to the x64 version only, which is in the minority, while still allowing unsigned drivers on the x86 version? Stupid I say.

But no, instead my favorite tools get screwed royally. No more Daemon Tools or TrueCrypt. I guess no Vista for me until someone figures out how to disable mandatory driver signing.

Tom Servo wrote:

What's even the point in restricting this to the x64 version only, which is in the minority, while still allowing unsigned drivers on the x86 version? Stupid I say.

That's exactly the point: x64 deployments are currently the minority.

Trying to enforce this on 32 bit systems just isn't going to work. There are just far too many badly written bits of software which rely on being able to hook directly into the kernel and too many unsigned drivers out in the wild that aren't ever going to get updated.

x64 represents the best opportunity to change the tide and get developers following best practices.