Re: Questions and observations about CAS and the StrongNameIdentityPermssionAttribute.
From: Nicole Calinoiu (calinoiu)
Date: 08/30/05
- Next message: Michael Marr: "Using CAPICOM and .NET to envelope email."
- Previous message: Michel Gallant: "Re: signcode vs signtool"
- In reply to: John Sheppard: "Re: Questions and observations about CAS and the StrongNameIdentityPermssionAttribute."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Tue, 30 Aug 2005 16:43:38 -0400
"John Sheppard" <John.Sheppard@newsgroups.nospam> wrote in message
news:uU6v20ZrFHA.1128@TK2MSFTNGP11.phx.gbl...
<snip>
> Secondly let me pose a question. Is this the official MS answer on
> this subject?
I don't work at Microsoft, so no. <g> I haven't seen anything directly
relevant in the "official" docs yet. The most on-point statement that I
know of from a Microsoft employee is on Eugene Bobukh's blog at
http://blogs.msdn.com/eugene_bobukh/archive/2005/05/06/415217.aspx.
> Because if it is that sucks.
I actually tend to agree (at least partially), so don't shoot the messenger.
<g>
> Not only does it suck it seems very illogical. Why have CAS then if a
> fully trusted assemblies can override your demanded criteria.
Fully trusted code can bypass CAS entirely by calling into unmanaged code
directly, so the ability to bypass any given permission isn't considered a
security hole.
> Think about this. Say I have an object library assembly whose classes I
> have decorated to demand that inheritors and or callers be signed with a
> certain strongnamekey. This works fine as long as I do not fully trust
> the implementation / calling code.
No, it works fine as long the user does not grant unrestricted permissions
to the calling code. You might want to keep in mind that CAS is meant to
prevent the user, not the developer or his code.
> My object library is protected in this scenerio. Or lets say I want to
> have multiple levels of access to my API based upon the SNK of my
> callee/inheritor. Again as long as I do not fully trust the
> calling/implementing assembly all is fine. Now regardless of what the
> object library developer wishes are on this subject I developer B want to
> use he object library so I fully trust the code calling his stuff and
> viola I can now use it. This has ramifications for not only SNIP but
> reflection and I presume FileIO as well.
Code running with an unrestricted permission grant (full trust) always
passed all demands for ReflectionPermission and FileIOPermission. The only
demands it didn't automatically pass were those for identity permissions
that corresponded to evidence it did not have. In v. 2.0, those have been
added to the pass list.
> So if I don't want somebody dynamically reflecting over my code and
> calling private methods I am just SOL.
Yup, and you always were. In addition to highly privileged code being able
to deliberately bypass permission verifications, the user could always
disable CAS entirely if he deliberately wanted to enable bypassing of your
protections.
> This is scary and from my perspective just plain wrong.
Only if you're counting on CAS to protect your code from callers that you
consider "undesirable" even if your users don't. Granted, there's plenty of
documentation out there (including quite a bit that came directly from
Microsoft or was sponsored by Microsoft) that suggests that CAS can do this.
Unfortunately, it's pretty much all wrong even with respect to version 1.x.
> So before I drive out to Redmond and ask Bill why please tell me I'm
> wrong.
>
> Again thanks for the answers but now I have to go take my blood
> preasure medication.
>
> John
>
- Next message: Michael Marr: "Using CAPICOM and .NET to envelope email."
- Previous message: Michel Gallant: "Re: signcode vs signtool"
- In reply to: John Sheppard: "Re: Questions and observations about CAS and the StrongNameIdentityPermssionAttribute."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
