@EterNalReality 后台各种迅雷，P2P 视频软件，或者人家根本就是在挂 PT

为什么不用真实姓名？

@acess
file system filter drivers 有好几种。
微软的文档表示，legacy file system filter drivers can ’ t attach to direct access (DAX) volumes。
我仔细翻阅了一下文档看来是我有点想当然了，File ​ System ​ Filter ​ Drivers 里面要看你把驱动 attach 到什么地方。
如果只把 Filter Device Object Attach 到 File System，那么就只能拦截 IRP_MJ_CREATE 之类的不能拦截 IRP_MJ_WRITE。
如果 Filter Device Object Attach 到 Volume 上，那么就可以拦截 IRP_MJ_CREATE。
File System Minifilter Driver 也是类似的情况，看开发者怎么使用了
我表示没有调试过，IRP_MJ_WRITE 的具体拦截情况，看文档应该是有办法拦的，但是实际上我会觉得拦截 IRP_MJ_CREATE 这样的请求意义不是很大，绝大多数的程序不需要直接进行底层磁盘写入，如果要驱动来判断直接写入扇区是不是应该允许未免是个巨大的工程。一般不需要在这一步进行拦截，如果只是为了防止写入，拦截 IRP_MJ_CREATE 就足够了。

@acess
调用链方面中间有些省略，不过大致上是这样的。
在 ntdll.dll 中 Nt*函数和 Zw*函数功能是相同的, Nt*函数是 Zw*函数的别名.
ntoskrnl.exe 中 ZwCreateFile 会最终调用到 NtCreateFile
在你看到的调用栈里
NtCreateFile 这里使用 IopCreateFile，ObOpenObjectByNameEx 从名字上就能看出来，目的是把名字转换成 Object 对象，在这转换过程中触发了 IRP_MJ_CREATE

只能自己设置小一点的 TTL 减少缓存的时间。
不过依然得等缓存失效才行。

接楼上，做个更正 NtCreateFile 是调用 IoCreateFile，由 IoCreateFile 来发起 IRP 的。这个是我疏忽了。

@acess
应该是可以拦截到的
从调用链就可以看出来。
CreateFileW （\\.\PhysicalDrive0 ）—》 ZwCreateFile->NtCreateFile
NtCreateFile 会向驱动层的最上级驱动发起 IRP_MJ_CREATE，然后 IRP_MJ_CREATE 这个 IRP 会依次按照顺序发送到下级驱动中，直到最后发送到磁盘驱动。
File System Filter Drivers 想拦截拦截文件的打开就一定会在这个调用链中，所以 File System Filter Drivers 有能力拒绝这样的行为。
而对于直接向磁盘写入这种行为来说。
WriteFile-》 ZwWriteFile-》 NtWriteFile
NtWriteFile 产生的 IRP_MJ_WRITE 不会交给 File System Filter Drivers，因为要写入的并不是一个文件系统的对象，所以 File System Filter Drivers 并不会接收到这个 IRP_MJ_WRITE。

@acess
这完全取决于开发者希望产生什么样的效果，比如我要开发一个文件透明加密的驱动，那么我就没有必要防程序直接读取或者写入磁盘的这种行为，因为不会影响到我的程序功能。
一般安全产品在这方面的处理方法也是简单粗暴的，可能有些 HIPS 会直接弹个窗，警告一下，如果允许了剩下的事情 HIPS 也不管。
这个是开发难度与产品功能之间做出的妥协，安全产品当然也可以直接接管更加底层的 IRP 请求，但是那又会面对一堆乱七八糟的问题，比如稳定性方面的问题。

@acess
@ahhui
我解释一下 open \\.\PhysicalDrive0 这种行为。
对于 File System Filter Drivers 来说，open \\.\PhysicalDrive0 这样的行为 Filter Drivers 会收到一个 IRP_MJ_CREATE 的请求，如果 Filter Driver 在针对这个请求直接拒绝，那么直接打开设备的操作明显会失败。这里不存在所谓绕过这么一说。只是取决于驱动怎么处理直接访问设备的请求，如果驱动对此没有拒绝，后续的操作因为直接是针对设备块的读写（其实就是直接向磁盘驱动发起了 IRP ）并不涉及文件系统，所以 File System Filter Drivers 无法拦截后续的读写操作，这看起来就像是，绕过了，但是实际上只是驱动不想粗暴的拒绝而已。
如果要拦截底层的磁盘访问的 IRP 请求当然也是有办法的，不过这又是另外一个话题了。

@RE 不会

@acess 吊销的问题是微软实现方面的问题。这一点我了解的不多，不过微软完全有能力随时发布更新来解决这些问题。
DSE 确实带来了很多问题，也是无可否认的，个人几乎很难在独立开发驱动。不过微软这方面的要求也不是不能理解，因为大多数蓝屏的问题并不是 Windows 自身的问题导致的，几乎都是第三方驱动形成的。在驱动层面开发是很麻烦的事情，普通的 app 如果犯了一个除 0 的错误，也就只是收到一个程序崩溃的提醒，可是驱动层面上那就直接蓝屏了。（其实某种层面上蓝屏是相当好的保护措施）通过 DSE 这样的手段来限制一些开发者这大概才是微软的目的所在。至于未来版本的支持。。内核上很多地方是未公开的，每一个版本都可能会有些许不同，而驱动们为了达到各种各样的目的可能又必须依赖于这些未公开的地方，所以驱动上兼容各种版本是相对比较困难的。微软其实就不想让开发者动内核，什么 hook SSDT 这种事情根本就不是什么正规手段，所以才有了 PatchGuard 这种东西来阻止对内核的修改。

@hx1997 JOB 和 AppContainer 可能后续会加入。有这方面的计划，不过嘛级别可能比较靠后。

@acess 这种都是互相权衡的，毕竟还是要以正常使用为第一前提。数字证书有有效期，但是数字证书签出来的签名不能说因为数字证书有效期过了就不认。一张数字证书的有效期少则 1 年多则 3 年 5 年，如果因为数字证书过期就拒绝那么也就意味着你系统中的所有驱动必须每隔几个月就更新一次，否则可能会无法启动。至于签名出来的时间戳，纯粹只是用来表示发布时间的，并没有什么特别的意义。
这个过程和签名一样，一个人签署的合同，不能说因为签署人挂了这份合同就是无效的。
获取数字证书始终是有成本的，这一点也是毋庸置疑的。

namesilo +1

@acess 微软为什么要阻止天翼客户端加载驱动？微软不是神，不能包办一切。。。不管一个驱动是好还是坏，如果符合要求就允许加载是没有问题的，这方面不要指望太多。

@acess
微软一直都有做根证书更新这件事情，从未停止过。
进入了 RING0 层，在驱动级别的对抗是永无止境的，事实上也没办法阻止驱动干点什么事情，最根本的还是阻止加载驱动。

@hx1997
权限始终是用来保障控制的一种手段，对于无法覆盖到的地方自然是没有办法，但是也不应该用脆弱来形容。
对于窗口确实没有太多办法，毕竟权限不是主要用于处理窗口方面的问题的。
至于其他的攻击面，其实是和使用方法有关系。如果能做到更为细化的权限控制，那么这些问题其实并非不能解决，比如勒索软件，如果创建一个用户拒绝访问文档有关的目录，并且使用该权限来运行勒索软件的话，那么很显然勒索软件尝试加密的操作将会直接失败。（当然如果你一定要谈使用不支持 ACL 的其他磁盘格式那也是没办法的）
注册表的问题也是一样。

我开发 wesuex 这个产品的目的就是希望能更加细化一些权限方面的管理，通过这个产品我们可以让不同的程序运行在不同的权限或者用户下，这样我们就可以拒绝不必要的权限加以限制。比如创建一个拒绝访问 D 盘的用户，那么用这个用户来运行一个程序，这个程序就不能扫描到 D 盘的隐私内容了。这个是我理想中的用法，当然虽然现在做的不好，但是还是可以努力一下。

@acess 对，花钱当然是没问题的，但是至少提高了攻击成本。本来我写一个驱动，抛开人工成本，电费成本，开发出来基本上不用花钱就能做出来攻击一大批人。需要数字签名的话，那么我就得额外多花一个数字签名的费用，并且大规模的攻击就不太容易实现了，因为大规模的攻击更容易被发现，导致数字签名被吊销。
至于证书的过期时间，我了解的不太多，但是据我了解，证书本身有过期时间，可是签名出来的文件是没有过期时间这一说法的。如果签名用的证书过期了就不允许加载这个驱动，那可能你会发现某一天突然你的电脑无法启动了，因为证书过期了没有更新。
至于吊销列表微软完全有能力发布更新来解决，但是说到底，封堵第三方应用的漏洞就不是微软该干的工作。不怕神一样的对手就怕 X 一样的队友，放在安全上尤为适用，因为安全问题永远出在最薄弱的地方。

@hx1997 权限控制是依赖于内核的安全性的，只要内核保持在最新（打补丁）的状态这种安全性并不脆弱。如果打破内核的权限控制基本上就是内核的漏洞。在这一点上来看，安全性基本上可以保证，并不脆弱。如果有人能突破，可以致电微软领取奖金。

@acess
IE 的保护模式实际上就是对 IE 做了一些限制。在 IE 的保护模式下，IE 进程设置了 Administrators 组为拒绝，并且设置了 Low Mandatory Level （低进程完整性级别）。IE 进程想对系统做出修改就必须提升权限，实际上也就是标准账户提升到管理员账户的过程，并且由于一般用户默认的都是 Medium Mandatory Level （中进程完整性级别）所以实际上 IE 在保护级别下得到的权限比一般标准账户的权限更低一些，当然要提权也会更加困难。
浏览器存在漏洞是无可避免的，所以才需要经常更新。微软也好 Google 也好，保证的就是公开的能导致安全问题的漏洞都会被修复，所以只要保持更新“不下载、运行就是安全的”这种印象是基本上正确的。退一步，即使浏览器存在漏洞导致了代码被执行，也会有 DEP,ASLR 这样的安全机制来妨碍代码的执行，虽然这些保护是可以绕过的，但是毫无疑问的提升了代码的执行难度，有相当多的漏洞可能因为绕过这些安全机制的必要条件无法实现而导致实际上无法利用。（并不是说有漏洞就一定能被利用，并且成功入侵，这样的理解是不正确的）我们在退一步，即使有漏洞，能绕过 DEP,ASLR 这样的安全机制，成功的运行起来了，代码仍然会运行在低权限下，想对系统进一步进行修改，那么就必须提高权限，想要提高这样的权限，如果没有用户许可又必须使用内核漏洞来实现。虽然这些安全机制单点都是可以破解的，但是复合起来很显然会发挥更强大的功效。
一种安全机制的出现与其说是为了彻底杜绝某类攻击，不如说是大幅提高攻击成本。就像楼主举得例子，Windows 要求加载的驱动必须有数字签名，那么攻击者去签发一个带数字签名的证书不就得了？说起来很容易，可是数字证书是要花钱的，并且个人不能申请对代码签名用的证书，一般要求是公司进行申请，申请成功之后，如果证书被发现用于恶意软件，那么证书还可以被吊销。
我不能说要求驱动必须进行数字签名是一个好方法，但是这样的手段确实提高了攻击者的攻击成本或者攻击难度。

就目前的情况来看。
已经公开的，没有发布补丁的，在最新版 Windows 下从标准账户权限加上中等完整性保护级别，不需要任何特殊条件只执行一段代码就能提权到管理员权限或者更高权限的方法是不存在的。这一条正是微软一直在守护的底线，如果有技术逾越了这条底线，微软是一定要修复这个问题的。
在这样的基础上，其实已经足够保障一定程度的安全性，至少代码不能随意破坏系统，这其实已经足够了。
顺便，既然谈到权限问题，我最近正好写了一些代码对 Windows 权限的管理做出了一些补充方案。
取名 wesuex，代码和生成的二进制文件已经放在了 github 上，使用说明在此 https://www.exvs.org/?p=430
通过 wesuex，可以一定程度的加强权限控制，比如创建的受限制进程，大多数情况下将无法在通过其他方法提权。可以算作是一种补充性的方案。