Kind of two thought thread - one about assembly level checks, one for alternatives to CSLA needing FullTrust
Is there any particular reason why the AllowPartiallyTrustedCallers attribute couldn't be added into the Assembly file and adding the required CAS attributes at the assembly file for things like reflection so that users of CSLA can determine right away if they're going to have problems...or at minimum put the
[assembly: PermissionSet(SecurityAction.RequestMinimum, Name="FullTrust")]
into the assembly file so that when CSLA is loaded into an application a person would know right away versus a few screens in or down in a workflow when a CSLA factory method is first called.
My thought process is that CSLA doesn't truly require full trust; it requires
[assembly: ReflectionPermission(SecurityAction.RequestMinimum, Unrestricted=true)]
for sure along with a few others (such as Remoting), but I run into a lot of headaches with sys-admins who don't wan't to fully trust my application. Some are willing to fully trust CSLA itself but since it has the implicit LinkDemand because it doesn't have the AllowPartiallyTrustedCallers attribute at the assembly level...my application has to be fully trusted in order to use CSLA. So in some cases my fights with sys-admins would be less or non-existant because I would only have to fight for the rights I need versus fighting for full-trust.
Of coarse I can just add these items into the source code and do it myself; but I'm wondering if this maybe should be something that is added to the framework by default?
Comments?
To responsibly allow partially trusted callers, code must ensure that it can't be exploited to allow that caller to do malicious things by calling the framework. CSLA can make no such guarantee because it uses the BinaryFormatter and/or NetDataContractSerializer. Both of these allow a caller to inject arbitrary code that would be run under FullTrust, even though that code came from a partially trusted caller.
So I won't put that attribute into the project, because I can't guarantee your code. However, you can put that attribute into the project if you'd like - because then it is very clear that you are assuming the associated risks by your own concious choice ![Smile [:)]](/emoticons/emotion-1.gif)
This is a best practice issue. It isn’t a matter of what I
_can_ do, but rather what I _should_ do.
If an assembly uses FullTrust (which CSLA does, because the
BinaryFormatter/NDCS/private reflection/Remoting/WCF/etc all require it), and
that assembly allows partially trusted callers, then it is up to the author of
that assembly to do all the demands and asserts and more importantly ensure
that it can’t be used as an exploit.
If you implement ISerializable you (untrusted code author) get
to write the serialization and deserialization methods for your object. They run
within the context of the trusted code (BinaryFormatter/NDCS – within CSLA),
which means you get to write code that runs under FullTrust. Huge exploit
scenario.
This is why BF/NDCS are never allowed in any sandboxes and why
neither Remoting nor WCF work (or are likely to work) in Silverlight or similar
environments.
So as a responsible framework author I should not (and thus won’t)
allow partially trusted callers. Sure, I _can_ provide workarounds, but
that would be irresponsible. You can implement those workarounds for
your own use and that’s no problem – you are accepting the risks of
opening exploits, but you are writing the “untrusted” code, so
there’s really no risk to you.
Just don’t tell your sysadmins what is really going on,
because they’d freak and stop granting CSLA FullTrust J
Rocky
From: boo
[mailto:cslanet@lhotka.net]
Sent: Monday, July 09, 2007 12:32 AM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] AllowPartiallyTrustedCallers and CAS and
FullTrust
Why does the fact that it used the BinaryFormatter and/or
NetDataContractSerializer (not sure what that is...will have to Google later)
mean that it has to be FullTrust...why couldn't the assembly just have the
RequestMinimum on those permission sets? Then the calling code still has
to have some level of trust, but it's not an all or nothing approach.
Copyright (c) Marimer LLC