代码访问安全是个笑话？
我刚刚阅读了这篇关于代码访问安全性的文章。它有这样一个例子：
using System.Security.Permissions;
public class MyFileAccessor
{
public MyFileAccessor(String path, bool readOnly)
{
path = MakeFullPath(path); // helper fcn
FileIOPermissionAccess desiredAccess = readOnly
? FileIOPermissionAccess.Read
: FileIOPermissionAccess.AllAccess;
FileIOPermission p = new FileIOPermission(desiredAccess, path);
p.Demand();
//
•••
open the file
}
// •••
}
如果我不使用 FileIOPermissionAccess 类型并且在我的代码中根本不包含像 p.Demand() 这样的代码会怎么样？换句话说，如果我想做坏事，我为什么要费心去征求许可呢？这不是一个笑话吗？或者我理解错了？
I have just read about this article about Code Access Security. It has such an example in it:
using System.Security.Permissions;
public class MyFileAccessor
{
public MyFileAccessor(String path, bool readOnly)
{
path = MakeFullPath(path); // helper fcn
FileIOPermissionAccess desiredAccess = readOnly
? FileIOPermissionAccess.Read
: FileIOPermissionAccess.AllAccess;
FileIOPermission p = new FileIOPermission(desiredAccess, path);
p.Demand();
//
•••
open the file
}
// •••
}
What if I didn't use the FileIOPermissionAccess type and never includ code like p.Demand() in my code at all? In other words, if I want to do something bad, why should I bother to ask permission for that? Isn't it kind of a joke? OR did I take it wrong?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
嗯，是的，这个例子有点开玩笑，你自己永远不会写这样的东西。缺少的是真正重要的部分，即打开文件的代码。例如，它的实际版本会调用 CreateFile()。
关键是 Windows 对 CAS 一无所知。因此，如果您提供这样的实用程序函数并且想要强制执行 CAS 规则，那么您必须验证您的调用代码是否具有所需的权限。当然，这种代码实际上只属于.NET框架。看一下 FileStream.Init() 和请注意，在 CreateFile 调用之前需要 FileIOPermission。
Well, yes, the example is a bit of a joke, you'd never write something like this yourself. What's missing is the really important part, the code that // opens the file. A realistic version of it would, say, pinvoke CreateFile().
The point being that Windows doesn't know anything about CAS. So if you provide a utility function like this and you want to enforce the CAS rules then you have to verify that your calling code has the required permission. Of course, this kind of code really only belongs in the .NET framework. Have a look-see at FileStream.Init() and note FileIOPermission being demanded there before the CreateFile call.
文件访问（例如使用
FileStream）将自动请求FileIOPermission。对于所有标准类来说都是如此，当他们执行某些需要许可的操作时，他们会自动请求它。请在此处下查看 .NET Framework 安全性。所以示例代码是没有用的，没有人会明确要求文件权限。如果您开发一些 API 并且您的代码经过签名，这样就没有人可以更改它，这是合理的。进一步阅读，以下是该文章的引用：
File access (for example using
FileStream) will automatically demandFileIOPermission. And this is so for all standard classes, when they do some action that require permission they will demand it automatically. Look under .NET Framework Security here. So the sample code is useless, no one will explicitly demand file permissions. It is reasonable if you develop some API and your code is signed so that no one can change it.Read further, here is quote from that article:
在 java.io API 内部，您可以确保正在进行检查。如果您想控制访问（在崩溃发生之前绕过崩溃），您必须在 API 调用进行内部检查之前进行适当的检查。
Java 代码通常在您控制的计算机上运行，但也经常在您无法控制的计算机上运行。想想 Java 小程序。他们应该请求访问文件系统的权限，因为程序的作者不应该被允许未经检查地访问其他人的文件系统。
如果您需要阻止一群人做出恶意行为，那么您需要阻止每个人可能做出恶意行为，以实现真正的安全。否则，作恶者只会说自己是受信任、不受约束的群体的一部分。
默认情况下，Java 命令行可执行文件运行时具有允许您访问自己的文件系统的权限。假设是，如果您在本地启动该程序，则可能会弄乱您有权访问的文件系统部分。小程序启动时会删除所有这些默认权限。这样，浏览小程序所在网页的人必须手动授予远程程序（小程序）访问其文件系统的权限。
您看到的这证明没有特殊的后门可以绕过某些用户（或在某些情况下）的安全性。
Inside the java.io APIs, you can assure yourself that the checks are being made. If you want to control the access (bypassing a crash before it happens) you must make the appropriate checks PRIOR to the internal checks made by the API calls.
Java code often runs on computers you control, but it also often runs on computers you don't control. Think of Java applets. They should ask permission to access the file system because the author of the program shouldn't be allowed unchecked access to everyone else's file system.
If you need to stop one group of people from doing something malicious, then you need to stop everyone from possibly doing something malicious for the security to be real. Otherwise, the ill-doers will just say that they are part of the trusted unchecked group.
The Java command line executable runs by default with permissions to allow you to touch your own file system. The assumption is that if you launched the program locally, you could have messed up the portions of your file system you had access to anyway. Applets launch with all of these default permissions removed. That way the person browsing the web page where the applet resides must manually grant permissions for a remote program (applet) to touch their file system.
That you see this is proof that there isn't a special back door which bypasses security for some users (or in some conditions).