sandboxing

OpenSSH's design is the model answer, but interviewers want you to derive it: what the parser must never hold, how small the privileged half can get, and the three mistakes that make a privilege drop reversible.

Assume the parser will be exploited, then decide what the exploit gets. The scored design has a disposable worker with nothing worth stealing, no way out, and a narrow, validated return path.

A seccomp filter decides on a system call number and six integers. It cannot read the file path a pointer refers to, and that one limitation shapes every good policy.

Browsers assume the JavaScript engine will be exploited. The architecture is built so that one bug buys an attacker a locked room, and they need a second, different bug to leave it.

Every platform that runs someone else's code (plugins, notebooks, AI agents, serverless) must pick a boundary. The right one depends on what the code may do and what a single bug in the boundary costs.

Sender authentication proves which domain sent a message, not that the message is safe. The scored answer walks the layers after it and where each one is blind.

File tools take paths from the model, and the model takes ideas from whatever it read. A string check for '..' is not confinement.

Both platforms sandbox apps and require signing; they differ in who decides what runs and how fast fixes arrive. Interviewers want the shared model first, then the differences that change a threat model.

The sandbox is a Linux user ID, SELinux and a signature that decides who you are. Get those three right and most Android security questions become reasoning rather than recall.

The question is really 'what does hostile code have to break to reach the host?' Answer that for each option and the choice follows.

Assume the code is hostile and design until that stops mattering. Then the interviewer adds a GPU and the internet, and you design again.

The weights are safetensors and the code is a Python file from the same repository, fetched at load time. Guess which one runs with your credentials.

Treat repository code and shell execution as part of the threat model. Define reachable files, credentials, services and publication paths, then verify the actual sandbox and CI handoff rather than trusting command names.

Distinguish profile, device and account boundaries, then bind UI actions to the intended app, recipient and effect. Screenshots and accessibility trees provide observations, not trusted authorization.

Design-time controls decide what an agent may do. Runtime protection watches what it actually does, at four different layers, and each layer catches something the others miss.