I'm starting to agree with this recommendation (wish I had known about it a long time ago):

<<<

It is an annoying process to add security after the fact, the best
recommendation I've seen is to develop as a least permission user (VS
Debugger user etc) or to remove all default permissions with [assembly:
PermissionSet(SecurityAction.RequestOptional, Unrestricted=false)] up
front.
As you add functionality and it throws security exceptions run you can
research what permissions each object needs.

>>>

Src: http://www.secnewsgroups.net/group/microsoft.public.dotnet.security/topic11068.aspx

I'm starting to agree with this recommendation (wish I had known about it a long time ago):

<<<

It is an annoying process to add security after the fact, the best
recommendation I've seen is to develop as a least permission user (VS
Debugger user etc) or to remove all default permissions with [assembly:
PermissionSet(SecurityAction.RequestOptional, Unrestricted=false)] up
front.
As you add functionality and it throws security exceptions run you can
research what permissions each object needs.

>>>

Src: http://www.secnewsgroups.net/group/microsoft.public.dotnet.security/topic11068.aspx

Breaking .NET code:
http://www.atrevido.net/blog/PermaLink.aspx?guid=8315fa01-0286-47ce-a20b-fcc15eb297c3
and
Breaking a strong name:
http://www.atrevido.net/blog/PermaLink.aspx?guid=f772c18a-f389-4c28-bd6a-a30f4ccc84f5

A buried fact is how to manage IsolatedStorage -- you don't see it mentioned too often.

Just use the StoreAdm command line tool, which provides a couple of ways to cleanup after a person.

You'll probably find the *.exe here:

C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\StoreAdm.exe

or

c:\program files\microsoft visual studio 8\sdk\v2.0\bin\storeadm.exe

This is more of a reminder to myself than anything else, but I'm *always* looking high and low for this in the wrong place (I keep on reaching for System.IO.Directory when in fact its under System.Environment):

Environment.GetFolderPath(
    System.Environment.SpecialFolder.CommonApplicationData);

Environment.GetFolderPath(
    System.Environment.SpecialFolder.ApplicationData);

etc.

Damn!

AssemblyName x = thisAssembly.GetName();

triggers:

Request for the permission of type 
'System.Security.Permissions.FileIOPermission, ...etc'
 failed.

This is going to be fun, trying to get the assembly version without that error (eg: on Silverlight)...

Any ideas?

I've been toying with the blasphemous idea of Linux for a while.

Firstly, because my brother R. once in a while gets on his crate and extols its virtues (or mostly the virtues of him tinkering with it and never getting any drivers to work, but at least it amuses him on the weekend), and so does Olivier B., Tranx, and now Ollie E...

I still haven't really investigated it, mostly because I don't have the time I I would want to do it justice. I like knowing things well -- not crappily. Its certainly not because I am especially attached to Windows (I've been using computers since at least 2 OS's (CP/M, MS-DOS) before Windows 3.0 ever came out (yes, Ollie :-) )

Sec Read More »

Basic File operations on the .NET platform are really easy, once you get past the one or two strangely chosen class names.

This is a post demonstrating various ways of getting the job done, depending on how much control you need.

I was just writing up in another post about the System.IO.File in terms of streams, when I realized that this section could come in handy, as a quick reference, in the future, and deserved its own post.

It just lists, succinctly, the most common static methods used to open, read, write files, with information as to the returned variable, Encoding used, and whether an err if will be thrown if the file is not found...

(But do click the image...)

PS: When you get there, notice the disabled embed link to the right.... Cute :-)

Brilliant :-)

http://youtube.com/watch?v=adc3MSS5Ydc&feature=related

AppDomains allow you to save memory by unloading assemblies that are no longer being needed, and therefore lead themselves to being a good foundation for a plugin architecture.

But to communicate across boundaries, you need your classes to be MBR (MarshallableByRef)

"At this year’s TechEd conference, Juval Löwy was interviewed on the principle of interface-based programming vs coding to abstract classes.  Not many .NET developers know the difference between an interface and an abstract class, and even less when and why to prefer one to the other (hhmmm…sounds to me like a good post to write soon).  If you didn’t get a chance to hear his full talk on the subject at Tech Ed 2008, I strongly suggest to invest 16 minutes today to watch this interview."

Src: Brian Di Croce

Links:

http://blog.briandicroce.com/2008/06/21/juval-lwy-on-the-importance-of-interface-based-programming-teched-2008/

"Krzysztof Cwalina has published a condensed version of the Microsoft .NET Framework Design Guidelines which he co-authored with Brad Abrams a couple of years ago.

You can find the Framework Design Guidelines Digest  here as a PDF file (9 pages long).

The document is very useful if you desire to set up a standard, practical and ubiquitous approach of programming with .NET in your own organization in no time and without much effort (the job is already done for you!)."

Links:

• http://blog.briandicroce.com/2008/04/09/a-cheat-sheet-on-net-framework-design-guidelines/
• Framework Design Guidelines Digest

In all cases, a Permission (ie, a class that descends from System.Security.CodeAccessPermission) has at least two modes: Unrestricted, or Restricted.

An example of such a simple Permission would be the DnsPermission (which only has two states: Unrestricted, or Restricted).

But most of the of the Permissions, if they are not in the Unrestricted mode, work with Enums instead:

In one compact sentence:

"CAS is the .NET system of granting the intersection of 4 built in Security Policies' union of Permission Sets associated to Assemblies that match a Code Group's Evidence filter."

Here's what the above actually means...

While looking for other stuff, I just came across a post from a while back...Still mostly relevant for CF code to find the Entry point of the application, working around the missing methods, and at the same time, picking up other properties (Trademark, Copyright, etc.)

Let me know if you find it useful...

Just parking a link for later reading: http://www.grimes.demon.co.uk/workshops/fusWSEleven.htm#Fusion_and_CF

Parking the Link: http://www.ddj.com/security/206902613

When you P/Invoke API calls, its recommended to dedicate an (optionally nested) class just for the API calls --  for example:

public static
         
          Read More »
          
        
  
        

          

          	
            Comments (0)
            
          
          
          

            
            
            
            .NET:CAS
             
 
        
      

I've just come across a nice chance to the CAS security model: FullTrust is now allowed on the Intranet...under certain conditions.

The quick summary is that as of .NET 3.5 SP1, applications run from a network share will receive a grant set of FullTrust by default, making them act the same as if they were launched off of your computer directly.  Since this is an issue that I know a lot of people run into, I hope that this change makes it easier to use and deploy managed applications.  For people who want to keep their machines working the same as they did for previous .NET Framework releases, you can set the DWORD registry value LegacyMyComputerZone to 1 in the HKLM\Software\Microsoft\.NETFramework registry key.

If that looks promising to you, there's more on the subject at the .NET Security Blog.

Links:

• http://blogs.msdn.com/shawnfa/
• FullTrust on the LocalIntranet