|
I wondered how certain .NET hosting providers can safely grant full trust to their customers? Doesn't this open up everybody who is hosting with that company to potential safety issues? Or is there a way to safely restrict each customer, despite giving full trust, to "their" space without giving them the abiliy to bring down the system or spy on other customers?
| |||||||||||
feedback
|
This question came from our site for professional and enthusiast programmers.
|
In some ways it does, potentially, open up the possibility of problems from one application from affecting others. But, full trust is actually pretty safe by default already, especially from external attacks. The biggest risks in full trust scenarios are from the legitimate users who could, possibly, upload and run code that does something stupid. Again though, this is a minor risk in overall practice, which is why you see hosting with full trust at all. Hosting providers also do a few things besides to further reduce the effects of one errant user's idiocy. Most of the providers do make a few tweaks to the "full trust" defaults to eliminate features that asp..net solutions wouldn't actually need anyway. They also tend to run each user's account in separate app pools on the server too. Also, there were some problems with the default medium trust settings that resulted in full trust being very difficult to achieve with many asp.net applications. Microsoft has made some changes to how code access security and trust levels work in asp.net 4.0 to address these concerns. I haven't dug into the final details myself yet, but you can find a bit of information on them at these links: | |||
|
feedback
|
|
The "trust" issue of the .net framework is not related to protecting the server. At least not directly. The hosting providers are (should) protecting their servers by granting limited user rights to the hosted user. Those rights are granted in the operation system level. The VM or langauge that the user is using is not relevant. From most languages you can access the win32 api or the the posix api and do as much damage as your security permission will allow you. The scenario that the "trust" model of the .net framework is covering, is not much different than the JavaScript parser that is hosted in your browser is providing. Consider the following: You are writing some game server. And you wont to allow third parties to write extensions for you game. You will run the dll's provided by those third parties on your server. You want to allow them to call your api. but you certenlly don't want to allow them to sniff your disk or database directly. In that case the OS security won't help you because those dll run in your process with your credential. So you load those dll's in restiricted trust. And the .net framework will make sure they are not calling any dangerous api. | |||
|
feedback
|
