1 / 19

.NET Security and MSIL

.NET Security and MSIL. Tom Roeder CS215 2006fa. MSIL. Common intermediate language really CIL in ECMA standard MSIL is common name Very close to C# (and other OO languages) define classes define methods similar attributes statements look more like assembly. MSIL.

MikeCarlo
Download Presentation

.NET Security and MSIL

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. .NET Security and MSIL Tom Roeder CS215 2006fa

  2. MSIL • Common intermediate language • really CIL in ECMA standard • MSIL is common name • Very close to C# (and other OO languages) • define classes • define methods • similar attributes • statements look more like assembly

  3. MSIL • No structured control flow • use conditional/unconditional branches • Specify calls exactly • need to have the right number of parameters • eg [mscorlib]System.Console::WriteLine(string, object, object) • Stack language • main operations push and pop from stack • call methods in other objects from stack

  4. Stack langauge • Instead of registers, everything is from stack • egint i = 137; int j = 1;int k = i + j; • all operations take their operands from the stack • common intermediate language • like JVM bytecode • very close to the high-level language 137 1 138 137

  5. MSIL • why a stack language? • consistent for all machines • limited but possible everywhere • stack construct easy to check • Always implemented by JIT • stack construct mostly in theory • slower to interpret

  6. MSIL operations • stloc <index> • pops and stores in local index (16 bits) • some assemblers handle variable names • ldloc <index> • pushes contents of local index onto stack • integer operations • eg. add, mul, sub, div • box/unbox • conv.*

  7. MSIL operations • call • static • instance • uses the static type of the class • callvirt • uses dynamic instead of static typing • castclass • pop, try to cast, push new reference on stack

  8. MSIL operations • ceq/cgt/clt • pop top two elements of stack • check =, >, < • push 1 if true, 0 if false • br/beq/bgt/blt/bfalse/btrue • do the comparison and jump • br is an unconditional jump • use to implement structured control flow

  9. MSIL structure • .method • define methods • .class • define any type • extends • extend some other type • if extend System.ValueType, then value type, and sealed • .entrypoint

  10. MSIL structure • .locals • define names and types for local variables • useful if writing straight MSIL • .maxstack • say how large the stack will be at most • must push onto stack for method calls • must remember to push object being called • one reason compilers are useful

  11. MSIL example • Can generate from arbitrary C# • use ILDASM • can be found in Visual Studio • [ see example in emacs and Visual Studio ]

  12. Brief Security Intro • Lampson’s Gold Standard (Au) • Authentication: who’s who • Authorization: who can do what • Audit: who did what • Need mechanisms for all three • need good support libraries • eg. built-in crypto • C# security based on Windows security

  13. .NET Security: authentication • Windows security based on principals • a user is a principal • accounts can be principals (eg. LOCAL SYSTEM) • users are members of groups • these groups act as roles • system policy specifies rights for different roles • this is the authorization • a given principal is assigned the ownership of a program: its rights come from this principal • What is wrong with this model?

  14. .NET Security: authentication • Evidence-based security • called “code access security” • evidence is taken from many properties of code • url, signature, site, etc • system policy can assign different rights • thus authorization is based on this policy • can specify access rights to classes/resources • When would this be useful? • Somewhat coarse-grained • must be specified in the system • defaults based on code group

  15. Code Access Security • Can assign permissions to groups of code • grouping made explicitly • or on evidence • Code can request permissions • Declaratively (using attributes) • happens at compile time (JIT compilation) • Imperatively (using calls to subclass of CodeAccessPermission) • happens at runtime • When would you want to use each?

  16. Code Access Security • Can also request permissions for assembly • RequestMinimum • RequestOptional • RequestRefuse • What happens on requests • stack walk • if any caller in stack doesn’t have permission, then Security exception is thrown • default deny

  17. Code Access Security

  18. Code Access Security • Asserting permissions • allows a method to assert that all higher code already has the permission • can short-circuit stack walk • must have permission to make this assertion • Is there an attack here? • Can lead to luring attacks • get trusted code to use assert • then get it to call malicious code

  19. .NET Security: cryptography • Provided in System.Security.Cryptography • Provides implementations of all major crypto • eg. • RSA • (Triple)DES • hashes: SHA-1, MD5 • AES • Managed and unmanaged implementations • why does this matter?

More Related