Full Trust level: should be a concern?

Question

Should I worry about the safety of my application if it runs in Full Trust level?

If yes, why? What damages could be done?

If the trust level should be a concern why it is the default level for asp.net applications instead of medium?

I know all the yes and no's between medium and full trust levels, but I can't see where this could be a serious risk to the application and server.

Considering this:

My ISP wants to (and will) change the trust level to Medium of an IIS asp.net mvc application running on a dedicated server. This simply will break my application, since it relies heavily on System.Reflection namespace and it uses 3rd party assemblies which don't have the AllowPartiallyTrustedCallers defined.

The application runs under a specific user that has read only access to the application directory and only execute permission on stored procedures on the Sql Server. The authentication is via SSPI, so no passwords on web.config.

The ISP claims that if they let my application run in full trust they can not guarantee the security of my server. I never heard about a single case when the full trust was the cause to a security break. It seems to me that they are not sure about what they are doing.

I can't see a security flaw here. The only securiy flaw I can see in general is the password stealing from the web.config, but this is not possible in my current setup...

Answer 1

Running in full trust is typically only a problem when you allow your application to run code that is written out of your control. For instance, when you download code from the internet, you like to sandbox this and this is what partial trust is for. For your ISP, they don't know your code and like to be able to sandbox it, since they have no idea what sorts of crazy things you are doing, or allowing others to do. For instance, your application might do on-the-fly compilation of C# code (pulled from the database) and run that. When a hacker is able to (SQL) inject this C# code in your database, he would be able to do absolutely anything within with in that process (which is quite a lot).

But I've got one question for you:

Do you trust your 3rd party components?

You like to run in full trust. Why? What code did you write needs full trust? Or is it the 3rd party components that need full trust? Why do they need full trust? Perhaps you are using a 3rd party component that is able to convert Word documents to PDF or the other way around and it need full trust. That sounds quite scary to me, since a hacker might be able to inject a malformed document that triggers a buffer overrun exception, which might be possible when the component uses unsafe code (which needs full trust). In that scenario, I would rather not use such a component, since it could be a serious threat to your application. Or you should sandbox that component to be run in partial trust in a different AppDomain.

The best advice I can give you is to do thread modeling. Look closely at the boundaries of your system. What are the inputs. What are the outputs. What are the risks. This is essential information to know how to mitigate the risk.

Answer 2

Always grant only the privileges you really need.

Let's say you work in a company. Your work is limited to the room A and B and you might, sometimes, go to the room E. If you're given the access to the room C, D and F, it means that if something wrong happens in those rooms, you will be among the suspects. To limit the risks for the company and, at the same time, make it safer for you to work there, you will be given only the accesses you actually need or might need, but only those.

Source code is the same thing. When everything has full access and something wrong happens, you have no idea what happened. If, on the other hand, the protected file was altered while the file can be changed only by two people in the company and by a specific application, you know that either one of those people did something wrong, or their accounts were hacked, or the specific application was hacked. It becomes much easier to find the root cause of the issue and to be very reactive face to a security threat.

There are other reasons to use partial trust:

• The code you write may differ from what you've meant. Imagine that you're creating a tool which will sync the files in some mission-critical directories every ten minutes from the machine A to the backup machine B. You finish the n^th version of the app late in the evening and you mistakenly ask the tool to remove the source files from the machine A. You also make a few mistakes so that it doesn't copy the files from A to B. If you work in a partial trust where your application cannot remove any file from anywhere, never, it will just gracefully fail. Instead, in full trust, it will do the harm, then tell that it succeeded, letting you discover the consequences days later.

• You may use third party components that you don't always trust or can't verify. Steven already discussed this point.

• Partial trust applications can be executed in the context where the user, executing the application, has a partial trust too. It applies to the ordinary users, as well as IIS, daemons (Windows Services), etc. If you write your app for partial trust, you are aware of the pitfalls. If your application is intended to run in full trust and is started by a user who has a very limited set of permissions, what will happen?

• Working in partial trust forces you to learn things you don't usually use in full trust context. For example, what about IsolatedStorage? The advantages of isolated storage are not limited to the partial trust context (abstracting the way the information is stored; being sure that other non-malware applications will never access or overwrite the information you put there, etc.), but the feature is often ignored by people who work in full trust.

• Some contexts force you to use partial trust. Silverlight is an example.

• If your full-trust code accepts plugins, it is a security threat. Unless you specifically determine the permissions granted to the plugins code which runs in the sandbox (which has some issues too; for example, it's not obvious for the sandboxed plugins to change the UI, as well as you may encounter some issues when using cache), the code of the plugins run with the same privileges as your application. Given that those plugins can be written by a third party and contain harmful code, the user will blame your app and not the plugin from doing the harm.