You are viewing the intel version of our documentation.

Anka Secure

Anka Secure solution is built on top of Anka macOS virtualization engine with features to create secure VMs and manage and distribute to the users.

What is Anka Secure?

Anka Secure solution is built on top of Anka macOS virtualization engine with features to create secure VMs and manage and distribute to the users. Anka VMs by default are intended to provide reproducible, stable, controllable, shareable environment for different tasks: build, test, debug etc.

VM isolation enables multiple environments simultaneously on the same host.

Processes running inside isolated Anka VMs can communicate with the outside world, including host via network interfaces, shared folders, pasteboard, and other mechanisms. However, there are use cases where there is a need to disallow any communication between processes running inside Anka VMs and the outside world and/or the host.

Some of the common examples are :

  1. Protecting privileged user access to sensitive data on a single device - Technical support accessing customer systems/data from their workstations, developers accessing and working with corporate developer/application certificates on their workstations.

  2. Increasing productivity of superusers who use macOS workstations by freeing security restrictions which impact their ability to innovate, without compromising enterprise security - iOS developers working/researching with beta versions of libraries, Xcode, third party libraries downloaded from the internet.

  3. Increasing productivity of superusers who use macOS workstations by freeing security restrictions which impact their ability to innovate, without compromising enterprise security - iOS developers working/researching with beta versions of libraries, Xcode, third party libraries downloaded from the internet.

  4. Malware and other sensitive analysis and testing tasks for macOS Anka Secure protects the Anka VM environment from unsolicited use, modifications and leakage of critical resources by controlling access and actions on these machines with a VM Policy.

Note In order to avoid risks of data stealing and modifications by unauthorized users, all information stored on disk images is also encrypted on the fly.

Anka Disk Engine is closely integrated with VM Policy and performs on the fly encryption (OTFE) of all information passed to/from disk image. Encryption uses cryptography data from the associated policy, so it’s not possible to use (decode) encrypted drive with another policy or without policy itself. This robustly protects encrypted VMs from policy replacement attacks.

OTFE is not turned on by default. You can enable it with:

anka -l {policyAdmin} modify {VM} set policy
[ENTER PASSWORD FOR {policyAdmin}]
anka modify {VM} set hard-drive 0 --enc aes-128 ## This merges all layers together into one, so you lose any VM template layer sharing/disk optimization ##
anka -l {policyAdmin} start vm

This start will prompt for the {policyAdmin} password you set in the set policy command. To avoid the need to put in the password, you can set ANKA_USER={policyAdmin} and ANKA_PASSWORD={policyAdminPasswordHere} on the machine.

Once your VM is started, the anka run commands work just fine without any -l or password/envs. Enabling policy forces any start/stop/modify commands to require the policy admin and password, else it will throw an error.

Currently aes-ecb encryption algorithm is supported. 128 bit encryption is more than enough to protect VM from unsolicited access/modifications, but for some applications aes-ecb-256 could be needed.

Creating VM Policy

Core elements of the VM Policy are:

  1. Users (and groups)
  2. Rules

Every vm policy can be treated as a user database (accounts, participating in policy). Every user, registered in the policy belongs to groups, group has similar parameters as a user, for example name and associated rules. Unlike the users, groups doesn’t contain authorization and crypto information, so group name can’t be used to access the policy.

Group can be a part of another group, so the policy is actually tree structure of users and groups.

The “standard” group is the root of the tree, every user and group is part of this group. Another predefined group is “administrators”. Administrators is part of the standard group, but has some fundamental differences:

  1. Only administrators can modify policy.
  2. Policy has to have at least one administrator.


Another part of the VM Policy is rule. Rule is a literal string rulename with assigned verdict:TRUE or FALSE.


Example -

Rule is not being used by policy itself, conversely systems (VM in our case), using the policy, associate their internal functionality with certain rulename.


com.veertu.ankahv.fs controls shared folder functionality for the VM. controls VM networking.

Behavior of the VM can be altered by changing the VM policy.

The rulename has reverse domain name structure (dot separated), and processing of rule is also happening in direction from larger scope to more specific one. Rule that describes more generic scope affects all subscopes, and “sub rules” could override rules of larger scope.

com.veertu.anka.fs=deny - specified in policy, disables ability to mount any host folder into VM.

Additional “sub rule" com.veertu.anka.fs./Users/test/workspace1=allow overrides more generic com.veertu.anka.fs rule, and allows to mount workspace1 (and any of its subfolders) of system user test.

Policy rules are used to control entire VM functionality: ability to start, modify, access network, use shared paste buffers, external drives, USB, etc. Rules mechanism is pretty flexible, so it’s easy to add additional controls in the future.

Anka VM policy rules can have three kinds of “verdicts”.

  1. Logical TRUE (allow, enable, 1, yes, on, pass, …)
  2. Logical FALSE (deny, disable, 0, no, off, block, …)
  3. Undefined (the rulename is not specified in the policy)

By default all runtime features, like networking, shared folders, are “enabled”, so to disable them it’s needed to explicitly specify corresponding denial rule in the policy.

Contrary to this, all configuration changes - changing RAM size, VNC password, etc (except some needed for normal operation of anka tool) are prohibited by default to non-administrators.

To allow such changes, explicitly specify corresponding rule in the policy.

Runtime functionality rules have the following form - com.veertu.ankahv.{function}={verdict}

Rules for VM configuration have the following form - com.veertu.anka.cfg.{parameter}={verdict}

Anka Secure policy Management

VM Policy can be modified by users with a private key. Administrators have such key, while regular users have only public key, so they are only able to read policy. Groups have no keys at all, so they can’t be used to open policy file.

This design prevents modification of policy files by non-admin users. It’s safe to share policy files over unencrypted channels and store in plain files - no additional protection is required. But such design also introduces some limitations in assigning user’s passwords - only administrator can modify user’s data, the user is not able to change their password in policy by themselves.

To get temporary passwords, password renewal (by user) and other “privacy” related things, additional external mechanisms should be invoked.

Following algorithms are used - RSA-2048, SHA-256, AES-256 .

Critical policy parts are encrypted with user’s password (aes-cbc-256).

Policy Management Tool

Current implementation of VM Policy uses separate json files to store user/rules db and cryptographic information. To maintain policy and sign VM configuration files the policy tool is used. This tool is being shipped with Anka package 2.0 , available with Anka Secure license and above (located at /Library/Application\ Support/Veertu/Anka/bin/policy).

This tool can be compiled and used under Linux and (probably) other posix compliant systems.

/Library/Application\ Support/Veertu/Anka/bin/policy
usage: policy [options] <command>

   Manipulate Anka policy (create, add, assign, sign, ...)

  -l,--login <val>   Username to access policy file
  --version          Print version information and quit
  --help             Show usage for particular command and exit

  create             Create new policy file with initial admin user
  adduser            Add new user to policy
  addgroup           Add new group to policy
  delete             Delete user or group from policy
  join               Add user/group to certain group
  leave              Remove user from group(s)
  users              List the policy users
  groups             List the policy groups
  assign             Assign rule(s) to certain user or group
  retract            Retract rule(s) from certain user or group
  rules              List rules applied to the user or group
  decide             Evaluate the rule for the user returning corresponding status
  sign               Sign input (yaml) file
  validate           Validate integrity of (yaml) file

Every policy has to have at least one administrator user. This user is created during the creation of new policy file. Later users and groups can be added with corresponding commands.

The policy tool infers “current” user from command line option, environment, and current macOS user name in the following order.

  1. --login <username> command line option
  2. ANKA_USER environment variable,
  3. current system user name (a user under which the policy tool was started)

Some commands don’t require authentication and could be invoked anonymously, like users, groups & rules.

Password is required to authorize certain user. The password could be provided through ANKA_PASSWORD environment variable, or asked interactively through tty (if connected). If no tty is connected to the policy process and the ANKA_PASSWORD variable is not found, the user’s password is assumed to be EMPTY (that is also valid, but insecure, password).

Turn Policy on for a VM - anka modify VM set policy

This command creates policy.json file inside VM folder with initial admin user, inferred from arguments and environment as discussed above. Initial policy has some predefined minimal set of rules to allow core Anka logic (i.e. clone, suspend, push, pull etc) to operate.

View active rules (for current user) - policy rules /path/to/vm_dir/UUID/policy.json

This operation doesn’t require actual authorization.

VM Policy can be changed later (with the policy tool) to allow non-administrators to make some changes like change cpu count, RAM size, configure display settings etc.

Disable VM Policy - anka modify VM delete policy

Only administrators can delete the VM policy.

Clone - Clone operation preserves current policy settings and so it’s allowed to all users by default. clone --copy produces pure (no policy) VM. So clone --copy operation can be performed only by the VM administrator.

Push and Pull - Pushing and pulling of VM is also allowed to all users by default. Implement certificate based access to the registry is supported to control access for the users.

Note VM functions that don’t affect VM configuration and runtime directly (anka config, anka registry,cluster etc) are not controlled by the policy.

Anka Secure Policy Rulename List

com.veertu.ankahv.start=0 To disable VM to start by authorized user (non-authorized ones can’t start in any case)

Networking disable “local” (interhost) connectivity set all IPs blacklisted by default{}=1 whitelist specific outgoing IP address disable TCP protocol disable UDP protocol disable other (that TCP and UDP)

Special com.veertu.ankahv.local=0 rule disables any connectivity (Ethernet and IP levels) among host where VM is running. This includes

  1. Inter vm connectivity
  2. VM - Host connectivity
  3. VM - host bridge and aliases connectivity
  4. Zero configuration protocols (DNS, DHCP, ARP..) handling

Note The user can still build custom network topology, e.g. connect personal laptop with patch cord, and perform uncontrollable (from the perspective of corporate network) data transfers.

Protocols{prot_number}=1 allow specific network protocol (ethernet) disable all port forwarding rules{dport}.{addr}.{sport}=1 allow specific port forwarding rule. {lp} is port opened on the host, {addr} is a listening address, for example receives connections from any peer, {dp} is service port in VM.

Due to reverse domain name essense of the rulename processing, there could be some “wildcards” in the port forwarding rules. - Allows connections to any port inside VM from host through port 20000

Disk Access com.veertu.ankahv.disk=0 prevent access to any unencrypted drives com.veertu.ankahv.disk.%s=1 allow access to certain unencrypted drive

Shared Folders and Anka Run com.veertu.ankahv.fs=0 disable ability to mount host folders com.veertu.ankahv.fs.{/abs/path/to}=1 allow to mount specific host folder disable anka run functionality{/abs/path/to}=1 allow to run certain commands via anka run

Anka View com.veertu.ankahv.view.pb=0 disable shared paste bufferd(PasteBoard) in Anka View com.veertu.ankahv.view.hid=0 disable keyboard pass-through in Anka View

Anka VNC
Anka VM has it’s own implementation of VNC (RFB) server, allowing to access guest’s display via the network protocol. Additionally macOS guests have Screen Sharing service, also allowing to interact with the desktop over network.

Anka VNC doesn’t allow to use any kind of paste buffer sharing, moreover once the policy is enabled for certain VM, the VNC password became encrypted.

height: 768
pci_slot: 29
width: 1024

Users who don’t know Anka VNC password are not able to infer it neither with anka describe, neither anka show commands. There is no special policy rule, controlling Anka VNC module for now.

To control connectivity to the guest’s Screen Sharing service, disable local networking, and close guest port 5900 from port forwarding.


USB Pass-Through is provided by the uhost module. Policy allows to prevent this module from loading. So with policy USB pass-through could be enabled or disabled only generally - on all kinds of devices.

com.veertu.ankahv.usb.{module}=0 disable corresponding USB Module (“host”)

Installation and Configuration

Anka when activated with the Anka Secure license enables installation of Anka package all mac hardware with Secure modules. It enables administrators to create policies for the VM and assign users/groups to the VM policy.

Installing the Anka Hypervisor binary is remarkably simple, just download it from Anka Secure Download page.
Run the anka.pkg installer. The Anka package includes the Core hypervisor and anka guest Add-ons.

After running the installer package, anka is found at /usr/local/bin/anka.

Verify the installation by running anka version command.

After install, if the users want to, they can change the location of this default Anka install location link manually.

Execute sudo mv /usr/local/bin/anka /to/any/other/location/.

Verify the installation by running anka version command.

View all settings for Anka installation on the host with anka config -l command.

Activate with your Anka Secure license key.

sudo anka license activate <key>

Upgrading the Anka Package

  1. Download the latest version of Anka package (.pkg) and stop all running VMs.
  2. Before upgrading, you will also need to force stop any suspended VMs with the anka stop -f {vmNameOrUUID} command.

Note For major Anka releases, it maybe required to upgrade guest addons in existing Anka VMs. Check the release notes to identify if this step is required or not.

  1. Upgrade guest addons on the VM. Execute the following command to upgrade guest addons in existing VMs to the current release.
anka stop -f {vmNameOrUUID}
anka start -u {vmNameOrUUID}
Preparing update configuration
Installing updates
update succeeded

If you are not able to upgrade the guest add-ons tool using the anka start -u {vmNameOrUUID} command, then you have a very old version of guest addon tools on your VM. You will first need to manually update them. Contact Veertu support. 4. Push your upgraded VMs to the Registry.


From the command line, execute the following command. Make sure all your VMs are stopped.

sudo /Library/Application\ Support/Veertu/Anka/tools/