关于AppLocker程序集的.NET DLL规则

Question

我使用AppLocker来阻止标准用户执行除我们签名的应用程序之外的任何东西，以及一些必要的Windows文件。

exe和dll文件使用signtool.exe使用我们的证书进行签名，然后在AppLocker中我有发行者规则，这些规则阻止用户运行未经我们签名的任何内容。

这是可行的，但它不能阻止已签名的可执行文件加载未签名的dll文件，这似乎是一种安全风险。我测试的方法是用未签名的版本替换所有的dll，只留下有签名的exe，打开dll规则，阻止任何未经我们签名的东西，并且应用程序运行得很好。EventLog没有显示任何潜在的块(我在审核模式下打开了dll规则)。

我读了一些，据我所知，原因可能是这些不是“正常”(Win32) dll，而是在CLR中编译和执行的程序集，它绕过了AppLocker dll规则？

如果是这样的话，确保dll不被篡改的唯一方法是进行程序集签名，给每个程序集一个强名称，这将确保exe只获取和运行这些特定的dll。这是正确的吗？

是否有任何方法使AppLocker dll规则阻止由CLR编译和运行的dll(程序集)？如果没有，那么即使对程序集dll进行签名也有什么意义吗？

更新：

感谢莫里齐奥发现了这个问题的原因，因为AppLocker规则在.NET 3.5上很好地工作，所以微软很可能刚刚破坏了.NET 4.0。他联系了微软，微软只是推荐使用WDAC而不是AppLocker.微软对这样悄悄地破坏人们的安全政策是非常不负责任的。

Answer 1

我们也看到了这种行为。根据我的测试，只有在用.NET 3.5编译加载动态链接库的情况下，它才能正常工作。

这是我的考验：

1. 我编写了一个简单的C#应用程序，它动态加载一个C#库/dll，它只计算两个数字之间的和。
2. 这个应用程序(LoadDLL.exe)是针对.NET 3.5和.NET 4.0+编译的，并添加了一个新的AppLocker规则。
3. Adder.dll (进行添加的库)是而不是添加到applocker规则中，所以我希望它在LoadDLL.exe加载时会被阻塞。

结果是，用.NET3.5编译的.NET3.5按预期工作--即阻止了Adder.dll的加载，而用.NET4.0+编译的LoadDLL.exe工作得很有魅力。

我认为，当.NET4.0被引入时，有些东西发生了变化，这使得DLL集合变得无用。