Disclaimer: I have limited ASP.Net skills
I have a couple of websites which I am transferring from my current hosting onto the Mosso hosting service. When I tried transferring one of the websites, I got the error "System.Security.SecurityException: That assembly does not allow partially trusted callers.", which appears to have to do with the fact that Mosso runs on Medium Trust for ASP.Net apps, and the code in the website appears to require full-trust.
Unfortunately, I don't have access to the full source code for the app, and the original developer is not available. Is there any easy workaround to porting these websites? I tried adding in web.config but that didn't work.
I don't think asking Mosso to adjust the security level is an option, because they had refused when I asked them.
Does anybody have any ideas?
Is your assembly strong named? Does it call strong named assemblies?
You should apply the 'AllowPartiallyTrustedCallers` attribute to the Assembly. More information about this attribute is available here.
From the docs:
By default, a strong-named assembly
that does not explicitly apply this
attribute at assembly level to allow
its use by partially trusted code can
be called only by other assemblies
that are granted full trust by
security policy. This restriction is
enforced by placing a LinkDemand for
FullTrust on every public or protected
method on every publicly accessible
class in the assembly. Assemblies that
are intended to be called by partially
trusted code can declare their intent
through the use of the
AllowPartiallyTrustedCallersAttribute.
See this MSDN article for more information.
Edit:
Some information that confirms my suspicions that the APTCA attribute is a possible solution to the problem:
https://support.isqsolutions.com/article.aspx?id=10334
http://bloggingabout.net/blogs/rick/archive/2006/04/07/11929.aspx
Sorry to say but unless they allow you to set the trust level, you could have big issues. You could have a look here.
Professional ASP.NET 2.0 Security, Membership, and Role Management
Almost exactly the same thing happened to me, except the my hosting company changed their trust policy after I a number of websites running on their servers for a couple of years. In the end I had to give up and move to DiscountASP as they overrode <trust level="Full" /> in my congfig file.
Here was my original question.
ASP.NET WebPermission Security Exception
Good luck
I know this is old, but I thought I'd add something to it that might help. Mosso's change to Medium trust caused us some issues as well.
We use BlogEngine.NET and access MySQL for its backend. We had the MySQL dll in our bin directory and that was causing issues with medium trust. Once Mosso added a MySQL dll to the GAC, we were able to use it successfully.
Obviously, I don't know your particular details and what you are trying to do, but if it is related to MySQL, let me know.
Related
I must say that so far, I've probably just been darn lucky in that I've never come across the problems associated with a web site running in medium trust. I've only ever developed intranet apps or happened to have use a hosting company that runs in full trust. But the host I've been asked to use for a recent project runs at medium trust so I'm trying to get my app running this. Couple of questions - I develop on Windows XP. Can IIS on there be configured for medium trust (easier to debug) and/or is it a web.config setting? There is a wealth of information on this subject and the learning curve is steep.
Secondly, after a lot of fiddling and removing code, I think this line is causing a permissions error:
For Each FieldInfo As FieldInfo In Type.GetFields(BindingFlags.Instance Or BindingFlags.NonPublic Or BindingFlags.Public)
Can anyone clarify this is a possible candidate, esp. that NonPublic flag? This is copy & pasted code (Coding Horror highlighted the risk of this) so I've never really thought about. I assume the loop is through each field in the object both public and non-public fields - and I've read that protected fields are forbidden with reflection on medium trust.
Cheers, Rob.
Sorry, Reflection with NonPublic is equivalent to full trust.
If somehow I didn't have full trust but had NonPublic reflection, I could leverage that into changing my own code trust level (writable strings, etc).
Yes, a website on XP can be configured to run in medium trust:
In the <system.web> section add the following:
<!-- Case is important: it's Medium, not medium -->
<trust level="Medium"/>
And you're there.
What you may well find is that most hosts run their sites in a slightly elevated "Medium" trust setting, with some additional rights beyond the default - their techies should be able to tell you what differences they have if any.
If you take a look in:
C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\web_mediumtrust.config
you will see the default settings that are applied.
Reflection is one of the key things that is limited in Medium trust - from the Remarks on the GetFields page:
If the requested field is non-public and the caller does not have ReflectionPermission to reflect non-public objects outside the current assembly, this method returns a null reference (Nothing in Visual Basic).
As this has the potential to return null you should probably be checking for null before you start iterating through it, or checking that FieldInfo isn't null/nothing before using it.
I'm going to flag this as closed as nobody has answered and also it was just proving too problematic to try and re-code. The program isn't badly written but uses reflection very heavily for object mapping and to be honest, it's easier to find a hosting company that supports full trust.
I recently joined a firm and when analyzing their environment I noticed that the SharePoint web.config had the trust level set to Full. I know this is an absolutely terrible practice and was hoping the stackoverflow community could help me outline the flaws in this decision.
Oh, it appears this decision was made to allow the developers to deploy dlls to the Bin folder without creating CAS policies. Sigh.
Just want to clarify and make matters worse, we are also deploying third party code to this web application.
Todd,
The book, "Programming Microsoft ASP.Net 3.5", by Dino Espisito provides some sound reasoning for not allowing Full Trust in ASP.Net applications.
Among other reasons, Dino states that web applications exposed to the internet are "one of the most hostile environments for computer security you can imagine." And:
a publicly exposed fully trusted
application is a potential platform
for hackers to launch attacks. The
less an application is trusted, the
more secure that application happens
to be.
I'm surprised the StackOverflow community did not outline the problem with Full Trust better. I was hoping for the same thing so I didn't have to go digging through my pile of books to find the answer, lazy me.
If they're ignoring the CAS policies, it might be a tough sell to get them to dial it back, since it makes their job a little harder (or, at least, a little less forgiving). Changing security practices is always tough - like when I had to convince my boss that using the SA accounts in the SQL connection string of our web applications was a bad idea - but hang in there.
Full Trust allows the application to escalate to control of any resource on the computer. While you'd have to have a security flaw in your application to allow these, and they'll probably claim that they've prevented any escalations through astute programming, remind them that in the case that something happens, wouldn't they rather the web application didn't have control of the whole computer? I mean, just in case?
EDIT: I was a little overzealous with my language here. Full Trust would allow the application to control whatever it wants, but only if the Application Pool process has sufficient rights to do it. So if you're running as a limited user with no rights on the server except what the applicaition needs, then I suppose there's essentially no risk to "Full Trust". The reality is that the app pool owner most likely has a number of rights you wouldn't want your app to have (and in some cases, many, many more), so it's much safer to limit app security and grant additional rights needs individually to the application. Thanks for the correction, Barry.
Flaws? Many. But the most damning thing is straight out of the CAS utility:
"...it allows full access to your computer's resources such as the file system or network access, potentially operating outside the control of the security system."
That means, code granted Full Trust can execute any other piece of code (managed or otherwise) on the system, can call across the network to any machine, can do anything in the file system (including changing permissions on restricted files - even OS files).
Most web programmers would say "that's not a problem, it's just my code," which is fine.... until a security flaw crops up in their code that allows an attacker to use it to do unsavoury things. Then previously-granted Full Trust becomes quite unfortunate.
I honestly have found sharepoint to be too restrictive.
Take a look at the following page to see what can and cannot be done based on trust levels
http://msdn.microsoft.com/en-us/library/ms916855.aspx
One problem I ran into immediately was I could not use the Caching Application Block. We were using this application block instead of the ASP.NET caching because we had used an MVP pattern and may open up a win forms application.
Another problem is no reflection, this caused the About page to fail because the version number is pulled from the metadata of the assembly.
I think the best solution is to not use Sharepoint as an application host. I would only use Sharepoint as an application host if the amount of coding was so small that it didn't affect the trust level and it would be less work then setting up a new application. If you are doing some type of coding which is starting to hit the walls of the trust level, move your application into a proper ASP.NET enviroment. But that is just me, and I am biased. Maybe you should try to aim for a Medium trust level compromise.
I use full trust on my development machines.. so I can deploy to the BIN when building new code.
I trust my own code and run it in the GAC on production because creating CAS policies is a pain.
The third party thing would have me worried.. however:
Most 3rd party solutions found on the web also deploy to the GAC (assuming for the same reasons). This gives them all rights regardless of trust level.
Feels like it has more to do with if you trust the 3rd parties or not.. and do you really trust your own developers?
What would a hacker do?
The scenario where a hacker drops an evil dll in your BIN folder I don't see as very realistic.. regardless if he can do that he can also probably change the trust level.
I have a web app which queries a Lucene index and it works just fine in a W2K3 server in my network. Now I got my azure code so I wanted to test the service uploading the app. In order to do that I had to install Vista (I did it in a Virtual machine) cause the Azure SDK won't install on an XP box.
I created my Cloud Service, added the files from my app but when I run it (just F5) I get a SecurityException, when I call Lucene to query the index, saying:
The application attempted to perform
an operation not allowed by the
security policy. To grant this
application the required permission
please contact your system
administrator or change the
application's trust level in the
configuration file.
I've been googling around and the solutions I've found concern modifying the machine.config file which is something I won't be able to do "in the cloud".
Could anybody help on this?
Ok, in case somebody is facing the same issues, this is the correct answer which I got from the Azure forum:
This is because of the trust policy
for the Windows Azure CTP. The
enviroment variablies TEMP and TMP are
avaliable and set up appropiately.
However, System.IO.Path.GetTempPath
and System.IO.GetTempFile do not work
as they require unrestricted
environment permissions. I would
suggest you contact the Lucene
developers to see if they can modify
the code so it runs properly in medium
trust environments.
Thanks to Daniel C. Wang for the answer.
I also found a question regarding my same issue and how if was fixed.
Here the link: Lucene.Net fails at my host because it calls GetTempPath(). What’s the work around?
You can change trust in the web.config, unless that has been disallowed in the machine.config (which it often is in shared hosting). inside your put and see what happens.
If you are not allowed to do that, see if you can get your control GACd by talking to your provider. If that doesn't work, sorry to say but you are out of luck. Sometimes you can find workarounds that don't require full trust for a specific method, but if a third party dll requires it there is not much you can do
Haven't done this but isn't it possible to have a desktop version of the Live Operating Environment? This would seem a good start for troubleshooting.
What are the things that Medium Trust stops you from doing? For example, I've already learned that Medium Trust stops you from using System.IO.Path.GetTempPath(). What other things like that?
Here's how to learn about and resolve trust issues.
1) Search your Windows\Microsoft.NET\Framework[YOUR VERSION]\CONFIG folders for the files:
web.config (this is the root config file)
web_mediumtrust.config
web_hightrust.config
2) Change the web.config to say
<trust level="Medium" originUrl="" />
3) Try your ASP.NET app. Mine failed with a permission error.
4) Diff the web_mediumtrust.config and web_hightrust.config in a diff tool, like WinMerge.
5) Copy settings from the high to the medium one at a time and see how they affect your app. In my case, the error message referred to ConfigurationPermission, so it was easy to diagnose.
If you can pin down the precise lines in the web_mediumtrust.config file that are blocking you, then maybe you can share that with your hosting company and have a better chance of working things out.
More documentation here:
http://msdn.microsoft.com/en-us/library/aa302425.aspx
#Oli, my app IS hosted at GoDaddy and I had to do some workarounds in code when I started using Lucene.NET. I had to modify the Lucene.NET source code to not use GetTempPath and System.IO.FileInfo.
Who can be sure? That's why you should develop with a trust level of medium set in your web.config.
<trust level="Full|High|Medium|Low|Minimal" />
Most shared hosts don't use a true medium trust environment because it restricts some things that are just too vital. Others restrict some extra settings for their own anal reasons.
The best thing you can do is ask your host what settings they use for ASPNET. Ask for the specs of the trust level they're using. Find out the memory limits. Once you've got those details you should be able to replicate the scenario at a local level.
If they won't tell you, just set your app to run in medium trust but it (obviously) won't necessarily work if they're using a modified trust level.
Here is some information on setting trust levels in IIS.
In general the only issue I've run into is: If you're pushing assemblies, make sure you allow partially trusted requests (it's an Assembly meta-tag) otherwise you won't be able to use them.
Here's an extract of GoDaddy's Medium Trust information page:
Applications operating under a Medium
trust level have no registry access,
no access to the Windows event log,
and cannot use ReflectionPermission
(but can use Reflection). Such
applications can communicate only with
a defined range of network addresses
and file system access is limited to
the application's virtual directory
hierarchy.
Using a Medium trust level prevents
applications from accessing shared
system resources and eliminates the
potential for application
interference. Adding OleDbPermission
and OdbcPermission allows applications
to use those data providers to access
databases. WebPermission is modified
to allow outbound http and https
traffic.
That might not map exactly to what you'll have to work around with your host (unless you're with GoDaddy) but it's a typical example.
Make sure any third party libraries/frameworks (Castle comes to mind) are build (or can be built) in medium trust.
The system.runtime.serialization library is completely unavailable in medium trust.
I coded around this for json serialization/deserialization and found out the hard way. It took a week to get an associate to confirm that medium trust restrictions were to blame. I ended up switching hosting companies as a result.
In medium trust, at least at my host, P/INVOKE calls are unavailable, ie using [DLLImport] to call a COM component is not going to work.
-Edoode
I'm currently buying webhosting on a shared server with uses IIS6 and ASP.NET2.0 (They advertise 3.5 but investigation on my part has proven this to be false).
I did some legwork to make my 3.5-sensitive ASP.NET apps compile on my hosting then discovered another problem: My apps are failing at 'File.Open()' calls due to no FileIOPermissions.
I've called Technical Support and they've advised me this permission is only available if I configure IIS6 to use .NET 1.1 only. Am I out of line by thinking this is just not good enough?
This is something that should have been nutted out before starting to pay them, unless this disk access is a new requirement.
I can see it from their point of view. Every extra bit of power your apps have gives you more ability to shoot yourself (and more importantly, them) in the foot.
But I don't know why they'd allow it for an earlier .NET version, that seems bizarre.
I would make it clear that this is a deal-breaker. They might recapitulate, or you may have to move elsewhere. Either way, your problem will be solved.