Mark Assemblies with Allow Partially Trusted Callers by Default

[William C. Pierce]

http://support.castleproject.org/projects/CASTLE/issues/view/CASTLE-ISSUE-48

[William C. Pierce]

Calling all Super Readers...Calling all Super Readers...

On Wed, Sep 24, 2008 at 8:47 AM, William C. Pierce <wcpi...@gmail.com> wrote:

http://support.castleproject.org/projects/CASTLE/issues/view/CASTLE-ISSUE-48

[Roelof Blom]

I think the same questions were asked on the Rhino Tools list: what's the rationale and what are the implications?

-- Roelof.

[hammett]

From MSDN

"Allows strong-named assemblies to be called by partially trusted
code. Without this declaration, only fully trusted callers are able to
use such assemblies"

AllowPartiallyTrustedCallersAttribute is only effective when applied
by a strong-named assembly at the assembly level. For more information
about applying attributes at the assembly level, see Applying
Attributes.

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.
The attribute is declared at the assembly level. An example of the
declaration in C# is [assembly:AllowPartiallyTrustedCallers] and in
Visual Basic is <assembly:AllowPartiallyTrustedCallers>.

Caution:
The presence of this assembly-level attribute prevents the default
behavior of placing FullTrust LinkDemand security checks, making the
assembly callable from any other assembly (partially or fully
trusted).
When this attribute is present, all other security checks function as
intended, including any class-level or method-level declarative
security attributes that are present. This attribute blocks only the
implicit fully trusted caller demand.

This is not a declarative security attribute, but a regular attribute
(it derives from Attribute, not SecurityAttribute).

--
Cheers,
hammett
http://hammett.castleproject.org/

[Roelof Blom]

Here's some more info about APTC
- 'The only time you should ever add the AllowPartiallyTrustedCallers attribute to your assembly is after a careful security audit' http://msdn.microsoft.com/msdnmag/issues/03/08/SecurityBriefs/
- http://www.guidanceshare.com/wiki/ASP.NET_2.0_Security_Inspection_Questions_-_Code_Access_Security

Personally I think it's not a a problem enabling it.

-- Roelof.

[James Kovacs]

If you apply this attribute, the assumption is that you've done a full security audit of your codebase looking for security vulnerabilities. You're basically telling the CLR, "Trust me, I know what I'm doing." I am not aware that such an audit has been done of the Castle bits. I personally wouldn't recommend applying APTC without someone knowledgeable in framework security performing an audit. But that's just me...

James
--
James Kovacs, B.Sc., M.Sc., MCSD, MCT
Microsoft MVP - C# Architecture
http://www.jameskovacs.com
jko...@post.harvard.edu
403-397-3177 (mobile)

[William C. Pierce]

My only rationale is to enable the use of the stack in Medium Trust environments.

[josh robb]

On Sat, Oct 4, 2008 at 6:20 AM, William C. Pierce <wcpi...@gmail.com> wrote:
> My only rationale is to enable the use of the stack in Medium Trust
> environments.

Isn't there a build option to do this if you need to? (checks..) Yes -
there is:

> nant -D:assembly.allow-partially-trusted-callers=true

The assumption is that - this is something you can do for yourself if
required - but we don't think this is a good default.

Why does this not meet your requirement?

[William C. Pierce]

I can do my own build and that would meet my needs but I'm challenging the idea that it isn't a good default.  The problem is I now have to do a private build of Castle and any other project I use that has Castle dependencies.  Anyone who wants to use Castle in Medium Trust will also have to do their own build every time they upgrade.

[Roelof Blom]

I agree with Josh it's not a good default, but only at present time because I also agree with William that it's cumbersome doing your own builds, only because you're operating in Medium Trust.

Like James wrote there's an assumption that a security audit has been done on the code with this attribute, so we need someone with good knowledge of code security issues to perform an audit and then we could enable the attribute by default.

So, who's knowledgable about secure code and System.Security.Permissions, and is wiling to perform such an audit?

-- Roelof.

[josh robb]

On Sun, Oct 5, 2008 at 8:52 PM, Roelof Blom <roelo...@gmail.com> wrote:
> So, who's knowledgable about secure code and System.Security.Permissions,
> and is wiling to perform such an audit?

This is why this isn't the default.

This is a (seriously) non-trivial amount of work. It's about as much
fun as writing documentation - and it needs to apply not only to the
existing codebase (100,000's of lines) but also to every SVN commit
from here on. Here's what's required:

1. Make sure that every item on this list is checked off. -
http://msdn.microsoft.com/en-us/library/aa302339.aspx
2. Read this: http://msdn.microsoft.com/en-us/library/aa720569.aspx -
and then ensure that every piece of code in each library meets these
standards.

Just changing the default built setting is basically saying - "We (the
castle project/PMC) think this is ok/secure." - and we don't.

I would _happily_ accept a patch which did the above - or even made a
start - but changing the default without doing the work is crazy.

I realise that it's inconvenient to have to do private builds - but
that inconvenience is a deliberate choice. It's there so that you have
to think this through and make a risk assessment for oneself.

j.

[Alex Henderson]

If the issue is private builds, is this perhaps just something that could be added to the build server - so a partially trusted callers build was done on a nightly basis, or just as a separate project on the CI server (using the cc.net queues you could just set the two to build one after the other to avoid clogging up the build server).

Cheers,

 - Alex

[Jonathon Rossi]

That still comes back to what Josh stated. If you published binaries build this way, then some people are going to make the assumption that Castle supports both and not even consider what it really means other than getting their web app running on medium trust.

--
Jonathon Rossi

[josh robb]

On Mon, Oct 6, 2008 at 6:54 PM, Jonathon Rossi <jo...@jonorossi.com> wrote:
> That still comes back to what Josh stated. If you published binaries build
> this way, then some people are going to make the assumption that Castle
> supports both and not even consider what it really means other than getting
> their web app running on medium trust.

Exactly. It makes no difference wether it's the default or not - if we
publish assemblies it's the same result.

As I said previously - this is meant to be a little bit difficult!
(svn up && build - isn't that difficult IMO).... but the burden of
responsibility rests on the individual who performs the build - rather
than castle-dev getting email "My server got HAX0RED". (Unlikely - but
not impossible - if you e.g. allow users to submit Brail/NH templates
or something similar).

Am I not explaining clearly the reason why we (the royal we) don't
wish to publish APTC assemblies? Help me here.

j.

[Patrick Steele]

On Mon, Oct 6, 2008 at 6:18 AM, josh robb <josh...@fastmail.fm> wrote:
>
> Am I not explaining clearly the reason why we (the royal we) don't
> wish to publish APTC assemblies? Help me here.

As an outsider (just someone that uses Castle -- not a committer/team
member), I DO NOT want the Castle team to publish pre-built APTC
assemblies at this time. As said earlier, a deep security audit of
the codebase would be required. Heck, even if I WANTED to download
pre-built assemblies with APTC, I'd want a document explaing the
detailed audit procedure that was done to make this a good idea.

I know making a private build can be tricky sometimes to get set up.
But once it's up and running it's zero maintenance -- just download
the trunk (or whatever version you want) with SVN and re-build. I
would prefer people ask for help getting Castle built than publishing
APTC assemblies. All we need is one little security leak on a visible
Castle project and Castle's credibility could be hurt.

--
Patrick Steele
http://weblogs.asp.net/psteele

[William C. Pierce]

This is an open source software project.  If someone finds a security vulnerability, and it concerns them enough, they will submit a patch. Perhaps in addition to APTC, we add some verbiage to the Castle Main Limitations urging developers not to use it to launch satellites or write an online NOC list.

Castle does not publish binaries often enough for assumptions to form :)  If it is the decision of the group not to add APTC until the process outlined by Josh is completed, then it will never be done.  Even if some kind soul were to carry out the review and subsequent patches and some other kind soul were to verify KS1's work, every committer would need to go through the provided checklist every time code was committed or patches applied.  Not gonna happen.

Was such an audit performed on Dynamic Proxy2?  Is the checklist adhered to for all commits to this project?  Why does DP2 APTC, but not Core, its dependent assembly?

[josh robb]

APTC is in essence a contract.

What I'm hearing an argument for is that we should implement a
contract without support for it.

Essentially - the argument is equivalent to: Can you please implement
this interface ITrustMeIKnowWhatImDoing and just throw NotImplemented
exceptions.

Except this is wholesale worse - because it's a silent failure of the
_entire_ trust mechanism for the .Net framework. (i.e.
ITrustMeIKnowWhatImDoing.IsAuthorized always returns true[1]).

I have no idea why DP2 is marked APTC (SVN blame might explain why) -
but an argument from existing practice is not a good one. (e.g. I've
never used source control - why do I need it now?)

If you seriously think that adding verbiage to a web page is a
solution to this problem then you haven't been paying attention.

e.g. Search the lists for "My AR instance is getting saved even though
I haven't called save and then read this:
http://castleproject.org/activerecord/index.html.

Basically - what your asking is for your support burden of maintaining
a private build (which is hardly onerous) to be exchanged for
additional support by other people on this mailing list.

I can understand why thats an attractive proposition to people who
need to build APTC - but it's not sounding like a great deal from my
seat.

j.

p.s. sorry if I seem arsey - I'm not having a great day and I'm
finding it hard to get my tone right (but I'm trying :-).

[1] Sorry for stretching this metaphor well past it's use.

[James Kovacs]

To give you an idea of the magnitude of properly applying APTC, Microsoft dropped support for running WCF in medium trust in .NET 3.0 because Microsoft did not have sufficient time to perform a security audit of their code. (Partial trust support was originally in scope for .NET 3.0, but had to be cut due to schedule constraints.) Even in .NET 3.5, WCF can run in partial trust in only limited scenarios.

http://msdn.microsoft.com/en-us/library/bb412175.aspx

Although applying APTC to an assembly is simple, the implied contract, as other have stated, is a huge undertaking. If Joe or Jane developer compiles a private build with the attribute applied, they are taking responsibility for the choice. A bigger worry, especially as Castle is more widely used, is if a bank or other financial institution uses Castle in medium trust and gets hacked due to a security vulnerability. As Josh has mentioned, it's the Castle PMC who could potentially have their necks on the line for accepting that patch. (No, I'm not a lawyer, nor do I play one on TV. I am just a layperson hypothesizing about the legal ramifications of applying APTC blindly.)

James
--
James Kovacs, B.Sc., M.Sc., MCSD, MCT
Microsoft MVP - C# Architecture
http://www.jameskovacs.com
jko...@post.harvard.edu
403-397-3177 (mobile)

[William C. Pierce]

I don't follow your example with WCF in .Net 3.0.  Both System.ServiceModel and System.Runtime.Serialization are marked with APTC.

I believe the ASL shields all PMC necks from the line.

[William C. Pierce]

I must plead some ignorance but APTC doesn't give users of my assembly a license to kill. 

If my APTC assembly is used in Medium Trust, users are still prevented from performing operations that require full trust.  The only contract I am aware of with APTC is that anyone can use my assembly, that doesn't circumvent any other restrictions of the runtime environment.

[James Kovacs]

WCF was not marked with APTC in .NET 3.0, though it was originally planned. The reason was insufficient time/resources to perform an APTC-related security audit. They performed that audit for WCF in .NET 3.5 and allowed limited scenario use of WCF in medium trust. Yes, Microsoft has marked System.ServiceModel as APTC, but WCF will only run in medium trust in certain configurations, such as using the basic HTTP binding. My point is that APTC is not something to be taken lightly.

James
--
James Kovacs, B.Sc., M.Sc., MCSD, MCT
Microsoft MVP - C# Architecture
http://www.jameskovacs.com
jko...@post.harvard.edu
403-397-3177 (mobile)

[James Kovacs]

By applying APTC, you could be allowing medium trust users to perform full trust actions... The biggest danger of APTC is luring attacks. APTC stops stack walks in CAS. You're basically saying, "Trust this assembly. I've done my security audit and I know that it can't be abused." For example, let's say you don't have permission to write to the local file system of a remote machine, but you have a APTC assembly that does. I could abuse a method in the APTC assembly such as:

public void Logger.Error(string category, string message)

If the implementation used category as the log file name in App_Data and did not properly sanitize it, I could call it like so:

logger.Error(@"..\Default.aspx", maliciousHtml);

Even though I don't have write permission, APTC stopped the stack walk and permitted the action anyway. (You would hope that you are following a defense in depth approach and that your service account - Network Service, ASPNET, or otherwise - wouldn't have NTFS permissions to write to that file and the call would fail at the file system level.)

This example required a .NET assembly, which could be a malicious plug-in, but if website content is parsed and used as API input, you could also be vulnerable to attack.

James
--
James Kovacs, B.Sc., M.Sc., MCSD, MCT
Microsoft MVP - C# Architecture
http://www.jameskovacs.com
jko...@post.harvard.edu
403-397-3177 (mobile)

[William C. Pierce]

You are making my point for me.  Just because we mark an assembly with APTC does not guarantee it will run in medium trust.  But NOT marking the assembly with APTC guarantees it will not run in medium trust.

I never automatically assume code is secure, especially open source software.  If I was concerned about security, and you told my your assembly was secure and marked with APTC, I wouldn't believe you, I would perform my own security audit to assuage my fears.  Most people probabaly are not aware of APTC, let alone assume some implied contract when that attribute is present.

[James Kovacs]

I believe you're misunderstanding APTC. Any assembly marked with APTC will run with full trust even in a medium trust environment.

James
--
James Kovacs, B.Sc., M.Sc., MCSD, MCT
Microsoft MVP - C# Architecture
http://www.jameskovacs.com
jko...@post.harvard.edu
403-397-3177 (mobile)

[William C. Pierce]

I must be misunderstanding because that statement is not correct.  Otherwise I could circumvent any shared hosting environment simply by marking my assembiles with APTC.

[James Kovacs]

Apologies for the confusion. Partial misunderstanding on my part... APTCA removes the LinkDemand, not the stack walk. So there isn't necessarily a hole in medium trust shared hosting. Often APTCA assemblies end up with full trust because they are registered in the GAC. (GACing an assembly essentially grants it full trust.) The link demand prevents partially trusted code from calling it. Applying APTCA removes the link demand. Additional details can be found on Shawn Farkas' blog.

http://blogs.msdn.com/shawnfa/archive/2005/02/04/367390.aspx

James
--
James Kovacs, B.Sc., M.Sc., MCSD, MCT
Microsoft MVP - C# Architecture
http://www.jameskovacs.com
jko...@post.harvard.edu
403-397-3177 (mobile)