Moonlight/SecurityStatus

This page list the security related features of Moonlight. Another page list the validations needed to ensure both the Moonlight and Mono security features are working.

Note: Simply search for TODO or partial on this page to see the current restrictions.

Table of contents 1 CoreCLR Security Model 2 Plugin Sandbox 2.1 AllowHtmlPopupWindow 2.2 EnableHtmlAccess 2.3 ExternalCallersFromCrossDomain 2.4 Out Of Browser 2.5 Elevated Trust 2.6 Additional documentation 3 Networking 3.1 Uri 3.1.1 Deep Linking 3.2 Web 3.2.1 Managed 3.2.2 JavaScript 3.2.3 Client Http Stack 3.2.4 Http Stack Registration 3.2.5 Others 3.2.6 Security Zones 3.3 Sockets 3.3.1 UDP Multicast 3.3.2 Tools 3.4 XmlXapResolver 4 Local I/O 4.1 Isolated Storage 4.1.1 Quota 4.1.2 Classes 4.1.3 Additional documentation 4.2 OpenFileDialog 4.3 SaveFileDialog 4.4 Local Messaging 5 Digital Rights Management 6 Others 6.1 Regular Expressions 6.2 User Initiated Events 6.3 Assembly Loading 6.4 Shader Effects 6.5 Surface reduction 6.5.1 Mono 6.5.2 Base Class Library (BCL)

CoreCLR Security Model

• mono
  • most logic resides inside security-core-clr.c
  • tests are located in coreclr-security.cs
  • status: complete
• moonlight
  • most logic resides inside security.c, including:
    • mono initialization of coreclr and the verifier
    • callback to determine which assemblies are “platform code”
  • status: complete
• unit tests
  • location: /moon/test/2.0/moon-unit/security/*.cs
  • status: more needed, in particular for SRE
• attributes (class libraries)
  • Added during the tuning process
  • Based on the output of tools located inside moon/class/tuning/SecurityAttributes/
  • status: active
• Documentation
  • CoreCLR security model
  • Moonlight Implementation Details

Plugin Sandbox

AllowHtmlPopupWindow

• Plugin property (setter)
• Managed property (getter)
• status: complete (ML 2.1+ and ML 3.0 preview 2+)

EnableHtmlAccess

Control access from Silverlight managed code to JavaScript and the DOM.

• Default value is:
  • True for same-domain applications; and
  • False for cross-domain applications.
• Plugin property (setter)
• Managed property (getter)
• status: complete
  • works for same-domain applications
  • undocumented HTML and XAP served on different ports is not cross (or even same) domain. It does not show anything on SL2 (and makes a very bad test case)
• test application available here

ExternalCallersFromCrossDomain

Control access from JavaScript and the DOM into Silverlight managed code.

• Documentation
  • ExternalCallersFromCrossDomain
• status: complete

Out Of Browser

Silverlight 3 feature

• status: TODO

Elevated Trust

Silverlight 4 feature

• status: TODO

Additional documentation

• Security Settings in HTML Bridge (MSDN)

Networking

• Cross-domain access is possible. Rules vary by content type and how they accessed.
• Documentation
  • HTTP Communication and Security with Silverlight
  • Network Security Access Restrictions in Silverlight 2

Uri

Silverlight System.Uri is not 100% identical to the one provided by the desktop framework. This affects a number of classes that are using URI.

• Unit tests
• Silverlight 2: Demystifying URI references for app resources

Deep Linking

Silverlight 3 feature

• Status: TODO

Web

There are multiple ways to retrieve data from the web.

Managed

WebClient Class

• Relative URI are combined with the BaseAddress;
• BaseAddress defaults to the application XAP absolute URI;

WebRequest Class

• Relative URI are not allowed;
• Supports http and https using the web browser. This cannot be overridden by registering the http[s] prefixes;
• RegisterPrefix works, so custom protocols are, within SL limits, possible;
• Cookies are disabled by default

Cross-domain access is possible using policy files. Either a clientaccesspolicy.xml (Silverlight specific syntax) or a crossdomain.xml (Flash subset syntax) can define the rules.

Status: complete

JavaScript

• Downloader (javascript)
• status: partial, works like 1.0 (no xdomain support)

Client Http Stack

• Note: Silverlight 3 feature
• Extended methods (e.g. HEAD, not just GET and POST)
• Extended status codes (not just 200 and 404)
• Cookie support
• Status: partial (mostly an extention to the browser stack at the moment)

Http Stack Registration

Since Silverlight 3 support two similar HTTP stack there are some ways to select which one you want to use in your application. The default stack is the browser stack.

• All requests per protocol, e.g. WebRequest.RegisterPrefix("http://"). This can only be done/registred once per application execution.
• For a specific domain, e.g. WebRequest.RegisterPrefix ("http://www.domain.com"). This can only be done/registred once per application execution.
• For a single object, e.g. WebRequestCreator.Create(uri)
• Status: partial

Ref: http://msdn.microsoft.com/en-us/library/dd920295%28VS.95%29.aspx

Other

There are different rules for downloading special content, by type:

• Image and MediaElement classes
• XAML source files
• Font files
• Stream media

Documentation

• URL Access Restrictions in Silverlight 2

Security Zones

Cross-zone URL are an Internet Explorer concept and is not supported by Silverlight 2 outside Windows (e.g. Mac OS X). This feature is NOT supported by Moonlight.

Sockets

• The plugin is limited to connect on TCP ports in the 4502-4534 range. The cross-domain policy can further restrict the ports that can be used;
• A cross-domain policy is always required, even when connecting back to the site of origin (unlike web requests);
• The plugin will query the host (on port 943) to get its policies and decide if a connect attempt can be made;
• Documentation
  • Socket class (managed)
  • MSDN: Working with Sockets
  • Why does Silverlight have a restricted port range for Sockets?
• Status: complete

UDP Multicast

Silverlight 4 (beta) feature

• Status: TODO

Tools

sockpol: A socket policy server source that listen to port 943 and serves socket policies. You can use it as-is or merge it into your server-based application when developing the server part of a Moonlight application using sockets.

XmlXapResolver

• Status: complete
• Documentation: MSDN
• This is the default resolver used on
  • XDocument;
  • XmlReader; and
  • XmlReaderSettings

Local I/O

Silverlight provides limited access to the local files.

Isolated Storage

In the classic framework the isolation was based on the appdomain, assembly, application and evidences. In Silverlight it is based on the site and application URL. Similar in concept but the source code is not.

• status: partial
• TODO
  • UI to manage storage (from right-click menu), including a global switch to turn IsolatedStorage on or off
  • SL3 behavior has changed (for performance reason, looking for a link…)

Quota

• The default storage quota is 1 MB and is shared for all applications on the same site.
  • Removing (deleting) a storage from the UI reset the quota to 1MB;
  • Calling IsolatedStorageFile.Remove from code does not change (i.e. reduce the quota).
• The default storage quota for out-of-browser application is raised to 25 MB (Silverlight 3) and does not shrink back (if the application is removed from the desktop)

Classes

• IsolatedStorageException (mscorlib) source, MSDN
• IsolatedStorageFile (mscorlib) source, MSDN
• IsolatedStorageFileStream (mscorlib) source, MSDN
• IsolatedStorageSettings (System.Windows) source, MSDN

Isolated Storage Additional documentation

• CLR Inside Out: Isolated Storage In Silverlight 2
• Silverlight 3: Out of the Browser, Mike Harsh @ MIX09 (beta)

OpenFileDialog

Silverlight 2 provides a Open File dialog which let the user select any file on his computer. The application can get access to its name (not the full path, just the filename) and a read-only Stream to it.

• Source: OpenFileDialog.cs
• Documentation: MSDN
• Status: complete
• Notes
  • Unit tests are mostly ignored due to required user interaction

SaveFileDialog

Silverlight 3 also provides a Save File dialog that works similarly to the OpenFileDialog (present in Silverlight 2).

• Source: SaveFileDialog.cs
• Documentation: MSDN
• Status: complete
• Notes
  • Unlike OpenFileDialog it can only be called from a user action (e.g. mouse click) otherwise a SecurityException is thrown.
  • Unit tests are mostly ignored due to required user interaction
  • The dialog warn if we’re about to replace an existing file;
  • It is possible to create a new directory from this dialog;

Local Messaging

Silverlight 3 feature

• Status: TODO

Digital Rights Management

Silverlight 2 supports Microsoft PlayReady Digital Rights Management (DRM). This is the DRM solution being used by Netflix’s “Watch Instantly” service for streaming movies to PC (Windows-only) and Mac computers.

Status: unsupported

More information:

• MSDN
• Netflix FAQ

Others

Regular Expressions

• Compiled regex are not supported by Silverlight
• Status: complete

User Initiated Events

In Silverlight some actions can only occurs if they are initiated directly by the user, e.g. a mouse click or a keyboard event. Otherwise the expected action will not occur, e.g.

• setting Content.IsFullscreen to true will be ignored;
• calling IsolatedFileStorage.IncreaseQuotaTo will return false (just like it would if the user denied the request);
• calling SaveFileDialog.ShowDialog will throw a SecurityException (Silverlight 3)
• calling HtmlPage.PopupWindow will return null unless it was done by a user-initiated event and it can only be called once per user event.

Documentation

• User-initiated operations in Silverlight

Assembly Loading

• Remove the Global Assembly Cache (GAC) from the assembly loading strategy
  • only assemblies from the “platform directory” or the XAP file should be loaded
  • status: complete
• Special handling of [InternalsVisibleTo] wrt platform code
  • make sure we are not opening our internals to assemblies in the XAP file masquerading (name and public key token) as platform code
  • see SecurityValidation for more details
  • status: complete

Shader Effects

Silverlight 3 feature

• status: TODO

Surface reduction

Why ? beside the standard less code, less vulnerabilities it is also easier and faster, in general, to remove features than to audit them (now and in the future). As a bonus Moonlight gets a smaller download size and the Mono runtime get usable in smaller embedded systems.

Mono

• Remove unneeded features (e.g. com support)
  • status: not done for Moonlight 2

Base Class Library (BCL)

• Reduce the number of (unneeded) [SecuritySafeCritical] code
  • Goal: Reduce surface and the required security audit time
  • How: Look at the lists of automatic entries added to Moonlight assemblies (*.auto.ssc files) and see what can be removed (e.g. drop or re-write small chunk of code)
  • status: DONE
• Remove unneeded code (i.e. help the linker)
  • Goal: Reduce surface and the download size of Moonlight
  • How: Help the linker, with a few well placed #if NET_2_1, drop some code that Moonlight does not require
  • status: DONE (more is possible/likely in future Moonlight releases)