fix(core) disable command_might_be_dangerous when unsandboxed

[dylan-hurd-oai]

Summary

If we are in a mode that is already explicitly un-sandboxed, then ApprovalPolicy::Never should not block dangerous commands.

Testing

• Existing unit test covers old behavior
• Added a unit test for this new case

[bolinfest]

This could also be because no sandbox is available, like for Windows users who have not installed our sandbox?

[dylan-hurd-oai]

Ah I might be misunderstanding the intent of FileSystemSandboxKind. Should we instead use the following logic?

let sandbox_is_explicitly_disabled =  matches!(
    sandbox_policy,
    SandboxPolicy::DangerFullAccess | SandboxPolicy::ExternalSandbox { .. },
)

I've updated to switch to this instead

[bolinfest]

Here's something that has been on my personal backlog:

Introduce a NoSandboxAvailable variant to SandboxMode and make sure ReadOnly means what we think it means everywhere it is used.

Currently, because we cannot distinguish between NoSandboxAvailable and FileSystemSandboxKind::Unrestricted, I don't think this change is safe.

Also, the point about prefix_rule() still stands, though I admit that if the agent is truly running unsandboxed and it is determined to do something, prefix_rule() is unlikely to stop it unless it's a setuid binary or something that can take an action as root that the agent has no other way of running...

[dylan-hurd-oai]

re: prefix_rule(), I don't think this change supersedes any ExecPolicy decisions, since this change is in render_decision_for_unmatched_command - I added an additional test to confirm this case.