Urgent.News

What's breaking now, across thousands of outlets.

Tech

Trying unknown Mac software without trusting it: a disposable macOS VM on Apple Silicon

At some point you want to try a Mac app you don't fully trust: a menu bar utility from a one-person shop, an installer someone linked in a forum, a CLI that wants sudo . Installing it on the machine that holds your SSH keys and browser profile is the fast option, and also the one with the worst cleanup story. A macOS virtual machine on Apple Silicon is a better boundary. It is not magic, and I'll…

Trying an unknown Mac application that you do not fully trust can be done safely using a disposable macOS virtual machine (VM) on Apple Silicon hardware. Installing the software on a regular Mac, which holds sensitive data like SSH keys and browser profiles, is risky and difficult to clean up afterward. A macOS VM on Apple Silicon offers a better boundary for testing the software.

A VM provides a separate macOS environment with its own user account, home directory, login items and launch agents. This allows the tested app to write to the VM without affecting the host system unless configured otherwise. However, the VM does not make any app safe and is not a hardened analysis environment for real malware.

Requirements for setting up the VM include an Apple Silicon Mac running macOS 14 (Sonoma) or later, sufficient disk space for the macOS restore image, the VM disk, and any copies, a comfortable macOS guest configuration with at least 4 vCPUs, 8 GB of RAM and 128 GB of disk, and a VM application capable of creating macOS arm64 guests. The guide uses a native VM manager for Apple Silicon.

To set up the VM, create a new macOS guest named "software-test-macos" and leave shared folders empty. Create a local account for the test that does not connect to your real identity. Install macOS updates, check the default privacy and security settings, create a plain folder like "~/Test-Downloads", and shut down the VM. Clone the VM as a clean baseline to return to if needed.

To install the software, download the installer inside the VM. Prefer a read-only shared folder for the installer and remove the shared folder after copying it. Do not share sensitive directories such as "~/Documents", "~/Desktop", "~/Downloads", "~/.ssh", browser profiles, password-manager exports, client project folders, or any files that you do not trust.

After installation, observe the software's behavior by paying attention to Gatekeeper prompts, permission requests, new login items, launch agents, daemons, browser extensions, network or system extensions, and any processes that keep running after closing the app. Use tools like Activity Monitor, Console, and System Settings to identify any changes left behind by the software.

If everything went well, keep the VM as a reference environment for future testing. If the app misbehaved, stop it and delete it from the VM. Remember that deleting the VM from the app's library does not remove the disk image, which can consume additional disk space. Remove the VM folder manually from the storage path once you are sure you no longer need it.

While this method offers risk reduction, it is not a guarantee of safety, especially when dealing with software only available for x86 macOS or requiring features like 3D acceleration, shared folders, audio, or USB passthrough, which are not supported in the current release of the used VM application. The VM acts as a layer of protection, but it should not be treated as permission to run untrusted software on your primary Mac.

Written by urgent.news from Dev.to's reporting — not their text. Machine-written — may contain errors; check the original before relying on it.

Read the original at dev.to →

More in Tech

"A second operation was started on this context" — the EF Core bug that only shows up under load

"A Second Operation Was Started on This Context" — The EF Core Bug That Only Shows Up Under Load You’ve debugged this error before: InvalidOperationException: A second operation was started on this…

  • Second operation started on EF Core bug under load conditions.
  • Root cause: service-lifetime design issue with fire-and-forget context leak.
  • Resolution: ensure one scope per unit of work, manage scopes explicitly.

CVE-2026-92951: CVE-2026-92951: Sandbox Escape via External Package Allowlist Bypass in vm2

CVE-2026-92951: Sandbox Escape via External Package Allowlist Bypass in vm2 Vulnerability ID: CVE-2026-92951 CVSS Score: 9.9 Published: 2026-10-01 An incorrect authorization and directory traversal…

  • Remote attackers can bypass sandbox in vm2, execute arbitrary host code.
  • Incorrect authorization and directory traversal in external package allowlist.
  • Upgrade to vm2 version 3.11.7 or later to fix vulnerability.

Understanding Prototypes in JavaScript: A Practical Guide for Developers

JavaScript uses prototypes to support inheritance, property lookup, and shared behavior between objects. Although modern syntax gives us classes and familiar object-oriented patterns, prototypes…

  • JavaScript uses prototypes for inheritance and shared behavior among objects
  • Every object has an internal prototype reference for property lookup
  • Prototype chain enables shared methods across instances and constructor functions

An uncalibrated classifier is worse than no classifier

What I learned building a website that rewrites itself for whoever is reading it, on ₹0 of infrastructure. Project Blog : https://santhosh-reddy.vercel.app/en/blog/8 Project Breakdown…

  • Uncalibrated classifier performs worse than no classifier
  • Poorly calibrated traffic split leads to slower convergence
  • Calibration solution over raw accuracy improvement

More from Friday 2 October →