個人檔案I may have joined the wr...部落格清單 工具 說明
2月17日

I'm in the platform? Little old me?

After introducing a Microsoft plan to force full trust all assemblies in the GAC, Shawn Farkas posted follow-up inviting further feeback. Included in his post are six points explaining some of the reasoning behind the change. In my opinion, none of these reasons even begins to justify the change, and I'd like to present some counter-arguments to each. I'll address each of Shawn's points in a separate post here, with the individual points and subpoints labeled for ease of discussion.

Starting with point 1...


1.a) "Assemblies in the GAC build up the managed platform that all managed applications can run on."

Not all assemblies in the GAC are meant to form part of the general .NET platform, just as not all DLLs in the Windows\System32 folder form part of the Windows platform. Microsoft lost the right to assume this the moment every Tom, Dick, and Harry were allowed to put their assemblies in the GAC.


1.b) "In order to build up a platform where any application, trusted or not, can run safely, it makes sense that you need to trust the assemblies making up that platform."

But that trust need not be blind. See my earlier post on trust decisions for why one might not want to grant full trust to even the most trustworthy assemblies.


1.c) "If you don't trust an assembly enough for any code to be able to call into it, then the best place for it is probably not the GAC"

i. On inappropriate GACing:

By and large, the decision to place any given assembly in the GAC or not is made by the folks who author and distribute applications, not the folks who run their installation packages. I might decide not to install an app once I find out that it puts assemblies in the GAC in a manner that I find unnecessary (and I'll be far more likely to make this decision if the change goes through), but I won't be adjusting someone else's app or installer to avoid putting their assemblies in the GAC.

ii. On trusting GACed assemblies:

Under v. 1.x rules, one could set policy to grant only partial trust to assemblies in the GAC, so allowing other folks' apps to put assemblies in the GAC did not necessarily cause a trust problem. The problem is introduced by eliminating the possibility to the restrict GACed assemblies to the permission one feels they actually merit.

回應 (7)

請稍候...
很抱歉,您輸入的回應過長。請縮短您的回應。
您尚未輸入內容,請再試一次。
很抱歉,目前無法新增您的回應,請稍後再試。
若要新增回應,您的父母必須先給您權限。要求權限
您的家長已關閉回應功能。
很抱歉,目前無法刪除您的回應,請稍後再試。
您已超過每日回應上限次數,請於 24 小時後再試一次。
由於系統顯示您可能傳送垃圾郵件給其他使用者,因此您帳號中的回應功能已遭停用。 如果您認為自己帳號遭錯誤停用,請連絡 Windows Live 支援
請完成下列安全檢查,以完成回應。
您輸入的安全檢查字元必須與圖片或音訊中的字元相符。
此網頁已停用回應功能。
匿名 的圖片
Nicole 撰寫:
Part V (finally, the end!):

Another issue is the ability of admins to judge whether an assembly merits GACing or not. A non-dev admin simply doesn't have the skills or experience required for this, and he shouldn't need to either. CAS should help that admin by allowing him to limit the permissions available to _any_ assembly. A reasonable way to set this up is to grant full trust only to assemblies with one of a specified set of Authenticode or strong name keys. (For evidence that I'm not the only one who likes this approach, see the first paragraph of the original problem statement at http://groups-beta.google.com/group/microsoft.public.dotnet.security/browse_thread/thread/8529c05b26be4d30?tvc=2.) This technique only offers adequate protection if no excemption is granted to assemblies in the GAC.
2 月 18 日
匿名 的圖片
Nicole 撰寫:
Part IV:

"the admin does have the ability to not install applications that they don't trust if the app requires going into the GAC."

If admins (all of them, not just the ones who get paid to be vigilant on behalf of others) truly screened the applications they installed, malware/spyware would not be nearly the problem it is today. The fact that it's a huge problem (and not just on home computers) is a pretty good indicator of how aggressive CAS protections should probably be.
2 月 18 日
匿名 的圖片
Nicole 撰寫:
Part III:

"Only local machine administrators are allowed to publish something there."

This is part of your original third point. I have a separate post on the way for that one--just needs some formatting, which I should be able to get to today...


"Getting home users to run as non-admin is a different story"

Sure is (also covered in my response to your point #3), and it's certainly not going to happen in the v. 2.0 timeframe. If the main intent of CAS is to prevent code from exploiting the full range of permissions permitted to the user, users with the most permissions should merit the best possible protection under CAS. Their broad user permissions should not be used as an excuse to reduce this protection.
2 月 18 日
匿名 的圖片
Nicole 撰寫:
Part II:

"APTCA and assembly level declarative security help with the "blind trust" problem"

How? Folks who will GAC just to gain guaranteed full trust are also likely to smack APTCA on their GACed assemblies as soon as they encounter a problem calling in from code that isn't fully trusted. This is a nightmare waiting to happen. Unfortunately, it's probably already a far too common practice amongst those who believe that GACing guarantees full trust even in v. 1.x.

As for assembly-level declarative security, do you really believe any significant proportion of devs use it to reject permissions? The Microsoft assemblies in my current machine's GAC certainly don't. The various third-party apps I have installed on the machine don't. The only ones I can find on this machine that do are the ones I authored myself.
2 月 18 日
匿名 的圖片
Nicole 撰寫:
Part I (since MSN Spaces apparently doesn't like long comment):


"anything in the GAC is callable from any managed code, including code that you do not trust, running on the Internet."

Yup. And that's one of the reasons that it can be a good idea to limit the permissions of assemblies installed in the GAC. If a GACed assembly lacks a potentially dangerous permission, it can't be coerced (or at least not nearly as easily) into exploiting that permission on behalf of an unanticipated caller.


"As soon as I put my DLL there, even if I don't intend it to be world callable, it's still loadable by any application who wants to get at it."

Unfortunately, plenty of developers put assemblies in the GAC without properly addressing this consequence. Limiting the permissions of these assemblies is one approach the user can take to protect himself against ignorant and/or lazy devs who don't properly understand the consequences of their actions.
2 月 18 日
匿名 的圖片
Shawn 撰寫:
I meant to add above ...

"every Tom, Dick, and Harry were allowed to put their assemblies in the GAC". This is one of the reasons we do trust the GAC. Only local machine administrators are allowed to publish something there. Getting home users to run as non-admin is a different story, but especially on corporate machines, most users actually cannot put files into the GAC.

-Shawn
2 月 17 日
匿名 的圖片
Shawn 撰寫:
Glad to see you started up the blog ... and that I provided plenty of fodder for you to write about :-)

About point 1a ... even though not all assemblies in the GAC may be intended to form part of the general platform, the fact is that they do because of the simple fact that anything in the GAC is callable from any managed code, including code that you do not trust, running on the Internet. The System32 point is a very valid comparison. As soon as I put my DLL there, even if I don't intend it to be world callable, it's still loadable by any application who wants to get at it. And that makes it, in effect, a part of the platform.

On 1b ... APTCA and assembly level declarative security help with the "blind trust" problem, as point 1c mentions, this is in the control of the developer, not the machine administrator. As you point out in a previous post, the admin does have the ability to not install applications that they don't trust if the app requires going into the GAC.

-Shawn
2 月 17 日

引用通告

引述這則內容的部落格