Inspect Mono CAS Policy with caspol Without Changing It

You will use caspol to inspect the Code Access Security (CAS) policy levels installed by Mono, while leaving policy files unchanged. This is an inspection guide, not a recommendation to enable CAS. Allow about ten minutes if Mono is already installed. The examples use Mono 6.8.0.105 from Ubuntu's mono-devel package.

1. Confirm the installed command

Check which executable the shell will run and record the package version. These commands do not need elevated privileges:

$ command -v caspol
/usr/bin/caspol
$ dpkg-query -W -f='${Package} ${Version}\n' mono-devel
mono-devel 6.8.0.105+dfsg-3.6ubuntu2
$ caspol -h
Mono CasPol - version 6.8.0.105
Command line tool to modify Code Access Security policies.
...
Usage: caspol [options] [arguments] ...

The installed program accepts -h for its short usage message. The local caspol(1) manpage is only a stub: it identifies the program but directs you to the help switch and Mono documentation. On this installation, caspol --version is not a supported CasPol option; the version banner from -h is the useful check.

2. Inspect the default user policy

List the code groups in the user policy level:

$ caspol -user -listgroups
Security: False
Execution check: False
Policy changes confirmation: True

Level: User

Code Groups:

1. All code: FullTrust

Success

This output describes policy data, not an active protection boundary. The first lines also show that Mono's security manager and execution checks are disabled in this invocation. Policy changes confirmation: True means CasPol is configured to ask before a change; it does not make a change safe or reversible by itself.

The -user selector is explicit and is a useful habit in scripts and notes. If you omit the selector, this installed command also reports the user level for -listgroups, but explicit scope makes the result harder to misunderstand.

3. Compare the machine and enterprise levels

Read the other policy levels without modifying them:

$ caspol -machine -listgroups
Security: False
Execution check: False
Policy changes confirmation: True

Level: Machine

Code Groups:

1. All code: Nothing
  1.1. Zone - MyComputer: FullTrust
  1.2. Zone - Intranet: LocalIntranet
  1.3. Zone - Internet: Internet
  1.4. Zone - Untrusted: Nothing
  1.5. Zone - Trusted: Internet

Success

The exact output is version-specific. In Mono 6.8.0.105, the machine level contains the default zone groups shown above, while the user level grants FullTrust to all code. Read the result as a description of stored policy objects. It does not prove that a program is being sandboxed, because the local Mono project documentation says that CAS is not supported and that the remaining implementation is disabled and non-functional.

To print all three levels in one read-only command, use:

$ caspol -all -listgroups
Security: False
Execution check: False
Policy changes confirmation: True

Level: Enterprise
...
Level: Machine
...
Level: User
...
Success

The ellipses above stand for the repeated group listings. Keep the full command output when investigating an old deployment, because the installed version and policy files determine the details.

4. Treat CAS as historical compatibility data

Mono's current CAS documentation is the boundary that matters here: it says CAS is not supported on Mono. Do not use a successful -listgroups result as evidence that untrusted assemblies are confined. Do not design a new security boundary around caspol, a zone group, or a permission set.

If an old application claims to depend on CAS, test the application itself in an isolated environment and identify a supported control for the real threat. Depending on the workload, that may mean a separate service account, a container or virtual machine boundary, filesystem permissions, a system service sandbox, or a network control. Those controls are outside CasPol, so changing CasPol policy is not a substitute for assessing the application.

5. Avoid the policy-changing traps

CasPol has operations that can change policy, including -reset. Do not run them on a shared host or production system merely to see what happens. A reset can alter how legacy applications resolve policy, and recovery depends on a policy backup being available. Take an approved backup and arrange a rollback before changing anything. Elevated privileges may be required for a machine-level change, but sudo does not make an unsafe policy change harmless.

One diagnostic trap is -listpset. On this installed release it can fail while formatting a named permission set with a System.ArgumentNullException. That stack trace is an observed tool failure, not proof that policy enforcement is working. Capture the version, command and output, then prefer the group listing or inspect the relevant deployment through its normal change process.

If you accidentally begin a confirmation prompt, answer no or interrupt before accepting a change. If a policy was changed, stop the affected application, use the approved backup or CasPol recovery procedure for that host, and verify the policy with the read-only commands in steps 2 and 3. Do not guess at a recovery file or delete policy data by hand.