Inspect Mono CAS Policy with caspol Without Changing It

caspol lets you read the Code Access Security policy levels Mono installs, without touching the policy files themselves. 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. None of this needs 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. Do not bother with caspol --version: it is not a supported CasPol option on this installation, and the version banner from -h is the check that actually works. The local caspol(1) manpage is only a stub anyway, pointing you at the help switch and Mono's own documentation.

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 describes policy data, not an active protection boundary. Those first lines also show Mono's security manager and execution checks are disabled in this invocation. Policy changes confirmation: True means CasPol will ask before a change; it does not make a change safe or reversible on its own.

The -user selector is explicit and worth the habit in scripts and notes: this installed command also defaults -listgroups to the user level if you omit it, but spelling out the scope makes the result harder to misread later.

3. Compare the machine and enterprise levels

Read the other policy levels without touching 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 holds the default zone groups above, while the user level grants FullTrust to everything. Read that as a description of stored policy objects, not proof anything is sandboxed: Mono's own project documentation says CAS is not supported and the remaining implementation is disabled and non-functional.

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

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

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

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

4. Treat CAS as historical compatibility data

Mono's current CAS documentation is the boundary that actually matters here: it says CAS is not supported on Mono. A successful -listgroups is not evidence that untrusted assemblies are confined, and none of this is a foundation for a new security boundary around caspol, a zone group, or a permission set.

If an old application claims to depend on CAS, test it in an isolated environment and find a control that is actually supported for the real threat: a separate service account, a container or VM boundary, filesystem permissions, a system service sandbox, or a network control, depending on the workload. Those sit outside CasPol entirely, so changing CasPol policy is never a substitute for assessing the application itself.

5. Avoid the policy-changing traps

CasPol has operations that change policy, including -reset. Do not run them on a shared host or production system just to see what happens: a reset can change how legacy applications resolve policy, and recovery depends on a backup existing. 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.

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