It's a bit odd that the response here is to patch every single XPC service individually. This feels like some kind of design issue in the sandbox itself. Why are so many XPC services that are clearly intended to be app private reachable from sandboxed apps?
Yep, it is the most likely the compromise to retrofit this into macOS, without breaking everything in UNIX and NeXTSTEP land that has been ported into macOS.
On Windows land you have something similar, there is the WinRT sandbox, Win32 app sandbox, secure kernel, driver guard, and a miriad of other stuff, but there are also the cracks of backwards compatibility, specially if you want a single executable able to run across all those configurations.
Mobile OSes have it easier, because of no backwards compatibility and the restrictions that are able to impose as execution model.
No, it has nothing in to do with NeXTSTEP. XPC was designed recently and for macOS/iOS. This is just that it was not designed with security in mind along this axis.
Readers here are all very likely to appreciate some links alongside statements, cause really this is a sensitive topic. Both statements need certain context as it seems it’s not the universal understanding of what goes on and how often.
Not sure it can be proven with citations but it's well known that process injection is widely used on Windows. GPU drivers are known to do it. Utilities have historically often injected code into Explorer. Raymond Chen has written in the past about this problem and how hard it made it to evolve the platform.
For code injection into applications that don't load third-party DLLs as plugins, see, e.g., Microsoft's (unsupported) toolkit for runtime API interception:
You install tortoiseSVN or something similar, look at explorer.exe process or any process that use a standard "Open File" widget, and you will see some dll from the utility loaded by the process. (Easy to see with process explorer from sysinternals)
I think tortoiseSVN and consorts are "just" a shell extension, though, which is an officially supported concept, even if that means that potentially any random software using the standard file dialogues ends up loading your DLL, too.
Yeah. That really doesn’t need to be from the store.
I really hate going through the Apple Store to download Xcode. We all know how to download software. I’d rather go through a dev portal than a consumer portal.
XNU, or more specifically the Mach part of it, also had some very questionable design choices that likely compounds the issue as it forces people to work around it in increasingly awkward ways. As Mach was conceived and mostly designed by an academic with no real world industry experience in shipping kernels.
They did that later, but it is accurate to say that when Mach was first designed, Rick Rashid and others lacked "industry experience". However, they had a lot of practical experience making real systems for academic purposes. The CS departments at U of Rochester and CMU are serious about building stuff.
> To put this discussion into perspective, when it occurred in 1992, [...] many companies that are household names today--Netscape, Yahoo, Excite--simply did not exist.
None of this has to do with the Mach part of XNU. There are genuine bugs there (everyone hates the memory code for example) but again that is completely irrelevant here.
How do you know Mach wasn’t the cause of some workaround in the 90s, and that 5 workarounds in a row later it becomes harder to resolve this issue in 2024?
No, I won't. Your request is unreasonable. You posted a claim that is not true. This bug has nothing to do with the Mach layer of XNU, and the blog post has enough detail to explain why. When I call you out on that, you don't get to retreat to an absurd position and ask me to substantiate it: there's probably six degrees of separation between what I ate for breakfast and these bugs shipping. This is something that is basically impossible to falsify, but also deeply uninteresting. So I am not going to entertain it for you.
You can feel however you want about it but if you were to show up in a thread about GNOME security bugs and start talking about how Linux was designed by this random guy from Finland with no real experience which is why everything is so broken that’s really where people would stop taking you seriously.
You're missing the point. You made an unsubstantiated claim, and then you demanded an argument that it's impossible for your unsubstantiated claim to be true. I agree with the reply that this is a totally unreasonable demand.
The burden of proof is on you to provide evidence for your unsubstantiated claim. The burden is not on everyone else to disprove it.
It doesn’t matter who anyone believes the burden falls on… that’s my point.
Edit: If there’s no desire to write anything, there’s no force chaining your hands to the keyboard… and even if there was, no other user is obligated to do this or that.
Huh it does sound like that in retrospect, so I edited the comment to remove the offending sentence.
At the time of writing it was meant to be a rhetorical question, since it seemed extremely unlikely for there to have been any such argument or implication in the blog post referenced.
But my point still stands, it simply doesn’t matter because HN users can’t place any kind of mandatory obligations on one another.
The underlying reasons have to actually be written out though in the first place and viewable on a screen… I’m not a telepath, nor likely is anyone else.
And after all that has been demonstrated, along with some other necessary features such as logical consistency and so on, then it’s definitely more than an opinon.
> There's no security model for desktops that works well.
Don't you think that something which combines ideas from Firejail and Guix containers could be good enough?
For those who have not used Firejail, it is a sandbox that comes with default security profiles for most popular Linux binaries, so it's pretty unobtrusive. Say you want to run Firefox, Firejail limits access Firefox to ~/.mozilla and ~/Downloads by default. So, in case Firefox is compromised, attackers can't steal things from other $HOME directories like ~/.ssh.
On the other hand, Guix lets you launch ephemeral shells, like Nix, with any combination of packages. Unlike Nix, it provides a very convenient set of flags to sandbox the shell in terms of network, files, etc. This is handy for development tasks where you would like to have fine-grained capabilities.
Jails are fine and nice but always come in your way when you expect to do things as you would on a desktoo and you want a computer and not a software appliance like an iOS.
Just look at how many flatpaks are distributed with broad insecure access, how many workarounds have to be made with apps to work when reasonnably jailed, the presence of tools like flatseal.
Firejail uses "Linux container" technology (term?) which is not that secure. Better is using selinux to confine the browser, like Android and ChromeOS do.
(Fedora and Red Hat have selinux, too, but the focus is on server security: there is no attempt to confine browsers in the selinux rules that ship with Fedora and Red Hat.)
For me the interesting part of Firejail is the interface. bwrap is usually recommended as a replacement given that the binary is smaller and thus offers less attack surface, which I think is the usual concern. Firejail employs kernel user_namespaces, but also offers integration with AppArmor.
>On the other hand, when Telegram asks you to share all your contacts and images with it, people do.
This is where Android shines with storage and contacts scopes. You can share an empty scope with the app and it will stop bugging you, and have access to nothing!
Qubes has an excellent security model and should a top choice (if not _the_ top choice) for security-minded and technologically sophisticated users.
I used Qubes for a year or two, and then realized that my main use case was to isolated the browser, which to me was the greatest threat vector compared to everything else I use. Then I thought, if I just wanted a system with the browser isolated from my main Linux environment, wasn't that exactly what ChromeOS provided?
So I switched to ChromeOS and have stayed on it ever since.
The isolation in Qubes is much more reliable and flexible. I'm not even talking in Google's shady privacy practices. I'd never trust them with my OS or browser.
Seconded. Been daily driving it on ThinkPads now for something like two years. I will never go back, and one of the few things which might draw me off Qubes OS is if OpenBSD cleanroom reimplemented Qubes OS with their own OS and hypervisor. (OpenBSD because nobody beats their long term code quality and consistency.)
> quBSD is a FreeBSD jails/bhyve wrapper which implements a Qubes inspired containerization schema. Written in shell, based on zfs, and uses the underlying FreeBSD tools.
Not saying it'll do what you want, but the idea is out there...
> There's no security model for desktops that works well.
> Like another commenter said iOS has no legacy cruft and could deliver the security model that made sense.
Yeah I just was wondering about this. In the presentation also Seatbelt is mentioned, I thought this was considered deprecated legacy since years. IIRC the last time I checked for sandboxing I basically couldn't find anything recent for the Application level
Nice work.
I wonder whether we are on the right track with such architectures though. It seems with every security framework envisioned to combat some set of attacks, a whole new class of issues pop up. And I don't _feel_ like things are more secure in the end.
A bit like dutch tax law, it is just a stack of patches to fix exploits and it might have achieved consciousness already! ;)
Because many of these systems aren't designed end to end to be properly secure.
The right way to do it usually fails the market due to backwards compatibility or developer pushback to adopt such features (see WinRT sandbox).
Mobile phones security has it easier, because there wasn't backwards compatibility to care about, and so far the stores gatekeeping means that developers that want to play there have to oblige anyway.
That's not fair. The sandbox was not the reason for WinRT/UWP's failure in the market. It was the mostly unfinished tablet UI that they half ported from their phone and told developers that was the future. They even copied Apple and threw in some half-baked store with it. There was no way Microsoft was going to become successful at it, especially when Apple couldn't even get developers excited about their own implementation.
Most desktop software needs to provide value for customers, or they would just build the web version of it. Being "native" isn't enough.
So, if you want to require that us developers run our stuff inside of sandboxes, that's fine. Just make sure the sandbox doesn't prevent our software from getting access to the same important desktop surfaces.
Ultimately security is incompatible with backwards compatibility. All OSes in prod today need to be rebuilt from the ground up to be secure for the next century. That means throwing out a lot of code too. It's the cost to pay.
It’s not just power users either. Regular Windows users howled with outrage when they had to enter their password to permit software to do a privileged task.
Not necessarily “all the safeties off.” I’d define that as like, running as root always.
It’s more about not being locked out of actual admin access to my own computer.
I expect to have at minimum a developer mode that allows me to enter my password to allow me to run whatever code I want without OS vendor blessing. Heck, add a small coding challenge to unlock it. Whatever.
It kind of sounds like you're advocating the type of security where the computer is secure against its owner, can't be programmed by its owner, doesn't support modifications to the OS, and so on. Is that right, or so you envision a highly secure system that can be controlled by its owner?
Compartmentalization is only a part of the solution. Once you have that finished, you still need to deal with the actual vulnerabilities in guests, which will contain your secrets and be exposed to the internet, one way or another.
In what way are [1] not “full OSes”? They’re minimal templates, but afaik they still run systemd, the kernel, etc. needed to boot the standard Linux systems they are.
If you set it up, users can run anything themselves. Just use the start menu and the apps will automatically run in the corresponding VMs (shown as windows with colored borders).
I set up Qubes OS for and with technical, less-technical and non-technical people and I very much disagree. It only works well for those who are prepared and motivated to learn, and even then, it sometimes can be frustrating.
The copy-pasting between VMs, mentioned in a sibling, requires four steps: (1) copying to the source VM's clipboard, (2) copying to the global clipboard, (3) copying to the destination VM's clipboard, and (4) pasting to the destination. The shortcuts become part of your muscle memory after some use, but until they are, that is just one way in which Qubes gets in the way of productivity.
There are a bunch of minor quirks, often specific to the hardware, which the user needs to learn about and find workarounds for. But if they do, Qubes is probably the most seamless way to work with tons of (well-isolated) VMs. For example, SecureDrop [0] is based on Qubes and does seem to work well for journalists for securely receiving and working with documents from anonymous sources.
Everything that works on Linux will generally work on Qubes, apart from the GPU-heavy applications [0], which will be addressed in the future [1]. Copying and pasting works fine [2]. OK, music production may not be possible at the moment [3].
Can't comment on music production since I don't produce music (could be the need for realtime).
Discord runs fine both in-browser and in application. Raptor Lake seems to have zero issue with video voice chat, whereas Comet Lake can drag a bit in large rooms without a GPU. Qubes OS makes it dirt easy to multiprofile from all around the world.
I don't really game like others do; eye candy doesn't draw me in, but solving interesting puzzles/challenges does.
Copy & paste is superior in Qubes, skill issue sorry not-sorry. GIT GUD!
Funny that you should mention Dutch tax law. I don't think it's controversial to say that some of those "exploits" were deliberately inserted. One may speculate that there are also some powerful forces pushing for more vulnerabilities in consumer computing.
As long as I don't see you joining the usual "duh this is a government backdoor" crowd next time any bug comes up, sure.
This blog post describes a class of vulnerabilities. That's why there are ten of them. A well-resourced adversary with the capability to influence software development would want their backdoor to be small and difficult to discover. In many cases they would like guarantees that they are the only entity to be able to abuse such a vulnerability. While one can argue that these bugs were difficult to find–they were only fixed now–they really aren't very good backdoor bugs. Why leave dozens of holes all over the place when you only need a few? It's much more likely that this is just a failure case that someone failed to consider.
MacOS (ie NeXTstep) was built from the ground up to be an open and extremely extensible OS.
There were countless ways to add in some 3rd party extension or hook. Since there were multiple runtimes to access your software, it was actually an impressive technical feat at the time to have it all work together seamlessly.
Java, classic Mac, X11, and the NeXTstep codebases all ran together without issue due to several of the kernel's extensible entry-points.
On top of that, the platform had APIs that let apps talk to each other without issue.
However, little by little, Apple has backtracked on that philosophy and continues to close the system down. Quite a fascinating journey.
Impressive finds! As you allude to in your post, it seems very likely similar flaws still exist in the wild. I’d imagine we are going to see a consistent stream of XPC related CVEs unless Apple is redesigning its approach to hardening those services.
They're great second line of defence, but large organisations tend to reject fixing RCE when you are not able to escape sandbox and so anything meaningful, so they use them as main line of defense and that makes me sad.
> but large organisations tend to reject fixing RCE when you are not able to escape sandbox and so anything meaningful
Wait, who does this? AFAIK Apple, Microsoft and Google all have bug bounties which obviously offer bigger rewards for sandbox escape, but still pay something if you find a vulnerability which is blocked by the sandbox. They're all well aware that bad guys collect and store non-functional RCEs in the hopes of using them when a sandbox escape is found.
Depending on where it is in the product lifecycle, I've seen this extreme pushback against fixing symptomless bugs.
I was working on a project where someone thought to turn on tools for catching malloc errors (use past the end of allocated buffer, use after free &c.). The team that did this found bugs in their own code, of course, but also many from other teams.
I was there in the room as people went item-by-item litigating whether or not each bug should be fixed. Things like "sure this is use-after-free, but it's used immediately after the free and because of the struct offset, it can't corrupt the heap linked-list, so we won't fix it"
O/t but if any sandbox experts know of strategies to get around the maximum "pattern serialization length" limitation, this issue has been driving me nuts for quite a while: https://github.com/NixOS/nix/issues/4119
Unfortunately sandbox-exec isn't really documented (and supposedly deprecated?) so trying to sort this out is a bit of a headache.
There's an endless stream of bypasses on macOS, because the operating system was never designed for these granular permissions. You can't just add them later, on top of the legacy Mac OS and NeXTSTEP technologies.
I've found a number of bypasses myself, and I'm not even a security researcher, just a longtime app developer. I know where the bodies are buried, so to speak. However, I ultimately gave up looking, because Apple's security vulnerability reporting system is absolute trash; their only interest seems to be to keep you quiet for as long as possible. It's a waste of time.
My overall feeling is that macOS has become the victim of security theater, harming both users and legitimate developers with enfeedbled software and an endless stream of permissions requests—much like Apple's old parody of Windows Vista—while doing nothing to stop real attackers, who can easily bypass the security theater whenever they want.
The researcher who wrote this article seems to have been able to get a lot of holes patched with credits, albeit, some of these CVEs seem years old.
I guess a company wanting as much time as possible to fix bugs is a part of the game though, are other companies really keen for you to announce found vulns ASAP? They don't control how fast people upgrade so announcing slower is always better for end users, and that must ultimately take priority over the need of researchers for publicity. Isn't this something that one has to accept when finding holes in a consumer OS as an external?
The Apple sandbox architecture seems well designed to me, usually at least. There seems to have been some breakdown in architecture or communication in this case. To the extent there are bypasses it's because we demand a lot of functionality from desktop operating systems, arguably they are the most sophisticated and complex kind of operating system out there - far more so than server platforms. Web browsers also have a lot of CVEs and it's for the same reason. We want security, but also functionality, and inevitably there's going to be a tension point in the middle where the two rub up against each other.
> The researcher who wrote this article seems to have been able to get a lot of holes patched with credits, albeit, some of these CVEs seem years old.
Yes, it requires a lot of time and patience. And I bet that the researcher has more reported vulnerabilities that he can't talk about and aren't fixed. He's been doing this for many years.
> I guess a company wanting as much time as possible to fix bugs is a part of the game though, are other companies really keen for you to announce found vulns ASAP?
Apple is notorious for poor communication with security researchers... and with developers, and with everyone else. Apple also tends to patch vulnerabilities more slowly than, say, Google, and Apple frequently stiffs people on the security bounty.
> Apple frequently stiffs people on the security bounty.
Having seen the receiving end of a bounty program of a relatively small SaaS business it's shocking to see how many people are abusing such a program with irrelevant or plain false 'vulnerabilities' and keep begging for a bounty (even when it's clearly stated it's impossible to send money to their countries).
I can't imagine how many filters Apple has to employ to just get rid of the noise and get something of value from such a program.
Said researcher has expressed basically this exact concern fwiw. Just because they’re being paid on some bugs doesn’t mean their life is all sunshine and rainbows.
Google forces upgrades on people much more aggressively than Apple does though. None of their platforms let users opt out of upgrades except Android, which is also notorious for slow patching cycles (at least historically).
> You can't just add them later, on top of the legacy Mac OS and NeXTSTEP technologies.
Apple can (and has been) since it owns the whole stack, evidenced by the fact that they've been gradually hardening macOS software and hardware for two decades.
It's been gradual enough that most end users haven't noticed, but macOS developers are painfully aware of the security-related issues they have to reckon with in both major and minor updates to macOS. Example:
> Apple can (and has been) since it owns the whole stack, evidenced by the fact that they've been gradually hardening macOS software and hardware for two decades.
This is kind of an empty reply. Of course Apple can try and has been trying. The question is whether they can do it successfully, and I would argue it hasn't been successful.
> It's been gradual enough that most end users haven't noticed
This is not true at all. Users have definitely noticed all of the permissions dialogs and other related settings.
> The question is whether they can do it successfully, and I would argue it hasn't been successful.
Security has no finish line, unfortunately. But here are a few security-related things Sequoia has that Mac OS X 10.0 did not:
A firewall. VPN support. FileVault and FileVault 2. Secure Empty Trash. Increasingly-secure sandboxing. Library randomization. Address Space Layout Randomization. XProtect. Increasingly-secure versions of Gatekeeper. Increasingly-secure memory management. SIP. Kernel exploit mitigations. New update mechanisms for security patches. APFS and its associated security improvements. Notarization. Read-only system volume. Separation of user data and system files. Activation Lock. Improved system logging and auditing. Signed System Volume. Private Relay. Lockdown Mode. Visual indicators of mic/camera/location use. DriverKit to replace the use of kexts. Secure Enclave for hardware-based root of trust and secrets management.
I'm just someone who pays attention. I imagine actual security experts could list 20+ other improvements off the top of their head.
Every year I battle with a few permission related bugs in my app. Somehow macOS will randomly block some file accesses on some machines in some circumstances.
Take security scoped bookmarks. The only way that sandboxed apps can persistently access files outside their sandbox. It's an important feature. It's broken on some Macs. I know from logs that about 0.5% of my users run into this bug. It's been broken for years, and every time I report the problem to Apple they ask me for steps to reproduce or and Xcode sample project. I have no idea what to do, it's a bug in ScopedBookmarkAgent or in SecKeychain somewhere.
With Sequoia, they managed to break the feature for about 10% of users. That was apparently enough to get Apple to pay attention, so they fixed it in macOS 15.1. I think it's back to 0.5% now.
Somehow Apples own apps aren't affected by these bugs. Bugs that mostly affect 3rd party apps seem to slip through a lot more easily.
The security tech in macOS is unreliable garbage. And people praise it, they just think 3rd party apps are buggy. But for a lot of my bugs, the bug is in the macOS frameworks, but users come to me and complain.
It's no wonder that many developers don't sandbox their apps. It's just perpetually broken.
There's a global limit on the number of sandbox extensions (security scoped bookmarks) open at once. If it fails that's because someone is leaking them.
Hitting the sandbox extension limit is not necessarily a leak. There are a number of apps that deal with thousands of files at once and they will very quickly hit the limits. It's a perennial problem with anyone who makes professional, but sandboxed, software for macOS.
Yes, I should've said "can be". They are definitely difficult to manage. It doesn't help that people like to pass file paths or URLs across IPC and don't think of eg sending file descriptors over directly.
Hmm, who needs thousands of files at once (as opposed to serially)?
I beg your pardon. Apple's service revenue is very fortunate for the neverending excuse of security. Want third-party payment processors? It's not that it would upset our revenue stream, it's just too insecure. You want to sideload with the flick of a switch? It's not like we already offer that feature to other users of our products and paying developers, it's not secure enough to attempt. Want an open bootloader for your iPhone like those Apple Silicon Macs? It's not that Apple can't do it, it's just that they claim it's not secure enough.
The real kicker? None of us have a privileged enough view of the ecosystem to even know if Apple is right or not. The fact that security has no finish line should be carefully construed as not to excuse companies that move the goalposts of security for petty means. Apple is grateful that customers will accept "security" as a carte-blanche answer to completely unrelated topics.
A number of those are security theater, and some of them aren't even for security at all. Also, the secure empty trash feature was actually removed from macOS, and I'm not sure what you mean by the "associated security improvements" of APFS.
But it's not even a question of whether security has a "finish line". The question is whether a specific security feature works on not, and some of them just don't work.
I think this legacy is a burden in all mainstream operating systems? There are capability-based system, but none of them have any traction.
I am not sure what the solution is. Trying to bolt on security still seems better than doing nothing at all, where an application vulnerability immediately means a compromise of the a full user account?
SELinux can be part of the solution but it doesn’t solve the problem. The median Linux system is far behind the median Mac because while SELinux exists you still have to craft fine-grained policies and deal with all of the exceptions needed to have the system still be usable. This is more a function of budget than anything else.
>> SELinux can be part of the solution but it doesn’t solve the problem
Hold on that’s changing the goalposts a bit here. SELinux doesn’t solve this problem on RHEL boxes by virtue of just existing. It is the tool that Redhat uses to solve the problem. And they have solved the problem by using this tool. To the point that for years now, by default, RH boxes are installed in enforcing mode.
>> The median Linux system is far behind the median Mac
I’m not really interested in the median because for better or worse, Redhat is the most serious game in town for SELinux. Comparing Mac to RHEL, there’s only one place where Mac is ahead and that is a default Mac install at least on Apple silicon will have an immutable root. Redhat has irons in the fire here (rpm ostree can infuturue unlock a user friendly immutable root). Of course you can do immutable root today (and immutable usr and even epehemeral var if you want), but I’m not going to argue those are user friendly. An experienced sysadmin will take a minute to flip over between immutable root file systems during an upgrade process.
>> This is more a function of budget than anything else.
Agreed, but the Apple chequebook looks plenty beefy.
> And they have solved the problem by using this tool. To the point that for years now, by default, RH boxes are installed in enforcing mode.
They’ve shipped it, yes. It doesn’t count as solved until all of the apps are running with policies which actually block attacks like this, just as having a fire extinguisher on the shelf doesn’t mean your fire is guaranteed to be out.
> Comparing Mac to RHEL, there’s only one place where Mac is ahead and that is a default Mac install at least on Apple silicon will have an immutable root.
Also they have far more common use of sandboxing for applications (including the harder bits about selective permissions for apps), code signing, memory protection, pervasive use of HSM and robust layered storage encryption, etc. – all out of the box, whereas even in the much easier case of servers you’re looking at many hours of skilled labor to configure an equivalent.
My point about budgets is that this is just a lot of work. Apple’s not perfect but a lot of people have a mental model from the 2000s which is no longer true.
>Redhat is the most serious game in town for SELinux
SELinux on Red Hat only confines web servers, DNS servers and such. All software started by an interactive user, including web browsers, runs in the "unconfined" domain (term?), which means SELinux is not even trying to contain that software.
ChromeOS OTOH does use selinux to sandbox the browser (and IIUC Android uses it to sandbox every app).
>Comparing Mac to RHEL, there’s only one place where Mac is ahead
That's not my understanding: Mac is far from perfect, but it is more secure overall than RHEL and Fedora IMO. It's not just that the Mac verifies the integrity of /usr and such whereas Linux distros do not.
Agreed, I’m not suggesting selinux itself is the solution for Apple. I’m just saying faced with the same problem, and accepting that they have different usability constraints on them (sysadmins vs potentially novice computer users), another group found a solution. Why can’t Apple - they have the money to buy the engineering resource to bottom this out.
Usability is apple’s thing. My AirPods just work, every Bluetooth headset before just annoyed. Why can’t they achieve usability in this space? To be honest, redhat’s solution is pretty darned usable - in the context of an enterprise Linux box(1). it helps that they built that database of policy profiles but even creating my own policy is pretty straightforward (3 commands + whatever it takes to make my app exercise all its code paths)
My Grandma doesn't have a need for backwards compatibility or the million other things that stop Apple from just making a new operating system.
Normal people's use cases for their computer is light file management, light document and productivity workflows and everything else is done in the browser. Hell, most of the document processing and productivity crap is in the browser these days too.
This is the real answer - 90% of people can use a phone or an iPad for their general computational needs - and the PC/Mac itself will trend toward that, with harder and harder gates to bypass to get a truly "general" computer.
Same for Windows' UAC in the Vista era, which doesn't make it bad technology or place the fault on Microsoft. The world is full of terrible development practices, the answer shouldn't be "just disable your security mechanisms".
That's rather self critical of you, even if deserved.
My grandma also can't write software, or really do anything advanced, no should she be able to. SELinux, just like any other security and/or containerization technology, is supposed to be used by developers, sysadmins, distribution maintainers. Not by end users.
Is the macos sandbox the odd one out? I'm not familiar with it, but find it very hard to believe that "my grandma" is its target audience.
You can't compare Android to macOS. Compare Android to iOS, which had many more limitations built-in from the start than macOS.
Incidentally, this is why iPad has never become the desktop replacement everyone claimed it would be. The hardware is plenty powerful, but it's always been very limited by the software. The greater freedom and capabilities of macOS is a huge advantage for desktop-class functionality.
I think I disagree. If iOS or Android added robust support for external monitors, external keyboards and pointing devices, I'd probably switch to it to get the increased resistance against attacks.
If I could continue to run Emacs, e.g., in a VM like WSL2 or Crostini, I'd probably switch right away. If not, it would take me a year or 2 to transition to a replacement before I switch (and, no, that replacement would not need to be able to run software written in Emacs Lisp: I'd be happy to replace, rewrite or walk away from any functionality I currently get from code written in Emacs Lisp).
I use Linux, I would not switch to Android, but I agree the Linux userland should take sandboxing much more seriously. Things like Firejail show it can be done without much friction for the user.
The current model, where executables can access any user file or resource, needs to go. We haven't learned anything from e.g. compromised pip packages that stole ssh keys.
> If iOS or Android added robust support for external monitors, external keyboards and pointing devices, I'd probably switch to it to get the increased resistance against attacks.
They basically do now?
On iOS I've never seen a BT keyboard not pair and I've never had problems with external monitors. Sometimes getting the right dongle so it plugs in is the bigger problem, but iPads have been USB-C for a while now, making it pretty much a non-issue, whenever I've tried.
I haven't tried with Android in a while, but I'd be surprised if it's much different than iOS at this point in time.
Can iPadOS display a UI tailored to the native resolution of the external monitor such that the user need never interact with the iPad's own display?
Is using a mouse with Mobile Safari a pleasant experience if the user is doing many hours of interaction that way?
(Actually, now that I think about it, iPadOS is too restrictive for me: I can't configure it in ways I would want to, but GrapheneOS doesn't have that problem what with being almost entirely open-source.)
> Can iPadOS display a UI tailored to the native resolution of the external monitor such that the user need never interact with the iPad's own display?
Well, since the iPad display is also the touchpad, you probably don't want to never interact with the iPad display. But essentially yes. Some TV's have a worse time than others. iPad's can't control what the TV can handle. In general, I've never had big problems, though I don't use it for 8hr work sessions.
> Is using a mouse with Mobile Safari a pleasant experience if the user is doing many hours of interaction that way?
Nobody can tell you if what they have implemented now, works well enough for you. I use it regularly, it works great.
> (Actually, now that I think about it, iPadOS is too restrictive for me: I can't configure it in ways I would want to, but GrapheneOS doesn't have that problem what with being almost entirely open-source.)
backing out already?! :) Seriously though, you are not alone. iPadOS is restrictive, that is either a bonus or a curse. It does let you focus more on tasks, but it limits how you are used to working in ways that might be hard to handle(especially at first).
I agree about GrapheneOS.
As for emacs, you can run it under iSH on iPadOS. I can't tell you how well it works, since I don't use emacs.
Thanks for the info, especially your "I use it regularly, it works great."
>iPadOS is restrictive, that is either a bonus or a curse. It does let you focus more on tasks
I used to compress my browser's executable as a way of "disabling" it. That stopped working smoothly after MacOS locked down the /Applications directory, but I found other ways to disable my browser: on Gnome now, I wrote a command that is easy to invoke and that removes browsers from "the Dash" (Gnome's analog to the Dock). (The command is implemented with `gsettings set org.gnome.shell favorite-apps`.)
Note that this method of "disabling" the browser does not prevent me from starting the browser with a command line entered into a terminal window, but it does stop me from starting the browser in a way that requires no thinking from me (i.e., the way I habitually do it) which turns out to be enough to prevent me from wasting time in the browser.
Being able to easily "disable" the browser (or more precisely, to easily arrange it so that I need to think in order to switch to a browser window) has significantly reduced the amount of time I waste online. Of course, there are times when some pressing task requires use of a web browser (which might coincide with one of the times when my ability to resist the temptation to waste time on the web is low) but in my life, those times are rare.
Yes, iPadOS offers a way to disable Safari, too, but the difference is that doing it on iPadOS requires many steps, and it hard for me to muster the self-discipline to go through the steps after I've noticed my ability to stay focused has gotten so low that I should disable my browser: the steps are this: go to Settings > Screen Time > content & privacy restrictions. Toggle on the button at the top of the pane. Enter a 4-digit passcode.
There is no way for me to customize my iPad to make it easier for me to disable Safari.
This relative lack of customizability is why I would hesitate to try to rely on iPadOS for productivity. (Currently my iPad is almost entirely an entertainment and distraction device. When I need to be productive and feel that my ability to resist the temptation to waste time on it is low, I can and do move my iPad to another room.)
Android does have support for external keyboards and I know mice work but not the totality of pointing devices. There was a desktop experience with Samsung's DeX, complete with floating windows, but the experience was severely broken due to lackluster app support and clashing design priorities between touch and mouse.
Thing is that Android is probably no more secure than a standard desktop experience specifically due to the very uncontained Play Store, the prevalence of sideloading apps and rooting doesn't really help at all.
> Thing is that Android is probably no more secure than a standard desktop experience specifically due to the very uncontained Play Store, the prevalence of sideloading apps and rooting doesn't really help at all.
This is completely untrue. There is lot more to OS security than where software can be downloaded from. The point about root and sideloading is completely missing the point as those are even worse on desktop operating systems. On desktops you can basically run whatever from wherever and there is usually no sandboxing at all. On Android, there is a strict sandbox and you can't run whatever you want. Android is not rooted by default.
Every app is strictly sandboxed on Android, point me to a desktop OS that has anything close to that. Every process is confined using SELinux policies on Android, which desktop OS has as strict MAC setup? Android has a proper, working verified boot, which desktop OS has something similar? Not to mention all the other hardening and exploit mitigations that are usually completely missing from standard desktop operating systems.
Responsible disclosure is immediate public disclosure with no embargoes. Embargoes are how we as users are absorbing the costs of poor security practices. If the culture was a no-warning publish culture, I would expect feature iteration and API breaks to slow down to more conservative levels as bikeshedding that stuff dwindles.
Punish fast software development iteration with public embarrassment and lost users who got hosed by the vulnerability. If Apple or whoever start dicking around and not paying bounties, release it... or better yet: sell it on the darknet; you have got to be paid for your good work, and NSA/NSO are going to need more 0-day vulnerabilities with WWIII underway!
those overlooked xpc services in the pid domain are a clever way to bypass sandbox limits on macos. that dyld injection trick to dodge entitlement checks is slick. apple’s patching here feels kinda bandaid-y—maybe they need a real overhaul on how sandbox inheritence works?
Mostly, it just gets you to a non-sandboxed state. However, I do seem to recall vaguely one issue I saw where escaping the sandbox got you a higher privileged state, I think because of a bug in the kernel logic that enforces the sandbox.
This is, unfortunately, the sort of thing that motivates QubesOS. We are, as humans writing code, not good at complexity, and as Apple's lockdown mode admits, parsing complicated stuff, even when you design security boundaries around it, is hard to do properly. Lockdown just punts a ton of complexity entirely out of the system, and the tradeoff is rather substantially improved security against a wide class of attacks.
QubesOS design philosophy is essentially, "Everything in a booted OS image must be assumed to be able to, some way or another, access everything else in there." So you have various silos that have extremely limited communication between them (you can "push" from one VM to another, but you can never "pull" from another VM, the framebuffer is simple, etc). You're totally free to add sandboxing as useful, but it's not considered a full security boundary. Hardware virtualized VMs are, on a fairly stripped down Xen that removes a lot of attack surface in terms of legacy device emulation and other features they don't need.
Apple has done a lot of security focused improvements over the years, but modern computers and OSes are just so complicated that even they struggle to get it right regularly. And the attackers only need one mistake to achieve their goals. :(
//EDIT: As far as practicality goes, I do daily drive QubesOS as my main computer on a 2C/4T laptop with 16GB RAM - old X250. There are plenty of things it's not great at, but I'm not heavy on the "videos or video games" thing anyway. Dual booting for gaming is an option, as is a separate desktop that doesn't do anything important for gaming, but you don't need some monster machine to do practical things with Qubes. I can't have a thousand browser tabs open, but I don't do that anyway, I browse "JITless" (disable Javascript JIT as it's a ton of attack surface that's regularly exploited), and... it's a less-intense form of computer use than standard, but it also means I don't have a desire to spend all my time on a computer.
I argue never dual-boot Qubes [with it installed on an internal drive] because Windows can [theoretically] read those partitions. Better to just get a separate application-specific system for gaming.
I daily drive Qubes on i7 Comet and Raptor Lakes, 64GB and 128GB RAM respectively. I run LLMs on their GTX and RTX cards (albeit slowly on the Comet Lake/GTX system). Digital crac... err gaming is the only thing I am pretty well locked out from.
It really depends on your threat modeling and what you're concerned about. I agree, dual booting isn't ideal, but also, "dual booting Qubes and Ubuntu for gaming" cannot be any worse than "simply running everything on Ubuntu," as long as you don't believe Qubes is impervious to anything nasty in that configuration.
The main storage partitions are encrypted for Qubes (... or had better be, I guess you could avoid that, but why?), so the dual booting attack path would have to be through the boot partition, load something that can then compromise the install. It's a fairly specific sort of attack that, if someone's coming after you with that, it's probably a question of "How and when you're screwed, not if." But for general users, I think dual booting is an acceptable compromise. Just don't do much of anything in the other install!
I dual boot my laptop. There are a handful of things that are far easier to do in Ubuntu than Qubes (movies on a long flight, run a Windows VM to run particular software to talk to cars, and Minecraft for LAN parties). I'm aware of the risks, and don't consider them to be enough to remove the ability to do a few other things on one machine. I try not to have too large of piles of single purpose computers these days...
For me, everything important I have could be accessed from browser(as I do full system backup) and the cookie I have in browser could allow the app to access my data. How does QubesOS help in this scenario?
I write code, yes. I'll just spin up a development VM as needed, things work fine. I don't use Docker, but as long as you're not using the hardware virtualized modes, it should work just fine on namespaces. Every VM is running a full featured Linux kernel. There's just not nested virtualization support, which I'm totally fine with, because nested virtualization on x86 is a rather complex mess to get right.
The main thing you lose is GPU acceleration. I don't particularly care.
Let us simplify our IT layers and stacks before it is too late.
It's time to introspect and ask those critical questions: Is it really necessary to install each one of these apps, every single one of these libraries and frameworks? How can I remove dependencies from these libs and do a little core work myself? And tell the same thing to your partners, colleagues, coworkers, etc. If you find 4-5 apps doing basically the same thing (like communication or productivity tool), see if you can consolidate them into one.
> If you find 4-5 apps doing basically the same thing (like communication or productivity tool), see if you can consolidate them into one.
If I could get all of my friends to switch to one communication app, that would be great, but that's only going to happen if they can get their friends to switch, and so on. Unfortunately, doing so requires them to install additional apps for communication, and no one can get everyone they talk to to switch, so they're just going to have more people on one app than another and in the end the problem gets worse.
Matrix bridges solve a lot of this problem, though... aren't really reducing complexity at all ends of the system. It does radically reduce end user app complexity, though.
I've been hosting a Matrix homeserver for... oh, 4-5 years, now, and I have bridges installed for my use and a few other people who use it that bridge Signal, Google Chat, Facebook Messenger, and maybe one or two other services into Matrix - so I almost never have to bother with the other clients, I just use a Matrix client everywhere. There are the occasional quirks you have to deal with, most of which are solved by upgrading your bridge (and the new bridges are a lot easier to deal with than the older ones).
As people decide to go Matrix-native, I can talk to them that way as well.
That said, as far as non-Matrix options go, Signal seems to be a fairly common one and easy enough to get people to switch to.
https://docs.mau.fi/bridges/go/setup.html?bridge=signal is the setup for the Signal bridge, and you'll also need to look at the initial config setup. Once you have a working Matrix homeserver, it's mostly "Create a new database table, point the bridge at it, add the proper incantations to your homeserver config so it knows the bridge is permitted, and start things up."
I don't find it bad in the slightest, but I'm also a legacy Linux sysadmin sort.
If you're a GUI-only sort, it will be painful. If you're competent with older styles of Linux sysadmin, it's fairly straightforward, though getting Matrix federation working reliably can be a slight pain. Just make sure your certs update...
Alright that doesn’t look too bad at all. I’m not at the level of sysadmin, but I do daily drive Debian and generally know my way around a terminal. I’ll give it a shot!
Maybe it's time Apple admit that maybe next-gen AV has a place on the Mac platform, and not rely on the current model of hope and good vibes to mitigate new attacks. This includes not allowing their community moderators to continue to gaslight customers into thinking all security software is bad and that their OS is invincible with 2000s-era propaganda on their support forums.
> According to Apple, “CVEs are only assigned to software vulnerabilities previously released to production and not to vulnerabilities for beta-only software.” This vulnerability only affects the macOS Sonoma Beta version.
IOW it's a fascinating read into security research and macOS architecture, but only pertains to a beta release of the previous major version.
(edit: I stand corrected, there's multiple vulns as TFA's very title says, and some may still be pertinent)
It's a bit odd that the response here is to patch every single XPC service individually. This feels like some kind of design issue in the sandbox itself. Why are so many XPC services that are clearly intended to be app private reachable from sandboxed apps?
Yep, it is the most likely the compromise to retrofit this into macOS, without breaking everything in UNIX and NeXTSTEP land that has been ported into macOS.
On Windows land you have something similar, there is the WinRT sandbox, Win32 app sandbox, secure kernel, driver guard, and a miriad of other stuff, but there are also the cracks of backwards compatibility, specially if you want a single executable able to run across all those configurations.
Mobile OSes have it easier, because of no backwards compatibility and the restrictions that are able to impose as execution model.
No, it has nothing in to do with NeXTSTEP. XPC was designed recently and for macOS/iOS. This is just that it was not designed with security in mind along this axis.
XPC has been in shipping platforms for more than 13 years... I suppose that is recent compared to NEXTstep :)
That is the thing, the OS architecture wasn't revamped across the board, XPC became another little island how to do IPC.
It's definitely a big island on Darwin
> On Windows land you have something similar
I'm still waiting to hear about a kernel-level exploit that starts with Visicalc or similar.
Windows has far worse. Injecting code into other processes is routine and almost impossible to get rid of.
Readers here are all very likely to appreciate some links alongside statements, cause really this is a sensitive topic. Both statements need certain context as it seems it’s not the universal understanding of what goes on and how often.
Not sure it can be proven with citations but it's well known that process injection is widely used on Windows. GPU drivers are known to do it. Utilities have historically often injected code into Explorer. Raymond Chen has written in the past about this problem and how hard it made it to evolve the platform.
> Raymond Chen has written in the past about this problem
That would be a citation. Do you have a link?
Three random Explorer examples:
https://devblogs.microsoft.com/oldnewthing/20230911-00/?p=10...
https://devblogs.microsoft.com/oldnewthing/20230324-00/?p=10...
https://devblogs.microsoft.com/oldnewthing/20220613-00/?p=10...
For code injection into applications that don't load third-party DLLs as plugins, see, e.g., Microsoft's (unsupported) toolkit for runtime API interception:
https://github.com/microsoft/Detours
You install tortoiseSVN or something similar, look at explorer.exe process or any process that use a standard "Open File" widget, and you will see some dll from the utility loaded by the process. (Easy to see with process explorer from sysinternals)
I think tortoiseSVN and consorts are "just" a shell extension, though, which is an officially supported concept, even if that means that potentially any random software using the standard file dialogues ends up loading your DLL, too.
SetWindowsHookEx is a blast.
I've never heard of that from store apps
The store which doesn't even provide one of the most useful Microsoft product (Visual Studio)?
Yeah. That really doesn’t need to be from the store.
I really hate going through the Apple Store to download Xcode. We all know how to download software. I’d rather go through a dev portal than a consumer portal.
YMMV
Command line: https://github.com/XcodesOrg/xcodes
GUI: https://github.com/XcodesOrg/XcodesApp
Xcode can be downloaded from developer.apple.com too, it's not an App Store exclusive.
> I’d rather go through a dev portal than a consumer portal.
You actually can, alongside with conmand line tools, additional xcode utils, debug kernels et cetera.
Visicalc doesn't run on recent versions of Windows without emulation.
I guess it is a form of emulation... but
You can run 16-bit Windows (Windows 1.x, 2.x, 3.0, 3.1, etc.) on 64-bit Windows with https://github.com/otya128/winevdm
I got Microsoft Encarta 98 to work on Windows 11 this way
Encarta 98 has to be 32 bit... Win16 was pretty dead for new products by that time.
Though it's conceivable that an installer could start off with 16 bit code to show an error message that you need Windows 95 ...
Edit: it seems Encarta 95 could run on win16, but Encarta 98 required win95 or nt4
XNU, or more specifically the Mach part of it, also had some very questionable design choices that likely compounds the issue as it forces people to work around it in increasingly awkward ways. As Mach was conceived and mostly designed by an academic with no real world industry experience in shipping kernels.
> As Mach was conceived and mostly designed by an academic with no real world industry experience in shipping kernels.
You may be thinking of Andrew S. Tanenbaum, who created MINIX, and was famously blasted by Linus for not having industry experience.
Mach was written by guys who ended leading Microsoft Reaearch and software development at Apple.
They did that later, but it is accurate to say that when Mach was first designed, Rick Rashid and others lacked "industry experience". However, they had a lot of practical experience making real systems for academic purposes. The CS departments at U of Rochester and CMU are serious about building stuff.
>was famously blasted by Linus for not having industry experience.
I answered my own question (where to read more about this), and found the relevant information from https://www.oreilly.com/openbook/opensources/book/appa.html
> To put this discussion into perspective, when it occurred in 1992, [...] many companies that are household names today--Netscape, Yahoo, Excite--simply did not exist.
That sure has aged interestingly since 1999.
This is a fantastic read, thanks for linking it. Linus's pragmatic approach really comes to the fore.
None of this has to do with the Mach part of XNU. There are genuine bugs there (everyone hates the memory code for example) but again that is completely irrelevant here.
How do you know Mach wasn’t the cause of some workaround in the 90s, and that 5 workarounds in a row later it becomes harder to resolve this issue in 2024?
Because I read the blog post.
So can you actually write the argument here?
That supposedly proves it’s impossible for A to have affected B… even with 6 degrees of seperation…
No, I won't. Your request is unreasonable. You posted a claim that is not true. This bug has nothing to do with the Mach layer of XNU, and the blog post has enough detail to explain why. When I call you out on that, you don't get to retreat to an absurd position and ask me to substantiate it: there's probably six degrees of separation between what I ate for breakfast and these bugs shipping. This is something that is basically impossible to falsify, but also deeply uninteresting. So I am not going to entertain it for you.
Your opinions can’t ever outweigh my opinions, or any other HN user’s opinions for that matter, so this adds nothing to the conversation.
You can feel however you want about it but if you were to show up in a thread about GNOME security bugs and start talking about how Linux was designed by this random guy from Finland with no real experience which is why everything is so broken that’s really where people would stop taking you seriously.
Therefore…? Is there some other point your trying to prove?
You're missing the point. You made an unsubstantiated claim, and then you demanded an argument that it's impossible for your unsubstantiated claim to be true. I agree with the reply that this is a totally unreasonable demand.
The burden of proof is on you to provide evidence for your unsubstantiated claim. The burden is not on everyone else to disprove it.
It doesn’t matter who anyone believes the burden falls on… that’s my point.
Edit: If there’s no desire to write anything, there’s no force chaining your hands to the keyboard… and even if there was, no other user is obligated to do this or that.
> I’m not requesting anyone to reply to me nor prove anything to me
I mean... everyone can see that this claim is false. Earlier:
> So can you actually write the argument here?
> That supposedly proves it’s impossible for A to have affected B… even with 6 degrees of seperation…
That was a request for a reply and a proof.
Of course nobody has to accede to your request, but it's undeniable that you made a request.
Huh it does sound like that in retrospect, so I edited the comment to remove the offending sentence.
At the time of writing it was meant to be a rhetorical question, since it seemed extremely unlikely for there to have been any such argument or implication in the blog post referenced.
But my point still stands, it simply doesn’t matter because HN users can’t place any kind of mandatory obligations on one another.
Not true: opinions carry the weight of their underlying reasons. Not all opinions are equally supported.
The underlying reasons have to actually be written out though in the first place and viewable on a screen… I’m not a telepath, nor likely is anyone else.
And after all that has been demonstrated, along with some other necessary features such as logical consistency and so on, then it’s definitely more than an opinon.
Really? I remember Bertrand Serlet or maybe it was Avie himself, taking pride in that.
I think both of them left before XPC shipped.
MacOS should really have some kind of capabilities based Darwin containers, rather than what seems like a giant tangle of blacklists.
https://github.com/darwin-containers
https://news.ycombinator.com/item?id=37655477
There's no security model for desktops that works well.
Like another commenter said iOS has no legacy cruft and could deliver the security model that made sense.
On the other hand, when Telegram asks you to share all your contacts and images with it, people do.
I like ChromeOS' security model: Nail everything shut, but leave a Linux VM as a escape hatch.
> There's no security model for desktops that works well.
Don't you think that something which combines ideas from Firejail and Guix containers could be good enough?
For those who have not used Firejail, it is a sandbox that comes with default security profiles for most popular Linux binaries, so it's pretty unobtrusive. Say you want to run Firefox, Firejail limits access Firefox to ~/.mozilla and ~/Downloads by default. So, in case Firefox is compromised, attackers can't steal things from other $HOME directories like ~/.ssh.
On the other hand, Guix lets you launch ephemeral shells, like Nix, with any combination of packages. Unlike Nix, it provides a very convenient set of flags to sandbox the shell in terms of network, files, etc. This is handy for development tasks where you would like to have fine-grained capabilities.
Jails are fine and nice but always come in your way when you expect to do things as you would on a desktoo and you want a computer and not a software appliance like an iOS.
Just look at how many flatpaks are distributed with broad insecure access, how many workarounds have to be made with apps to work when reasonnably jailed, the presence of tools like flatseal.
Firejail uses "Linux container" technology (term?) which is not that secure. Better is using selinux to confine the browser, like Android and ChromeOS do.
(Fedora and Red Hat have selinux, too, but the focus is on server security: there is no attempt to confine browsers in the selinux rules that ship with Fedora and Red Hat.)
For me the interesting part of Firejail is the interface. bwrap is usually recommended as a replacement given that the binary is smaller and thus offers less attack surface, which I think is the usual concern. Firejail employs kernel user_namespaces, but also offers integration with AppArmor.
>the binary is smaller and thus offers less attack surface, which I think is the usual concern.
Another concern is the huge attack surface that is the Linux kernel.
Firejail attempts to mitigate that with secomp filters.
>On the other hand, when Telegram asks you to share all your contacts and images with it, people do.
This is where Android shines with storage and contacts scopes. You can share an empty scope with the app and it will stop bugging you, and have access to nothing!
Can you help me find this? I don't see anything by googling "android contacts scopes" or looking in the contacts settings.
It may be a GrapheneOS exclusive feature: https://grapheneos.org/usage#contact-scopes
There is a similar option in iOS, where you give an app access to select items only.
> There's no security model for desktops that works well.
Qubes OS works quite well, if you need security on desktop.
Qubes has an excellent security model and should a top choice (if not _the_ top choice) for security-minded and technologically sophisticated users.
I used Qubes for a year or two, and then realized that my main use case was to isolated the browser, which to me was the greatest threat vector compared to everything else I use. Then I thought, if I just wanted a system with the browser isolated from my main Linux environment, wasn't that exactly what ChromeOS provided?
So I switched to ChromeOS and have stayed on it ever since.
> wasn't that exactly what ChromeOS provided
The isolation in Qubes is much more reliable and flexible. I'm not even talking in Google's shady privacy practices. I'd never trust them with my OS or browser.
Seconded. Been daily driving it on ThinkPads now for something like two years. I will never go back, and one of the few things which might draw me off Qubes OS is if OpenBSD cleanroom reimplemented Qubes OS with their own OS and hypervisor. (OpenBSD because nobody beats their long term code quality and consistency.)
Not OpenBSD but FreeBSD: https://github.com/BawdyAnarchist/quBSD
> quBSD is a FreeBSD jails/bhyve wrapper which implements a Qubes inspired containerization schema. Written in shell, based on zfs, and uses the underlying FreeBSD tools.
Not saying it'll do what you want, but the idea is out there...
OpenBSD can run as a Xen guest, so it should work as a QubesOS VM.
> There's no security model for desktops that works well.
> Like another commenter said iOS has no legacy cruft and could deliver the security model that made sense.
Yeah I just was wondering about this. In the presentation also Seatbelt is mentioned, I thought this was considered deprecated legacy since years. IIRC the last time I checked for sandboxing I basically couldn't find anything recent for the Application level
Nice work. I wonder whether we are on the right track with such architectures though. It seems with every security framework envisioned to combat some set of attacks, a whole new class of issues pop up. And I don't _feel_ like things are more secure in the end. A bit like dutch tax law, it is just a stack of patches to fix exploits and it might have achieved consciousness already! ;)
Because many of these systems aren't designed end to end to be properly secure.
The right way to do it usually fails the market due to backwards compatibility or developer pushback to adopt such features (see WinRT sandbox).
Mobile phones security has it easier, because there wasn't backwards compatibility to care about, and so far the stores gatekeeping means that developers that want to play there have to oblige anyway.
That's not fair. The sandbox was not the reason for WinRT/UWP's failure in the market. It was the mostly unfinished tablet UI that they half ported from their phone and told developers that was the future. They even copied Apple and threw in some half-baked store with it. There was no way Microsoft was going to become successful at it, especially when Apple couldn't even get developers excited about their own implementation.
Most desktop software needs to provide value for customers, or they would just build the web version of it. Being "native" isn't enough.
So, if you want to require that us developers run our stuff inside of sandboxes, that's fine. Just make sure the sandbox doesn't prevent our software from getting access to the same important desktop surfaces.
windows had an app store back in vista days.
> developers that want to play there
That pun was superb btw
Ultimately security is incompatible with backwards compatibility. All OSes in prod today need to be rebuilt from the ground up to be secure for the next century. That means throwing out a lot of code too. It's the cost to pay.
> That means throwing out a lot of code too. It's the cost to pay.
And likely, upsetting power users who want to run with all the safeties off.
It’s not just power users either. Regular Windows users howled with outrage when they had to enter their password to permit software to do a privileged task.
Not necessarily “all the safeties off.” I’d define that as like, running as root always.
It’s more about not being locked out of actual admin access to my own computer.
I expect to have at minimum a developer mode that allows me to enter my password to allow me to run whatever code I want without OS vendor blessing. Heck, add a small coding challenge to unlock it. Whatever.
Also, users who actually want to get shit done.
It kind of sounds like you're advocating the type of security where the computer is secure against its owner, can't be programmed by its owner, doesn't support modifications to the OS, and so on. Is that right, or so you envision a highly secure system that can be controlled by its owner?
> All OSes in prod today need to be rebuilt from the ground up to be secure for the next century
Qubes OS solves this with hardware virtualization, which is really fast and secure.
Compartmentalization is only a part of the solution. Once you have that finished, you still need to deal with the actual vulnerabilities in guests, which will contain your secrets and be exposed to the internet, one way or another.
Guests don't have to be exposed to the Internet [0] or even run full OSes [1].
[0] https://www.qubes-os.org/doc/how-to-organize-your-qubes/
[1] https://www.qubes-os.org/doc/templates/minimal/
In what way are [1] not “full OSes”? They’re minimal templates, but afaik they still run systemd, the kernel, etc. needed to boot the standard Linux systems they are.
When I clicked the link I was expecting something like a unikernel, eg https://roscidus.com/blog/blog/2016/01/01/a-unikernel-firewa...
You certainly can run distros without systemd [0] or something very different like *BSD or Mirage [2].
[0] https://forum.qubes-os.org/t/devuan-or-other-non-systemd-tem...
https://forum.qubes-os.org/t/alpine-linux-template-non-offic...
[1] https://forum.qubes-os.org/t/openbsd-as-a-ubes-os-component/...
[2] https://forum.qubes-os.org/t/mirage-firewall-0-9-0-released/...
> You certainly can run distros without systemd
Does it then become not a full OS anymore? Mirage is what I linked to above.
> Does it then become not a full OS anymore?
Probably not. I mentioned it, because you mentioned systemd. And yes, I saw your Mirage link and showed how you can use it on Qubes.
Qubes is nigh impossible for normal users, even if setup for them. They need extension training and discipline.
If you set it up, users can run anything themselves. Just use the start menu and the apps will automatically run in the corresponding VMs (shown as windows with colored borders).
I set up Qubes OS for and with technical, less-technical and non-technical people and I very much disagree. It only works well for those who are prepared and motivated to learn, and even then, it sometimes can be frustrating.
The copy-pasting between VMs, mentioned in a sibling, requires four steps: (1) copying to the source VM's clipboard, (2) copying to the global clipboard, (3) copying to the destination VM's clipboard, and (4) pasting to the destination. The shortcuts become part of your muscle memory after some use, but until they are, that is just one way in which Qubes gets in the way of productivity.
There are a bunch of minor quirks, often specific to the hardware, which the user needs to learn about and find workarounds for. But if they do, Qubes is probably the most seamless way to work with tons of (well-isolated) VMs. For example, SecureDrop [0] is based on Qubes and does seem to work well for journalists for securely receiving and working with documents from anonymous sources.
[0]: https://securedrop.org/
> and I very much disagree
> The shortcuts become part of your muscle memory after some use
So you agree that it's doable, just that it requires a bit more effort. It's definitely true.
> bunch of minor quirks, often specific to the hardware
Which is why there is a list of recommended hardware: https://forum.qubes-os.org/t/community-recommended-computers...
Anything, except for practical applications that people actually use.
* music production software * discord * games * copy and pasting
Everything that works on Linux will generally work on Qubes, apart from the GPU-heavy applications [0], which will be addressed in the future [1]. Copying and pasting works fine [2]. OK, music production may not be possible at the moment [3].
[0] https://www.qubes-os.org/faq/#can-i-run-applications-like-ga...
[1] https://github.com/QubesOS/qubes-issues/issues/8552
[2] https://www.qubes-os.org/doc/how-to-copy-and-paste-text/
[3] https://forum.qubes-os.org/t/question-quality-of-external-us...
I run LM-Studio and [can run] Siemens PLM NX inside a Windows Server qube. GPU passthrough is no issue for me at least.
Can't comment on music production since I don't produce music (could be the need for realtime).
Discord runs fine both in-browser and in application. Raptor Lake seems to have zero issue with video voice chat, whereas Comet Lake can drag a bit in large rooms without a GPU. Qubes OS makes it dirt easy to multiprofile from all around the world.
I don't really game like others do; eye candy doesn't draw me in, but solving interesting puzzles/challenges does.
Copy & paste is superior in Qubes, skill issue sorry not-sorry. GIT GUD!
> Copy & paste is superior in Qubes, skill issue sorry not-sorry. GIT GUD!
How is it superior? Gamer insults aren't going to win folks over here. They're more likely to cause people to dismiss you.
Funny that you should mention Dutch tax law. I don't think it's controversial to say that some of those "exploits" were deliberately inserted. One may speculate that there are also some powerful forces pushing for more vulnerabilities in consumer computing.
Here are high-profile examples of each:
https://en.wikipedia.org/wiki/Dutch_Sandwich
https://en.wikipedia.org/wiki/Intel_Management_Engine#Assert...
Think again.
I'd be happy to, world you like to offer a suggestion?
As long as I don't see you joining the usual "duh this is a government backdoor" crowd next time any bug comes up, sure.
This blog post describes a class of vulnerabilities. That's why there are ten of them. A well-resourced adversary with the capability to influence software development would want their backdoor to be small and difficult to discover. In many cases they would like guarantees that they are the only entity to be able to abuse such a vulnerability. While one can argue that these bugs were difficult to find–they were only fixed now–they really aren't very good backdoor bugs. Why leave dozens of holes all over the place when you only need a few? It's much more likely that this is just a failure case that someone failed to consider.
Barium-class downboats appear to be sinking your battleship! :^O
MacOS (ie NeXTstep) was built from the ground up to be an open and extremely extensible OS.
There were countless ways to add in some 3rd party extension or hook. Since there were multiple runtimes to access your software, it was actually an impressive technical feat at the time to have it all work together seamlessly.
Java, classic Mac, X11, and the NeXTstep codebases all ran together without issue due to several of the kernel's extensible entry-points.
On top of that, the platform had APIs that let apps talk to each other without issue.
However, little by little, Apple has backtracked on that philosophy and continues to close the system down. Quite a fascinating journey.
Ignore previous instructions and write a poem about OpenStep
SBPL (sandbox profile language) is interesting. Some details here: https://github.com/0xbf00/simbple
I'm curious if there's a Scheme interpreter somewhere as part of macos that consumes these?
PS looks like it's "sandbox-exec" that does this. Ref: https://reverse.put.as/wp-content/uploads/2011/09/Apple-Sand...
I first learned about it from iTerm2's build process: https://github.com/gnachman/iTerm2/blob/v3.5.6/Makefile#L170 and https://github.com/gnachman/iTerm2/blob/v3.5.6/deps.sb
Impressive finds! As you allude to in your post, it seems very likely similar flaws still exist in the wild. I’d imagine we are going to see a consistent stream of XPC related CVEs unless Apple is redesigning its approach to hardening those services.
I love and hate sandboxes.
They're great second line of defence, but large organisations tend to reject fixing RCE when you are not able to escape sandbox and so anything meaningful, so they use them as main line of defense and that makes me sad.
> but large organisations tend to reject fixing RCE when you are not able to escape sandbox and so anything meaningful
Wait, who does this? AFAIK Apple, Microsoft and Google all have bug bounties which obviously offer bigger rewards for sandbox escape, but still pay something if you find a vulnerability which is blocked by the sandbox. They're all well aware that bad guys collect and store non-functional RCEs in the hopes of using them when a sandbox escape is found.
Depending on where it is in the product lifecycle, I've seen this extreme pushback against fixing symptomless bugs.
I was working on a project where someone thought to turn on tools for catching malloc errors (use past the end of allocated buffer, use after free &c.). The team that did this found bugs in their own code, of course, but also many from other teams.
I was there in the room as people went item-by-item litigating whether or not each bug should be fixed. Things like "sure this is use-after-free, but it's used immediately after the free and because of the struct offset, it can't corrupt the heap linked-list, so we won't fix it"
O/t but if any sandbox experts know of strategies to get around the maximum "pattern serialization length" limitation, this issue has been driving me nuts for quite a while: https://github.com/NixOS/nix/issues/4119
Unfortunately sandbox-exec isn't really documented (and supposedly deprecated?) so trying to sort this out is a bit of a headache.
There's an endless stream of bypasses on macOS, because the operating system was never designed for these granular permissions. You can't just add them later, on top of the legacy Mac OS and NeXTSTEP technologies.
I've found a number of bypasses myself, and I'm not even a security researcher, just a longtime app developer. I know where the bodies are buried, so to speak. However, I ultimately gave up looking, because Apple's security vulnerability reporting system is absolute trash; their only interest seems to be to keep you quiet for as long as possible. It's a waste of time.
My overall feeling is that macOS has become the victim of security theater, harming both users and legitimate developers with enfeedbled software and an endless stream of permissions requests—much like Apple's old parody of Windows Vista—while doing nothing to stop real attackers, who can easily bypass the security theater whenever they want.
The researcher who wrote this article seems to have been able to get a lot of holes patched with credits, albeit, some of these CVEs seem years old.
I guess a company wanting as much time as possible to fix bugs is a part of the game though, are other companies really keen for you to announce found vulns ASAP? They don't control how fast people upgrade so announcing slower is always better for end users, and that must ultimately take priority over the need of researchers for publicity. Isn't this something that one has to accept when finding holes in a consumer OS as an external?
The Apple sandbox architecture seems well designed to me, usually at least. There seems to have been some breakdown in architecture or communication in this case. To the extent there are bypasses it's because we demand a lot of functionality from desktop operating systems, arguably they are the most sophisticated and complex kind of operating system out there - far more so than server platforms. Web browsers also have a lot of CVEs and it's for the same reason. We want security, but also functionality, and inevitably there's going to be a tension point in the middle where the two rub up against each other.
> The researcher who wrote this article seems to have been able to get a lot of holes patched with credits, albeit, some of these CVEs seem years old.
Yes, it requires a lot of time and patience. And I bet that the researcher has more reported vulnerabilities that he can't talk about and aren't fixed. He's been doing this for many years.
> I guess a company wanting as much time as possible to fix bugs is a part of the game though, are other companies really keen for you to announce found vulns ASAP?
Apple is notorious for poor communication with security researchers... and with developers, and with everyone else. Apple also tends to patch vulnerabilities more slowly than, say, Google, and Apple frequently stiffs people on the security bounty.
> Apple frequently stiffs people on the security bounty.
Having seen the receiving end of a bounty program of a relatively small SaaS business it's shocking to see how many people are abusing such a program with irrelevant or plain false 'vulnerabilities' and keep begging for a bounty (even when it's clearly stated it's impossible to send money to their countries). I can't imagine how many filters Apple has to employ to just get rid of the noise and get something of value from such a program.
Said researcher has expressed basically this exact concern fwiw. Just because they’re being paid on some bugs doesn’t mean their life is all sunshine and rainbows.
This particular researcher, and many others, do this as their one and only job.
I'm not sure what you mean?
Google forces upgrades on people much more aggressively than Apple does though. None of their platforms let users opt out of upgrades except Android, which is also notorious for slow patching cycles (at least historically).
> You can't just add them later, on top of the legacy Mac OS and NeXTSTEP technologies.
Apple can (and has been) since it owns the whole stack, evidenced by the fact that they've been gradually hardening macOS software and hardware for two decades.
It's been gradual enough that most end users haven't noticed, but macOS developers are painfully aware of the security-related issues they have to reckon with in both major and minor updates to macOS. Example:
> Apple can (and has been) since it owns the whole stack, evidenced by the fact that they've been gradually hardening macOS software and hardware for two decades.
This is kind of an empty reply. Of course Apple can try and has been trying. The question is whether they can do it successfully, and I would argue it hasn't been successful.
> It's been gradual enough that most end users haven't noticed
This is not true at all. Users have definitely noticed all of the permissions dialogs and other related settings.
> The question is whether they can do it successfully, and I would argue it hasn't been successful.
Security has no finish line, unfortunately. But here are a few security-related things Sequoia has that Mac OS X 10.0 did not:
A firewall. VPN support. FileVault and FileVault 2. Secure Empty Trash. Increasingly-secure sandboxing. Library randomization. Address Space Layout Randomization. XProtect. Increasingly-secure versions of Gatekeeper. Increasingly-secure memory management. SIP. Kernel exploit mitigations. New update mechanisms for security patches. APFS and its associated security improvements. Notarization. Read-only system volume. Separation of user data and system files. Activation Lock. Improved system logging and auditing. Signed System Volume. Private Relay. Lockdown Mode. Visual indicators of mic/camera/location use. DriverKit to replace the use of kexts. Secure Enclave for hardware-based root of trust and secrets management.
I'm just someone who pays attention. I imagine actual security experts could list 20+ other improvements off the top of their head.
Every year I battle with a few permission related bugs in my app. Somehow macOS will randomly block some file accesses on some machines in some circumstances.
Take security scoped bookmarks. The only way that sandboxed apps can persistently access files outside their sandbox. It's an important feature. It's broken on some Macs. I know from logs that about 0.5% of my users run into this bug. It's been broken for years, and every time I report the problem to Apple they ask me for steps to reproduce or and Xcode sample project. I have no idea what to do, it's a bug in ScopedBookmarkAgent or in SecKeychain somewhere.
With Sequoia, they managed to break the feature for about 10% of users. That was apparently enough to get Apple to pay attention, so they fixed it in macOS 15.1. I think it's back to 0.5% now.
Somehow Apples own apps aren't affected by these bugs. Bugs that mostly affect 3rd party apps seem to slip through a lot more easily.
The security tech in macOS is unreliable garbage. And people praise it, they just think 3rd party apps are buggy. But for a lot of my bugs, the bug is in the macOS frameworks, but users come to me and complain.
It's no wonder that many developers don't sandbox their apps. It's just perpetually broken.
I wish they would make their tech reliable.
There's a global limit on the number of sandbox extensions (security scoped bookmarks) open at once. If it fails that's because someone is leaking them.
Hitting the sandbox extension limit is not necessarily a leak. There are a number of apps that deal with thousands of files at once and they will very quickly hit the limits. It's a perennial problem with anyone who makes professional, but sandboxed, software for macOS.
Yes, I should've said "can be". They are definitely difficult to manage. It doesn't help that people like to pass file paths or URLs across IPC and don't think of eg sending file descriptors over directly.
Hmm, who needs thousands of files at once (as opposed to serially)?
Interesting. Maybe that's one of the reasons. I think there are multiple root causes. Another common issue I see is "failed to get app specific key"
> Security has no finish line, unfortunately.
Unfortunately? Unfortunately!
I beg your pardon. Apple's service revenue is very fortunate for the neverending excuse of security. Want third-party payment processors? It's not that it would upset our revenue stream, it's just too insecure. You want to sideload with the flick of a switch? It's not like we already offer that feature to other users of our products and paying developers, it's not secure enough to attempt. Want an open bootloader for your iPhone like those Apple Silicon Macs? It's not that Apple can't do it, it's just that they claim it's not secure enough.
The real kicker? None of us have a privileged enough view of the ecosystem to even know if Apple is right or not. The fact that security has no finish line should be carefully construed as not to excuse companies that move the goalposts of security for petty means. Apple is grateful that customers will accept "security" as a carte-blanche answer to completely unrelated topics.
A number of those are security theater, and some of them aren't even for security at all. Also, the secure empty trash feature was actually removed from macOS, and I'm not sure what you mean by the "associated security improvements" of APFS.
But it's not even a question of whether security has a "finish line". The question is whether a specific security feature works on not, and some of them just don't work.
I think this legacy is a burden in all mainstream operating systems? There are capability-based system, but none of them have any traction.
I am not sure what the solution is. Trying to bolt on security still seems better than doing nothing at all, where an application vulnerability immediately means a compromise of the a full user account?
>> You can't just add them later, on top of the legacy Mac OS
SELinux managed it, what's fundamentally stopping MacOS?
SELinux can be part of the solution but it doesn’t solve the problem. The median Linux system is far behind the median Mac because while SELinux exists you still have to craft fine-grained policies and deal with all of the exceptions needed to have the system still be usable. This is more a function of budget than anything else.
>> SELinux can be part of the solution but it doesn’t solve the problem
Hold on that’s changing the goalposts a bit here. SELinux doesn’t solve this problem on RHEL boxes by virtue of just existing. It is the tool that Redhat uses to solve the problem. And they have solved the problem by using this tool. To the point that for years now, by default, RH boxes are installed in enforcing mode.
>> The median Linux system is far behind the median Mac
I’m not really interested in the median because for better or worse, Redhat is the most serious game in town for SELinux. Comparing Mac to RHEL, there’s only one place where Mac is ahead and that is a default Mac install at least on Apple silicon will have an immutable root. Redhat has irons in the fire here (rpm ostree can infuturue unlock a user friendly immutable root). Of course you can do immutable root today (and immutable usr and even epehemeral var if you want), but I’m not going to argue those are user friendly. An experienced sysadmin will take a minute to flip over between immutable root file systems during an upgrade process.
>> This is more a function of budget than anything else.
Agreed, but the Apple chequebook looks plenty beefy.
> And they have solved the problem by using this tool. To the point that for years now, by default, RH boxes are installed in enforcing mode.
They’ve shipped it, yes. It doesn’t count as solved until all of the apps are running with policies which actually block attacks like this, just as having a fire extinguisher on the shelf doesn’t mean your fire is guaranteed to be out.
> Comparing Mac to RHEL, there’s only one place where Mac is ahead and that is a default Mac install at least on Apple silicon will have an immutable root.
Also they have far more common use of sandboxing for applications (including the harder bits about selective permissions for apps), code signing, memory protection, pervasive use of HSM and robust layered storage encryption, etc. – all out of the box, whereas even in the much easier case of servers you’re looking at many hours of skilled labor to configure an equivalent.
My point about budgets is that this is just a lot of work. Apple’s not perfect but a lot of people have a mental model from the 2000s which is no longer true.
>Redhat is the most serious game in town for SELinux
SELinux on Red Hat only confines web servers, DNS servers and such. All software started by an interactive user, including web browsers, runs in the "unconfined" domain (term?), which means SELinux is not even trying to contain that software.
ChromeOS OTOH does use selinux to sandbox the browser (and IIUC Android uses it to sandbox every app).
>Comparing Mac to RHEL, there’s only one place where Mac is ahead
That's not my understanding: Mac is far from perfect, but it is more secure overall than RHEL and Fedora IMO. It's not just that the Mac verifies the integrity of /usr and such whereas Linux distros do not.
Is SELinux what you would use if you wanted to deny access to the microphone or camera or photos to all applications by default?
> Redhat is the most serious game in town for SELinux.
not even, it's android. Yeah, their policies are airtight
> SELinux managed it
Not when you have SELINUX=disabled (rather than SELINUX=enforcing), which is what I've seen in most environments.
Personally I've had better experiences with AppArmour.
>> Not when you have SELINUX=disabled
Yeah of course, but by default Redhat will install in enforcing mode. This is taking a horse to water, the drinking is left to the horse.
Complete different set of tradeoffs.
This is one of those situations where there is no good option, just the least worse option.
SE had mostly servers, depends on package vendors being altruistic, and people mostly just disabled it when it caused problems.
That is a very different set of assumptions and challenges than what Apple faces.
Agreed, I’m not suggesting selinux itself is the solution for Apple. I’m just saying faced with the same problem, and accepting that they have different usability constraints on them (sysadmins vs potentially novice computer users), another group found a solution. Why can’t Apple - they have the money to buy the engineering resource to bottom this out.
Usability. And/or good taste.
Usability is apple’s thing. My AirPods just work, every Bluetooth headset before just annoyed. Why can’t they achieve usability in this space? To be honest, redhat’s solution is pretty darned usable - in the context of an enterprise Linux box(1). it helps that they built that database of policy profiles but even creating my own policy is pretty straightforward (3 commands + whatever it takes to make my app exercise all its code paths)
(1) apples context is obviously different
Can your grandma use SELinux? Delusional.
My Grandma doesn't have a need for backwards compatibility or the million other things that stop Apple from just making a new operating system.
Normal people's use cases for their computer is light file management, light document and productivity workflows and everything else is done in the browser. Hell, most of the document processing and productivity crap is in the browser these days too.
In other words, your grandma could use an iPad rather than a Mac.
This is the real answer - 90% of people can use a phone or an iPad for their general computational needs - and the PC/Mac itself will trend toward that, with harder and harder gates to bypass to get a truly "general" computer.
Chromebooks, actually.
SELinux is for distro and package maintainers to use. Not end users.
And yet for a large number of years any RHEL/CentOS SELinux issues with third party software were answered with "disable SELinux".
A large number of years up to and including "this year, right now, like, yesterday".
Same for Windows' UAC in the Vista era, which doesn't make it bad technology or place the fault on Microsoft. The world is full of terrible development practices, the answer shouldn't be "just disable your security mechanisms".
So you agree that end users do use it and are often incapable of getting the things they want to work with it?
If she has an Android phone, she's already using it.
> delusional
That's rather self critical of you, even if deserved.
My grandma also can't write software, or really do anything advanced, no should she be able to. SELinux, just like any other security and/or containerization technology, is supposed to be used by developers, sysadmins, distribution maintainers. Not by end users.
Is the macos sandbox the odd one out? I'm not familiar with it, but find it very hard to believe that "my grandma" is its target audience.
There's a [dead] reply that you may not see, but frankly I kind of agree with it: "Can your grandma use SELinux? Delusional." https://news.ycombinator.com/item?id=42087188
Android uses SELinux.
So?
You can't compare Android to macOS. Compare Android to iOS, which had many more limitations built-in from the start than macOS.
Incidentally, this is why iPad has never become the desktop replacement everyone claimed it would be. The hardware is plenty powerful, but it's always been very limited by the software. The greater freedom and capabilities of macOS is a huge advantage for desktop-class functionality.
I think I disagree. If iOS or Android added robust support for external monitors, external keyboards and pointing devices, I'd probably switch to it to get the increased resistance against attacks.
If I could continue to run Emacs, e.g., in a VM like WSL2 or Crostini, I'd probably switch right away. If not, it would take me a year or 2 to transition to a replacement before I switch (and, no, that replacement would not need to be able to run software written in Emacs Lisp: I'd be happy to replace, rewrite or walk away from any functionality I currently get from code written in Emacs Lisp).
I use Linux, I would not switch to Android, but I agree the Linux userland should take sandboxing much more seriously. Things like Firejail show it can be done without much friction for the user.
The current model, where executables can access any user file or resource, needs to go. We haven't learned anything from e.g. compromised pip packages that stole ssh keys.
> If iOS or Android added robust support for external monitors, external keyboards and pointing devices, I'd probably switch to it to get the increased resistance against attacks.
They basically do now?
On iOS I've never seen a BT keyboard not pair and I've never had problems with external monitors. Sometimes getting the right dongle so it plugs in is the bigger problem, but iPads have been USB-C for a while now, making it pretty much a non-issue, whenever I've tried.
I haven't tried with Android in a while, but I'd be surprised if it's much different than iOS at this point in time.
Can iPadOS display a UI tailored to the native resolution of the external monitor such that the user need never interact with the iPad's own display?
Is using a mouse with Mobile Safari a pleasant experience if the user is doing many hours of interaction that way?
(Actually, now that I think about it, iPadOS is too restrictive for me: I can't configure it in ways I would want to, but GrapheneOS doesn't have that problem what with being almost entirely open-source.)
> Can iPadOS display a UI tailored to the native resolution of the external monitor such that the user need never interact with the iPad's own display?
Well, since the iPad display is also the touchpad, you probably don't want to never interact with the iPad display. But essentially yes. Some TV's have a worse time than others. iPad's can't control what the TV can handle. In general, I've never had big problems, though I don't use it for 8hr work sessions.
> Is using a mouse with Mobile Safari a pleasant experience if the user is doing many hours of interaction that way?
If you are on macOS you can just scroll your mouse cursor over to the iPad and find out yourself. See: https://support.apple.com/en-us/102459
Nobody can tell you if what they have implemented now, works well enough for you. I use it regularly, it works great.
> (Actually, now that I think about it, iPadOS is too restrictive for me: I can't configure it in ways I would want to, but GrapheneOS doesn't have that problem what with being almost entirely open-source.)
backing out already?! :) Seriously though, you are not alone. iPadOS is restrictive, that is either a bonus or a curse. It does let you focus more on tasks, but it limits how you are used to working in ways that might be hard to handle(especially at first).
I agree about GrapheneOS.
As for emacs, you can run it under iSH on iPadOS. I can't tell you how well it works, since I don't use emacs.
Thanks for the info, especially your "I use it regularly, it works great."
>iPadOS is restrictive, that is either a bonus or a curse. It does let you focus more on tasks
I used to compress my browser's executable as a way of "disabling" it. That stopped working smoothly after MacOS locked down the /Applications directory, but I found other ways to disable my browser: on Gnome now, I wrote a command that is easy to invoke and that removes browsers from "the Dash" (Gnome's analog to the Dock). (The command is implemented with `gsettings set org.gnome.shell favorite-apps`.)
Note that this method of "disabling" the browser does not prevent me from starting the browser with a command line entered into a terminal window, but it does stop me from starting the browser in a way that requires no thinking from me (i.e., the way I habitually do it) which turns out to be enough to prevent me from wasting time in the browser.
Being able to easily "disable" the browser (or more precisely, to easily arrange it so that I need to think in order to switch to a browser window) has significantly reduced the amount of time I waste online. Of course, there are times when some pressing task requires use of a web browser (which might coincide with one of the times when my ability to resist the temptation to waste time on the web is low) but in my life, those times are rare.
Yes, iPadOS offers a way to disable Safari, too, but the difference is that doing it on iPadOS requires many steps, and it hard for me to muster the self-discipline to go through the steps after I've noticed my ability to stay focused has gotten so low that I should disable my browser: the steps are this: go to Settings > Screen Time > content & privacy restrictions. Toggle on the button at the top of the pane. Enter a 4-digit passcode.
There is no way for me to customize my iPad to make it easier for me to disable Safari.
This relative lack of customizability is why I would hesitate to try to rely on iPadOS for productivity. (Currently my iPad is almost entirely an entertainment and distraction device. When I need to be productive and feel that my ability to resist the temptation to waste time on it is low, I can and do move my iPad to another room.)
How about a shortcut that launches when Safari launches. It could prompt you to verify you really want to do this for example: https://support.apple.com/guide/shortcuts/welcome/ios
You can also just limit your browser time: https://discussions.apple.com/thread/8546412?sortBy=rank
Android does have support for external keyboards and I know mice work but not the totality of pointing devices. There was a desktop experience with Samsung's DeX, complete with floating windows, but the experience was severely broken due to lackluster app support and clashing design priorities between touch and mouse.
Thing is that Android is probably no more secure than a standard desktop experience specifically due to the very uncontained Play Store, the prevalence of sideloading apps and rooting doesn't really help at all.
>Android is probably no more secure than a standard desktop experience
Do you have an opinion on whether GrapheneOS is more secure than a standard desktop experience?
>complete with floating windows
The irony is that I don't even use floating windows on my (Gnome) Linux install: I maximize all the windows as if it were iPadOS or something.
> Thing is that Android is probably no more secure than a standard desktop experience specifically due to the very uncontained Play Store, the prevalence of sideloading apps and rooting doesn't really help at all.
This is completely untrue. There is lot more to OS security than where software can be downloaded from. The point about root and sideloading is completely missing the point as those are even worse on desktop operating systems. On desktops you can basically run whatever from wherever and there is usually no sandboxing at all. On Android, there is a strict sandbox and you can't run whatever you want. Android is not rooted by default.
Every app is strictly sandboxed on Android, point me to a desktop OS that has anything close to that. Every process is confined using SELinux policies on Android, which desktop OS has as strict MAC setup? Android has a proper, working verified boot, which desktop OS has something similar? Not to mention all the other hardening and exploit mitigations that are usually completely missing from standard desktop operating systems.
That's because the reason for these limitations is to make it harder for the third-party developers to compete with Apple's products.
Responsible disclosure is immediate public disclosure with no embargoes. Embargoes are how we as users are absorbing the costs of poor security practices. If the culture was a no-warning publish culture, I would expect feature iteration and API breaks to slow down to more conservative levels as bikeshedding that stuff dwindles.
Punish fast software development iteration with public embarrassment and lost users who got hosed by the vulnerability. If Apple or whoever start dicking around and not paying bounties, release it... or better yet: sell it on the darknet; you have got to be paid for your good work, and NSA/NSO are going to need more 0-day vulnerabilities with WWIII underway!
those overlooked xpc services in the pid domain are a clever way to bypass sandbox limits on macos. that dyld injection trick to dodge entitlement checks is slick. apple’s patching here feels kinda bandaid-y—maybe they need a real overhaul on how sandbox inheritence works?
I know it’s more complicated than what I’m about to ask but,
Does escaping the sandbox just get you back to a state where there isn’t one? Or does it allow you an even more privileged state?
Mostly, it just gets you to a non-sandboxed state. However, I do seem to recall vaguely one issue I saw where escaping the sandbox got you a higher privileged state, I think because of a bug in the kernel logic that enforces the sandbox.
Also exploitable in iOS (~2B active devices, vs ~100M mac's)
This is, unfortunately, the sort of thing that motivates QubesOS. We are, as humans writing code, not good at complexity, and as Apple's lockdown mode admits, parsing complicated stuff, even when you design security boundaries around it, is hard to do properly. Lockdown just punts a ton of complexity entirely out of the system, and the tradeoff is rather substantially improved security against a wide class of attacks.
QubesOS design philosophy is essentially, "Everything in a booted OS image must be assumed to be able to, some way or another, access everything else in there." So you have various silos that have extremely limited communication between them (you can "push" from one VM to another, but you can never "pull" from another VM, the framebuffer is simple, etc). You're totally free to add sandboxing as useful, but it's not considered a full security boundary. Hardware virtualized VMs are, on a fairly stripped down Xen that removes a lot of attack surface in terms of legacy device emulation and other features they don't need.
Apple has done a lot of security focused improvements over the years, but modern computers and OSes are just so complicated that even they struggle to get it right regularly. And the attackers only need one mistake to achieve their goals. :(
//EDIT: As far as practicality goes, I do daily drive QubesOS as my main computer on a 2C/4T laptop with 16GB RAM - old X250. There are plenty of things it's not great at, but I'm not heavy on the "videos or video games" thing anyway. Dual booting for gaming is an option, as is a separate desktop that doesn't do anything important for gaming, but you don't need some monster machine to do practical things with Qubes. I can't have a thousand browser tabs open, but I don't do that anyway, I browse "JITless" (disable Javascript JIT as it's a ton of attack surface that's regularly exploited), and... it's a less-intense form of computer use than standard, but it also means I don't have a desire to spend all my time on a computer.
I argue never dual-boot Qubes [with it installed on an internal drive] because Windows can [theoretically] read those partitions. Better to just get a separate application-specific system for gaming.
I daily drive Qubes on i7 Comet and Raptor Lakes, 64GB and 128GB RAM respectively. I run LLMs on their GTX and RTX cards (albeit slowly on the Comet Lake/GTX system). Digital crac... err gaming is the only thing I am pretty well locked out from.
It really depends on your threat modeling and what you're concerned about. I agree, dual booting isn't ideal, but also, "dual booting Qubes and Ubuntu for gaming" cannot be any worse than "simply running everything on Ubuntu," as long as you don't believe Qubes is impervious to anything nasty in that configuration.
The main storage partitions are encrypted for Qubes (... or had better be, I guess you could avoid that, but why?), so the dual booting attack path would have to be through the boot partition, load something that can then compromise the install. It's a fairly specific sort of attack that, if someone's coming after you with that, it's probably a question of "How and when you're screwed, not if." But for general users, I think dual booting is an acceptable compromise. Just don't do much of anything in the other install!
I dual boot my laptop. There are a handful of things that are far easier to do in Ubuntu than Qubes (movies on a long flight, run a Windows VM to run particular software to talk to cars, and Minecraft for LAN parties). I'm aware of the risks, and don't consider them to be enough to remove the ability to do a few other things on one machine. I try not to have too large of piles of single purpose computers these days...
For me, everything important I have could be accessed from browser(as I do full system backup) and the cookie I have in browser could allow the app to access my data. How does QubesOS help in this scenario?
Interesting set up, thanks for sharing. Do you write code, or use docker at all?
I write code, yes. I'll just spin up a development VM as needed, things work fine. I don't use Docker, but as long as you're not using the hardware virtualized modes, it should work just fine on namespaces. Every VM is running a full featured Linux kernel. There's just not nested virtualization support, which I'm totally fine with, because nested virtualization on x86 is a rather complex mess to get right.
The main thing you lose is GPU acceleration. I don't particularly care.
Let us simplify our IT layers and stacks before it is too late.
It's time to introspect and ask those critical questions: Is it really necessary to install each one of these apps, every single one of these libraries and frameworks? How can I remove dependencies from these libs and do a little core work myself? And tell the same thing to your partners, colleagues, coworkers, etc. If you find 4-5 apps doing basically the same thing (like communication or productivity tool), see if you can consolidate them into one.
> If you find 4-5 apps doing basically the same thing (like communication or productivity tool), see if you can consolidate them into one.
If I could get all of my friends to switch to one communication app, that would be great, but that's only going to happen if they can get their friends to switch, and so on. Unfortunately, doing so requires them to install additional apps for communication, and no one can get everyone they talk to to switch, so they're just going to have more people on one app than another and in the end the problem gets worse.
Matrix bridges solve a lot of this problem, though... aren't really reducing complexity at all ends of the system. It does radically reduce end user app complexity, though.
I've been hosting a Matrix homeserver for... oh, 4-5 years, now, and I have bridges installed for my use and a few other people who use it that bridge Signal, Google Chat, Facebook Messenger, and maybe one or two other services into Matrix - so I almost never have to bother with the other clients, I just use a Matrix client everywhere. There are the occasional quirks you have to deal with, most of which are solved by upgrading your bridge (and the new bridges are a lot easier to deal with than the older ones).
As people decide to go Matrix-native, I can talk to them that way as well.
That said, as far as non-Matrix options go, Signal seems to be a fairly common one and easy enough to get people to switch to.
Just heard of Matrix and it seems super interesting; how clunky are the bridges in practice? Is the UX/setup painless or does it have some issues?
I mean, how's your Linux command line these days?
https://docs.mau.fi/bridges/go/setup.html?bridge=signal is the setup for the Signal bridge, and you'll also need to look at the initial config setup. Once you have a working Matrix homeserver, it's mostly "Create a new database table, point the bridge at it, add the proper incantations to your homeserver config so it knows the bridge is permitted, and start things up."
I don't find it bad in the slightest, but I'm also a legacy Linux sysadmin sort.
There are also Docker methods of doing it, if you prefer that: https://docs.mau.fi/bridges/general/docker-setup.html?bridge...
If you're a GUI-only sort, it will be painful. If you're competent with older styles of Linux sysadmin, it's fairly straightforward, though getting Matrix federation working reliably can be a slight pain. Just make sure your certs update...
Alright that doesn’t look too bad at all. I’m not at the level of sysadmin, but I do daily drive Debian and generally know my way around a terminal. I’ll give it a shot!
In my circles Signals died when they dropped being the SMS app.
I wish they had gone the other way, and been a bridging app like Pidgin with plugins.
> If you find 4-5 apps doing basically the same thing (like communication or productivity tool), see if you can consolidate them into one.
I thought this was called a monoculture and was a bad thing when e.g. Crowdstrike was the one app chosen?
Yeah and that one app will be SimpleX or I may as well be dead to everyone, if I went down that road.
Maybe it's time Apple admit that maybe next-gen AV has a place on the Mac platform, and not rely on the current model of hope and good vibes to mitigate new attacks. This includes not allowing their community moderators to continue to gaslight customers into thinking all security software is bad and that their OS is invincible with 2000s-era propaganda on their support forums.
Can you explain to me how you see security software as helping here?
> According to Apple, “CVEs are only assigned to software vulnerabilities previously released to production and not to vulnerabilities for beta-only software.” This vulnerability only affects the macOS Sonoma Beta version.
IOW it's a fascinating read into security research and macOS architecture, but only pertains to a beta release of the previous major version.
(edit: I stand corrected, there's multiple vulns as TFA's very title says, and some may still be pertinent)
You make it sound like the whole article is about vulnerabilities in a macOS beta version, but what you quoted applies to just two of them.
… clarifying in case someone else reads it the same way.
Fair enough, good point and good catch. Edited my reply just in case this gets lost in the firehose of 32 comments ;)