Terminal is a significant risk though and I’d still really like to see macOS improve the APIs around filesystem access.
Granting terminal full disk access grants arbitrary scripts full disk access. There’s a lot you can do with ACLs and the permissions system, but it’s not reflected in the UI for settings.
Then there’s allowing access to documents, downloads, desktop, external disks. This should really allow the user to select a path or paths for applications, because these options are way too broad (especially external disks).
This is why I use Terminal as my primary terminal, and iTerm as my AI terminal. iTerm gets no permissions, I move specific things to Terminal to do it. Plus I can then style them to optimize for the different usages. And iTerm has better harness hooks anyway.
I would still like to see not only more granular permissions, but single use permissions. Once I grant iTerm access to Documents for whatever reason, it always has such permission. I would be nice to limit that to a single use, or a single harness session.
But your terminal shouldn't be accessing any files; you just need to be able to launch /bin/zsh or whatever you use as your shell. The shell needs to be able to access files, but its container doesn't.
Of course, you could go farther. For example, on OpenBSD, even /bin/ksh has been somewhat sandboxed; it can see most of the file system, but the things it can do have been limited:
It really isn't; the program just needs to be able to declare what it expects it should be able to do, and what it expects its children should be able to do. The latter doesn't need to be a subset of the former.
It's done on the majority of the OpenBSD base system, as well as important ports like Chrome and Firefox. Linux also has the parts to do this, though it's more fragile and complicated.
To be clear I have a much higher standard for what is acceptable than that, you really need to consider software that a hundred million people are going to use
you mean "isn't"? Though there is no indication that a lot was invested, so doesn't give you the measure (my comment was about the availability of resources, not of their actual use)
It's already done on OpenBSD, and linux has the pieces to do it, though it's far more fragile and complicated. I'm not speaking hypothetically here, I've implemented code that works this way.
You are minimizing the difference in scope between the audience and applications of OpenBSD and those of macOS.
macOS has had a capabilities model for over a decade called App Sandboxing. It would be entirely impractical to expect app authors to correctly declare their permissions up front and for users to audit them. Hence the permissions granted to sandboxed apps are pre-determined by the OS, and can be extended through explicit user interaction.
The latter does need to be a subset of the former, or else an attacker can trivially work around limitations on "what it should be able to do" by spawning a child instead of doing the thing directly.
But yes, it's unfortunate that macOS sandboxes cannot be nested.
>The latter does need to be a subset of the former, or else an attacker can trivially work around limitations on "what it should be able to do" by spawning a child instead of doing the thing directly.
That assumes you're only defending against malicious code. Spawning children with limited functionality is a useful defense against non-malicious code being exploited by malicious data, even if those children have privileges the parent lacks.
This position is trivially incorrect as it makes the entire concept of a login shell impossible in the first place, as you have just described the regime in which login, su, and even basic tools like ping (which have the permission to use raw sockets and write ICMP even though we would never let any of its parents do so) operate.
Terminal (and sshd) are special, in that they actually do end up with inherent transitive permission to their immediate intended child processes, as those children are nigh-unto universally (due to the entire idea of what terminals do) designed to be operated using text written to their input, which Terminal (and sshd) can man-in-the-middle.
But like, that doesn't generalize: it certainly (and obviously) is the case that I can have a process that is allowed to write files to disk that I would be happy to let you run even if I do not trust you to write to even those same files (as you will corrupt them), much less any file on my disk, as I merely need to trust that application to not give you the ability to do arbitrary writes.
The better idea here is that processes are their own form of encapsulation, and just because they can do something doesn't mean that they expose that functionality. You thereby must limit what tools can be used by a parent -- so almost no one gets a generic "exec" permission: you get a whitelist of tools and arguments you can utilize -- but the result doesn't look much at all like the permissions on subprocesses needing be a subset of the parent.
Yes, and macOS entitlements work similarly, as you know. I was interpreting “what it expects its children should be able to do” as a single rule for all child processes, like in OpenBSD pledge() which the parent seems to be referring to. Sure, such a rule could securely be greater than the parent’s own permissions if you strictly limit what processes can be executed with what arguments.
Actually, there’s another exception to my previous statement that I should have mentioned. For mitigations that are meant to prevent an attacker from turning memory corruption into code execution or code-execution-like control – such as restrictions on mapping memory executable (at least that’s one purpose for such restrictions), or memory map lockdown – the mitigations’ effectiveness doesn’t depend on whether they’re applied to children. Those mitigations are sometimes treated as part of the sandbox system, sometimes separate.
The TCC system attributes the access to Ghostty because that’s the thing the user understands as the app they are interacting with. Otherwise every `posix_spawn()` and `system()` call would result in a new TCC prompt attributed to an inscrutable name.
ls does not live in an .app bundle and it is not managed by launchd. The TCC framework (which implements sandboxing on macOS) and the rest of the UI only respects .app bundles since that's the thing the user sees. The fact that ghostty is fork/execing another process to to the disk access is immaterial to it - hell, if Apple had their way only launchd and Safari would be able to spawn processes at all (like on iOS).
I mean, think about it: what would it mean if ls had a separate sandbox identity from the shell that spawned it? It would mean that any process on the system not entitled to read files from disk could get that entitlement by just fork/execing ls and parsing its stdout. That's not a security boundary that makes sense. ls doesn't read files - ghostty reads files, and ls is just its deputy.
ghostty is the .app, perhaps it makes more sense if you imagine some other app, Spotify.app say, imagine for whatever reason it shells out to ls for listing files, it will show as Spotify requesting access not ls.
Spotify has (had? I no longer use it) a feature that would allow you to make local media available as part of your library anywhere so long as your machine was on and connected to the internet. I would imagine that feature requires disk access under these sandbox / permission models.
Edit: I should say, the model it was created with (select a folder, all media in that folder is mirrored) requires such permissions. One could imagine designs that don’t.
I haven't tested Apple's access model, but is there something that's stopping Gemini from launching `ghostty -e /bin/sh malware.sh`?
Windows' Vista-era UAC protections have been bypassed through lolbins since the day of its inception (although officially UAC is not a security boundary according to MS) and apps like Ghostty might punch a hole through disk access controls in the same manner.
moecables · · focus · HN ↗
- Ghostty (fine, it's my terminal)
- Alfred (fine, I use it for searching everywhere)
Then I have a few turned off:
- Spotify (why does it need full disk access) ??
- Gemini (nope, don't need it to know everything about my computer)
coderbants · · focus · HN ↗
Granting terminal full disk access grants arbitrary scripts full disk access. There’s a lot you can do with ACLs and the permissions system, but it’s not reflected in the UI for settings.
Then there’s allowing access to documents, downloads, desktop, external disks. This should really allow the user to select a path or paths for applications, because these options are way too broad (especially external disks).
[deleted] · · focus · HN ↗
[deleted]
ashishb · · focus · HN ↗
Indeed, I run all dev tools including coding agents inside sandbox now
<a href="https://github.com/ashishb/amazing-sandbox" rel="nofollow">https://github.com/ashishb/amazing-sandbox
jackjeff · · focus · HN ↗
If you open a project using a devcontainer it prompts you to build one. As long as you install all the tools you need in it, it just works.
Orbstack is much nicer than Docker to host the containers.
jshier · · focus · HN ↗
I would still like to see not only more granular permissions, but single use permissions. Once I grant iTerm access to Documents for whatever reason, it always has such permission. I would be nice to limit that to a single use, or a single harness session.
ghusto · · focus · HN ↗
No, it grants scripts I run full disk access. Unvetted scripts do not run in my terminal, so there are no secret sub-processes either.
m463 · · focus · HN ↗
get out of my way.
smcleod · · focus · HN ↗
0c3ca83 · · focus · HN ↗
But your terminal shouldn't be accessing any files; you just need to be able to launch /bin/zsh or whatever you use as your shell. The shell needs to be able to access files, but its container doesn't.
Of course, you could go farther. For example, on OpenBSD, even /bin/ksh has been somewhat sandboxed; it can see most of the file system, but the things it can do have been limited:
saagarjha · · focus · HN ↗
joshspankit · · focus · HN ↗
0c3ca83 · · focus · HN ↗
saagarjha · · focus · HN ↗
0c3ca83 · · focus · HN ↗
saagarjha · · focus · HN ↗
0c3ca83 · · focus · HN ↗
saagarjha · · focus · HN ↗
eviks · · focus · HN ↗
saagarjha · · focus · HN ↗
eviks · · focus · HN ↗
saagarjha · · focus · HN ↗
dcrazy · · focus · HN ↗
0c3ca83 · · focus · HN ↗
dcrazy · · focus · HN ↗
macOS has had a capabilities model for over a decade called App Sandboxing. It would be entirely impractical to expect app authors to correctly declare their permissions up front and for users to audit them. Hence the permissions granted to sandboxed apps are pre-determined by the OS, and can be extended through explicit user interaction.
comex · · focus · HN ↗
But yes, it's unfortunate that macOS sandboxes cannot be nested.
mrob · · focus · HN ↗
That assumes you're only defending against malicious code. Spawning children with limited functionality is a useful defense against non-malicious code being exploited by malicious data, even if those children have privileges the parent lacks.
saurik · · focus · HN ↗
Terminal (and sshd) are special, in that they actually do end up with inherent transitive permission to their immediate intended child processes, as those children are nigh-unto universally (due to the entire idea of what terminals do) designed to be operated using text written to their input, which Terminal (and sshd) can man-in-the-middle.
But like, that doesn't generalize: it certainly (and obviously) is the case that I can have a process that is allowed to write files to disk that I would be happy to let you run even if I do not trust you to write to even those same files (as you will corrupt them), much less any file on my disk, as I merely need to trust that application to not give you the ability to do arbitrary writes.
The better idea here is that processes are their own form of encapsulation, and just because they can do something doesn't mean that they expose that functionality. You thereby must limit what tools can be used by a parent -- so almost no one gets a generic "exec" permission: you get a whitelist of tools and arguments you can utilize -- but the result doesn't look much at all like the permissions on subprocesses needing be a subset of the parent.
comex · · focus · HN ↗
Actually, there’s another exception to my previous statement that I should have mentioned. For mitigations that are meant to prevent an attacker from turning memory corruption into code execution or code-execution-like control – such as restrictions on mapping memory executable (at least that’s one purpose for such restrictions), or memory map lockdown – the mitigations’ effectiveness doesn’t depend on whether they’re applied to children. Those mitigations are sometimes treated as part of the sandbox system, sometimes separate.
mindwok · · focus · HN ↗
rolosa · · focus · HN ↗
0c3ca83 · · focus · HN ↗
dcrazy · · focus · HN ↗
kmeisthax · · focus · HN ↗
I mean, think about it: what would it mean if ls had a separate sandbox identity from the shell that spawned it? It would mean that any process on the system not entitled to read files from disk could get that entitlement by just fork/execing ls and parsing its stdout. That's not a security boundary that makes sense. ls doesn't read files - ghostty reads files, and ls is just its deputy.
OJFord · · focus · HN ↗
king_geedorah · · focus · HN ↗
Edit: I should say, the model it was created with (select a folder, all media in that folder is mirrored) requires such permissions. One could imagine designs that don’t.
crooked-v · · focus · HN ↗
The gap here in functionality is between 'single manually specified folder/file' and 'entire disk'.
Hobadee · · focus · HN ↗
Still does, at least on Windows. I use it all the time - I have a playlist with a mix of Spotify music, and music from my server.
musicale · · focus · HN ↗
Joker_vD · · focus · HN ↗
jeroenhd · · focus · HN ↗
Windows' Vista-era UAC protections have been bypassed through lolbins since the day of its inception (although officially UAC is not a security boundary according to MS) and apps like Ghostty might punch a hole through disk access controls in the same manner.
gregoriol · · focus · HN ↗
chrisjj · · focus · HN ↗
Hobadee · · focus · HN ↗
<a href="https://www.youtube.com/watch?v=VuqZ8AqmLPY" rel="nofollow">https://www.youtube.com/watch?v=VuqZ8AqmLPY