在Silverlight发布时,微软宣称它将是一个完全跨平台、跨浏览器的下一代富客户端开发技术工具。但在使用绚丽功能的同时,很多人会思考Silverlight是否能够一如既往地实现不同平台间托管代码执行的安全性?答案是“除了安全,您没有别的选择”。
.NET Framework提供了一个新的安全方式——代码访问安全(CAS:Code Access Security),通过Stack Walk检查、Permission(/set)和Security Policy等一些措施我们可以保证不仅只有某些角色的人可以访问某些功能(也就是常说的RBS:Role Based Security),就连哪些代码可以访问何种资源也可以有效管理。
Silverlight推出后很多人更多关心的是它绚丽的UI效果和通过一个小小的CoreCLR就可以在多个平台运行的能力,但当我们尝试套用以往CAS的办法定义访问安全性的时候却发现无从下手,原因在于SL采用了所谓的“透明安全模型”(transparency model),它将代码分成两种:transparent Code和critical Code。前者是SL开发人员编写的应用代码,在用户态执行,执行主体是当前这个用户,而执行的访问控制设置为不受限;后者是CoreCLR在核心态执行的,它需要和具体的操作系统交互,完成例如文件访问、显卡调用等工作。在CoreCLR中两个代码可能保存在同一个Assembly中,但一个方法内部只能有唯一一类代码,而且transparent Code不能直接访问critical Code。
因此,在SL开发中,我们能编写的代码只能是满足下述transparent Code要求的内容:
隐式满足LinkDemand,即整个调用栈的所有代码都必须是transparent Code;
不需执行CAS的断言(Assert);
全部代码都是可验证的;
不可以通过Native Call或P/Invoke调用本地资源,一方面为了安全,另一方面因为不同平台的本地调用方式不同;
不可以直接访问critical code。
这样您可能觉得SL开发限制很大,比如建立一个文件这种操作在应用中非常普遍,为了实现这个目的,CoreCLR提供了一个中间过渡——IsolatedStorage。某种意义上讲,它是SL开发人员所能看到的逻辑运行平台,无论是文件、设备还是进程之类的信息都只能通过这个中间机制访问,而严格的检查也会“透明”的在这个中间机制完成。这么做有什么益处呢?很多。因为这一层把很多Best Practice强制实施了,例如:
打开一个文件的时候,文件名称是否有效,是否存在潜在的缓冲区溢出等危险,当前用户是否可以执行这个文件打开操作等;
访问一个URL的时候,这个URL是否会Traverse up,是否可以遍历到高层目录。
总体上通过IsolatedStorage,把很多已知的代码安全访问检查全部在CoreCLR平台一级内置了,开发人员可以通过这种“与生俱来”的安全性相对放心地开发自己的上层应用。
在
Silverlight发布时,
微软宣称它将是一个完全跨平台、跨浏览器的下一代富客户端
开发技术工具。但在使用绚丽功能的同时,很多人会思考Silverlight是否能够一如既往地实现不同平台间托管代码执行的安全性?答案是“除了安全,您没有别的选择”。
在Silverlight发布时,微软宣称它将是一个完全跨平台、跨浏览器的下一代富客户端开发技术工具。但在使用绚丽功能的同时,很多人会思考Silverlight是否能够一如既往地实现不同平台间托管代码执行的安全性?答案是“除了安全,您没有别的选择”。
.NET Framework提供了一个新的安全方式——代码访问安全(CAS:Code Access Security),通过Stack Walk检查、Permission(/set)和Security Policy等一些措施我们可以保证不仅只有某些角色的人可以访问某些功能(也就是常说的RBS:Role Based Security),就连哪些代码可以访问何种资源也可以有效管理。
Silverlight推出后很多人更多关心的是它绚丽的UI效果和通过一个小小的CoreCLR就可以在多个平台运行的能力,但当我们尝试套用以往CAS的办法定义访问安全性的时候却发现无从下手,原因在于SL采用了所谓的“透明安全模型”(transparency model),它将代码分成两种:transparent Code和critical Code。前者是SL开发人员编写的应用代码,在用户态执行,执行主体是当前这个用户,而执行的访问控制设置为不受限;后者是CoreCLR在核心态执行的,它需要和具体的操作系统交互,完成例如文件访问、显卡调用等工作。在CoreCLR中两个代码可能保存在同一个Assembly中,但一个方法内部只能有唯一一类代码,而且transparent Code不能直接访问critical Code。
因此,在SL开发中,我们能编写的代码只能是满足下述transparent Code要求的内容:
隐式满足LinkDemand,即整个调用栈的所有代码都必须是transparent Code;
不需执行CAS的断言(Assert);
全部代码都是可验证的;
不可以通过Native Call或P/Invoke调用本地资源,一方面为了安全,另一方面因为不同平台的本地调用方式不同;
不可以直接访问critical code。
这样您可能觉得SL开发限制很大,比如建立一个文件这种操作在应用中非常普遍,为了实现这个目的,CoreCLR提供了一个中间过渡——IsolatedStorage。某种意义上讲,它是SL开发人员所能看到的逻辑运行平台,无论是文件、设备还是进程之类的信息都只能通过这个中间机制访问,而严格的检查也会“透明”的在这个中间机制完成。这么做有什么益处呢?很多。因为这一层把很多Best Practice强制实施了,例如:
打开一个文件的时候,文件名称是否有效,是否存在潜在的缓冲区溢出等危险,当前用户是否可以执行这个文件打开操作等;
访问一个URL的时候,这个URL是否会Traverse up,是否可以遍历到高层目录。
总体上通过IsolatedStorage,把很多已知的代码安全访问检查全部在CoreCLR平台一级内置了,开发人员可以通过这种“与生俱来”的安全性相对放心地开发自己的上层应用。
(CAS:Code Access Security),通过Stack Walk检查、Permission(/set)和Security Policy等一些措施我们可以保证不仅只有某些角色的人可以访问某些功能(也就是常说的RBS:Role Based Security),就连哪些代码可以访问何种资源也可以有效管理。
Silverlight推出后很多人更多关心的是它绚丽的UI效果和通过一个小小的CoreCLR就可以在多个平台运行的能力,但当我们尝试套用以往CAS的办法定义访问安全性的时候却发现无从下手,原因在于SL采用了所谓的“透明安全模型”(transparency model),它将代码分成两种:transparent Code和critical Code。前者是SL开发人员编写的应用代码,在用户态执行,执行主体是当前这个用户,而执行的访问控制设置为不受限;后者是CoreCLR在核心态执行的,它需要和具体的操作系统交互,完成例如文件访问、显卡调用等工作。在CoreCLR中两个代码可能保存在同一个Assembly中,但一个方法内部只能有唯一一类代码,而且transparent Code不能直接访问critical Code。
因此,在SL开发中,我们能编写的代码只能是满足下述transparent Code要求的内容:
隐式满足LinkDemand,即整个调用栈的所有代码都必须是transparent Code;
不需执行CAS的断言(Assert);
全部代码都是可验证的;
不可以通过Native Call或P/Invoke调用本地资源,一方面为了安全,另一方面因为不同平台的本地调用方式不同;
不可以直接访问critical code。
这样您可能觉得SL开发限制很大,比如建立一个文件这种操作在应用中非常普遍,为了实现这个目的,CoreCLR提供了一个中间过渡——IsolatedStorage。某种意义上讲,它是SL开发人员所能看到的逻辑运行平台,无论是文件、设备还是进程之类的信息都只能通过这个中间机制访问,而严格的检查也会“透明”的在这个中间机制完成。这么做有什么益处呢?很多。因为这一层把很多Best Practice强制实施了,例如:
打开一个文件的时候,文件名称是否有效,是否存在潜在的缓冲区溢出等危险,当前用户是否可以执行这个文件打开操作等;
访问一个URL的时候,这个URL是否会Traverse up,是否可以遍历到高层目录。
总体上通过IsolatedStorage,把很多已知的代码安全访问检查全部在CoreCLR平台一级内置了,开发人员可以通过这种“与生俱来”的安全性相对放心地开发自己的上层应用。
查看本文来源