Welcome to MSDN Blogs
Sign in
|
Join
|
Help
.NET Security Blog
This Blog
Syndication
RSS 2.0
Atom 1.0
Search
Tags
CAS
ClickOnce
CLR v4
CNG
Cryptography
Debugging
Orcas
Other
Policy
SecAnnotate
Security
Silverlight
SSCLI
StrongName
Transparency
Under the Hood
Visual Studio
Windows
XML
News
Silverlight Security Cheat Sheet
What's New in Security for v2.0
List of CLR Bloggers
Getting Help with your .NET Questions
Archives
November 2009 (7)
June 2009 (4)
May 2009 (6)
March 2009 (1)
December 2008 (2)
August 2008 (1)
July 2008 (2)
May 2008 (2)
March 2008 (2)
February 2008 (1)
January 2008 (1)
October 2007 (2)
June 2007 (1)
May 2007 (5)
April 2007 (1)
March 2007 (4)
February 2007 (3)
January 2007 (5)
December 2006 (2)
November 2006 (3)
October 2006 (5)
September 2006 (2)
August 2006 (1)
July 2006 (6)
June 2006 (6)
May 2006 (7)
April 2006 (7)
March 2006 (6)
February 2006 (7)
January 2006 (9)
December 2005 (7)
November 2005 (8)
October 2005 (8)
September 2005 (11)
August 2005 (7)
July 2005 (8)
June 2005 (4)
May 2005 (10)
April 2005 (6)
March 2005 (10)
February 2005 (9)
January 2005 (10)
December 2004 (10)
November 2004 (11)
October 2004 (12)
September 2004 (10)
August 2004 (10)
July 2004 (10)
June 2004 (11)
May 2004 (7)
April 2004 (14)
March 2004 (21)
February 2004 (12)
January 2004 (3)
December 2003 (1)
November 2003 (5)
October 2003 (1)
June 2003 (2)
Browse by Tags
CAS
ClickOnce
CLR v4
CNG
Cryptography
Debugging
Orcas
Other
Policy
SecAnnotate
Security
Silverlight
SSCLI
StrongName
Transparency
Under the Hood
Visual Studio
Windows
XML
Wednesday, November 18, 2009 8:41 AM
Using SecAnnotate to Analyze Your Assemblies for Transparency Violations – An Example
SecAnnotate (available in the final .NET 4 SDK, and in beta form here ) can be used to analyze your assemblies, especially APTCA assemblies in order to find transparency violations without needing code coverage from a test case. Instead, the static analysis
Posted by
shawnfa
|
0 Comments
Filed under:
Security
,
CLR v4
,
Transparency
,
SecAnnotate
Attachment(s):
TransparencyAnnotations.xml
Wednesday, November 18, 2009 8:24 AM
SecAnnotate Beta
One of the design goals of the security transparency system in the CLR is that it should be as static as possible and not rely on dynamic state (such as the call stack) to function. A fallout of this is that we can write tools to analyze assemblies and
Posted by
shawnfa
|
0 Comments
Filed under:
Security
,
CLR v4
,
Transparency
,
SecAnnotate
Attachment(s):
SecAnnotate.msi
Thursday, November 12, 2009 12:59 PM
Differences Between the Security Rule Sets
In my last post I talked about the two different security rule sets supported by the v4 CLR . At a high level, level 1 is the v2.0 security transparency model, and level 2 encompasses the updated v4 security transparency model. Digging down
Posted by
shawnfa
|
0 Comments
Filed under:
Security
,
Silverlight
,
CLR v4
,
Transparency
Wednesday, November 11, 2009 11:24 AM
Transparency Models: A Tale of Two Levels
Earlier this week, we looked at how the v4 CLR continued the evolution of the security transparency model that started in v2 and started evolving with Silverlight in order to make it the primary security enforcement mechanism of the .NET 4 runtime. The
Posted by
shawnfa
|
0 Comments
Filed under:
Security
,
CLR v4
,
Transparency
Monday, November 09, 2009 12:23 PM
Transparency as Enforcement in CLR v4
Now that we know the basics of security transparency , let's look at how it evolved over time. In .NET v2.0, many of the transparency rules we previously looked at were in place , with the exception of some of the inheritance rules that were introduced
Posted by
shawnfa
|
0 Comments
Filed under:
Security
,
CLR v4
,
Transparency
Thursday, November 05, 2009 9:59 AM
Bridging the Gap Between Transparent and Critical Code
Last time we looked at the set of operations that can only be performed by security critical code . One interesting observation is that just because you are doing one of these operations does not mean that your method in and of itself is security sensitive.
Posted by
shawnfa
|
0 Comments
Filed under:
Security
,
CLR v4
,
Transparency
Tuesday, November 03, 2009 9:38 AM
Transparency 101: Basic Transparency Rules
One of the biggest changes in the .NET 4 security model is a move toward security transparency as a primary security enforcement mechanism of the platform. As you'll recall, we introduced security transparency in the v2 release of .NET as more of an audit
Posted by
shawnfa
|
0 Comments
Filed under:
Security
,
CLR v4
,
Transparency
Friday, June 12, 2009 11:33 AM
CLR v4 Security Policy Roundup
Over the last few weeks we’ve been taking a look at the updates to the CLR security policy system in the v4 release of the .NET Framework. Here’s a quick index of those topics: Overview Security Policy in the v4 CLR Sandboxing in .NET 4.0 Updating code
Posted by
shawnfa
|
1 Comments
Filed under:
Security
,
ClickOnce
,
CAS
,
Policy
Friday, June 12, 2009 11:27 AM
Temporarily re-enabling CAS policy during migration
Over the last few weeks we’ve been looking at the changes to security policy in .NET 4, namely that security policy is now in the hands of the host and the operating system. While we’ve looked at how to update code that implicitly uses CAS policy , loads
Posted by
shawnfa
|
3 Comments
Filed under:
Security
,
CAS
,
Policy
,
CLR v4
Tuesday, June 09, 2009 12:14 PM
Coding with Security Policy in .NET 4 part 2 – Explicit uses of CAS policy
Over the last few posts, I’ve been looking at how the update to the CLR v4 security policy interacts with how you write managed code against the v4 .NET Framework. So far we’ve looked at the implicit uses of CAS policy, such as loading assemblies
Posted by
shawnfa
|
1 Comments
Filed under:
Security
,
CAS
,
Policy
,
CLR v4
Monday, June 08, 2009 11:59 AM
More Implicit Uses of CAS Policy: loadFromRemoteSources
In my last post about changes to the CLR v4 security policy model, I looked at APIs which implicitly use CAS policy in their operation (such as Assembly.Load overloads that take an Evidence parameter), and how to migrate code that was using those APIs.
Posted by
shawnfa
|
5 Comments
Filed under:
Security
,
CAS
,
Policy
,
CLR v4
Thursday, May 28, 2009 1:30 PM
CLR 4 Security on Channel 9
A while back I did an interview with Charles Torre about the changes to security in CLR v4, and he posted it to the Channel 9 videos site yesterday. I start out talking about the security policy changes I've been covering here over the last week,
Posted by
shawnfa
|
1 Comments
Filed under:
Security
,
CAS
,
Policy
,
CLR v4
,
Transparency
Thursday, May 28, 2009 7:00 AM
Visual Studio 10 Security Tab Changes
Kris Makey, who works on the Visual Studio team, has written up a good blog post about the changes you’ll see on the security tab in Visual Studio 10 when it comes to editing permission sets . He covers what the changes are, and some of the reasons
Posted by
shawnfa
|
1 Comments
Filed under:
Security
,
CAS
,
Visual Studio
,
CLR v4
Wednesday, May 27, 2009 10:46 AM
Coding with Security Policy in .NET 4.0 – Implicit uses of CAS policy
Last week we looked at sandboxing and the v4 CLR – with the key change being that the CLR now defers exclusively to the host application when setting up sandboxed domains by moving away from the old CAS policy model, and moving instead to simple sandboxed
Posted by
shawnfa
|
4 Comments
Filed under:
Security
,
CAS
,
Policy
,
CLR v4
Friday, May 22, 2009 10:54 AM
Sandboxing in .NET 4.0
Yesterday I talked about the changes in security policy for managed applications , namely that managed applications will run with full trust - the same as native applications - when you execute them directly. That change doesn’t mean that managed code
Posted by
shawnfa
|
6 Comments
Filed under:
Security
,
CAS
,
Policy
,
CLR v4
More Posts
Next page »