Windows has virtualisation based sandboxing and NT has object-level security (albeit not often used correctly and granularly) and macOS has (among other things) SIP and a subsystem called sandbox that does exactly what it says: it sandboxes. It can sandbox in comparable namespace terms (like cgroups v1 or v2, but more in translocation style execution since it's a MAC framework) yet it also does it a much more fine-grained level depending on what you need. It is used by launchd and applications by default, some entitlements require it so if you want to do some broad kind of elevated application, you also have to have a specific sandbox profile. It's also been around for 16 years, and comes with a ton of examples if you wanted to use it yourself to constrain some process. Yes, it can do filesystem (would be pointless without it), but also does ipc, io, network, memory, fcntl, sysctl, mach ports, sys calls, processes, ui, sockets, messaging, events and all of that including context-aware filtering and compound matching for all of them. And if that's not enough there is also ESF and NEF, the latter only working on networking. You can compare those two to eBFP LSM and XDP. If you want all of this on linux, you'll need to add a lot of custom eBPF and LSM as well as always run in a hypervisor for guaranteed IOMMU usage, but you can't use bare KVM for that either, so you'll either need to never touch the privileged kernel (not even give it a console) or you need to run Xen and use XSM.
Flatpak is just a cheap container copy. Can't do anything beyond what cgroups and things like apparmor and selinux can do, and uses a runtime to do soft higher-level policy functions that translate down to the same primitives. If anything, it's a great bundler, but doesn't do anything new policy-wise.
So, can you get the macOS-level capabilities (both low-level and higher abstractions)? On Linux, yes, but they don't exist yet. On Windows: technically possible, but since that would break most GUI workflow it's not likely that anyone is going to bother, and you're going to have a hard time recompiling windows yourself to make that happen.
Hello, can you tell me if I can filter syscalls made from a memory address in macos without virtualizing the process, or requiring special entitlements and root? I currently have a project where sandboxing is important and i need to prevent all syscalls from a region. This is very simple in linux, and on openbsd i dont have to do anything because openbsd by default does not allow untrusted callsites from making syscalls (and the region in this case is not loaded by openbsd's dynamic loader).
On macos i currently virtualize the process itself, but this has virtualization overhead and some emulation overhead because macos does not let you map all the host process pages to a guest.
I don't think so, the XNU and macOS LS architecture doesn't assume you're going to do policies based on the internal memory topology of a process. It's usually done with multiple processes and having one be very constrained doing only some very specific calls and the other not being able to do any calls at all.
You can probably get by with mprotect or mach internals, but if you're developing at that level you've probably already either implemented or dismissed that.
It's a bit of a different architecture with PAC/MIE/APRR (and to a degree AMFI) being used to prevent abuse that would require syscall filtering in the first place. While I personally don't think that's airtight, it does appear to work out well for their ecosystem.
Edit: come to think of it, region-based call filtering is never really going to be enough on its own, if you don't combine it with other techniques it's basically a rop gadget fest. Probably also why SBX went for intent rather than trying to do it based on location/origin.
Wouldn't it have made more sense for Claude to suggest using the existing Linux-Airprint-VM project/product that already does this exact thing?
There's even a zero-install method via https://printervention.app where it runs that Linux VM isolated inside a WebUSB-capable browser. That website itself was posted right here on HN not too long ago.
I get that the LLM code assistant software prefers writing stuff, but constantly re-writing the same solution seems a bit inefficient.
Are you sure that approach would work? Usually I find these sort of projects end up not working just for the specific device I happen to have, which is always unsupported lol.
It's been extensively reported on, and any AWS user that clicks on the health dashboard would also have seen it, even if they don't consume from news outlets.
As for use it gets: plenty of use, mostly when someone needs to have their worlds close to that area (usually latency or legal reasons). There are a lot of smaller businesses that lost a lot (or maybe even everything) because their never thought they would need to create backups in a different region. Most of that wasn't really reported on but instead gets shared on various platforms like Reddit.
> Are you implying that something that gets reported on, shouldn't be on HN?
> Off-Topic: Most stories about politics, or crime, or sports, or celebrities, unless they're evidence of some interesting new phenomenon. If they'd cover it on TV news, it's probably off-topic.
How is it crazy? It's perhaps not granular (the repository is the boundary, and that's that), but you can definitely restrict who can pull or push as easy as you can make rules for SSH.
Plenty of not-very-granular "enterprise" systems out there, it's not exactly unique to not always have full ACLs on the smallest of objects.
What are you even talking about. Every M1 Mac and earlier runs Linux. Even all the way back to PowerPC.
Granted, the M1 and up are not 100% covered yet (driver-wise), but they aren't EOL either. And if they were, Linux would still run anyway. Take a 20 year old Mac and you'll run Linux just fine. 10 year old Mac, Linux still runs fine. Take an M1 and it's a joy to use with Linux. Taken an M2 and it will boot and you can be pretty sure it will run very well long before it's EOL too. And even if it's EOL, it's not going to prevent you from running Linux later.
As for the PC example: definitely EOL problems there. Try getting your EDK2-based UEFI stack patched on an old computer. At some point you won't be getting certificate updates and if you either forget to install a local override or if the vendor didn't add it, you're SOL, especially on laptops where you can't disable secure boot.
Those local options exist, and have been around forever, but the problem is nobody is doing it without cutting corners and with pay-as-you-go elasticity (and the 'call an API, get a VM instantly' effects that go with it).
Most on-prem deployments were trash and a lot of them still are. Not because it couldn't be better but because it's easier to just have some random hypervisor department do this work manually and not do the work to create it as an internal product. Even VMware with vrealize failed and that's about as 'customisable cloud platform in a box' as COTS enterprise software can get.
Maybe it's because IaC and APIs were just not in the vocabulary of the average system integrator or on-prem operating team (it's still lots of clickops and copy-paste).
Not really, some of the IP is core to the product and it cannot function without it. In theory if you do something like come up with a complete replacement for EUV, you could, but everyone with deep pockets has already been trying to do that without success. Same goes for the supply chains, most companies (including ASML) don't manufacture everything themselves; so components that come out of the US would need non-US suppliers, which don't always exist.
I suppose it's a case of 'technically possible, realistically infeasible'.
A more likely scenario might be either a from-scratch not-as-good machine that you can source locally (supply-chain wise) or a novel finding (which is hard to predict if it will happen and if so, when).
That statement makes no sense. X11 works fine on macOS and running it in rootful mode with Gnome essentially works the same way it would work on an OS that uses the Linux kernel.
Granted, it will not integrate with anything hardware-wise by itself (unless there's a package for it - if not, macOS still handles it, and Aqua/Quartz will keep running in the background anyway), but if what you wanted was something that is KDE or GNOME running with its own WM on its own X11 server, doing the exact same thing you'd get if you're running a Linux distro, that's been natively possible for over 15 years.
If a power user loses their power based on what GUI happens to be in front of them, how much of a power user was the power user to begin with?
There is a major difference between losing your power and having to constantly fight the UI to keep your power. And, for example, window management on Mac is clunky as all hell.
Flatpak is just a cheap container copy. Can't do anything beyond what cgroups and things like apparmor and selinux can do, and uses a runtime to do soft higher-level policy functions that translate down to the same primitives. If anything, it's a great bundler, but doesn't do anything new policy-wise.
So, can you get the macOS-level capabilities (both low-level and higher abstractions)? On Linux, yes, but they don't exist yet. On Windows: technically possible, but since that would break most GUI workflow it's not likely that anyone is going to bother, and you're going to have a hard time recompiling windows yourself to make that happen.
reply