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.
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.
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.)
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.
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.
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.
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!
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].
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.
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.
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.
> 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.
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 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.
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!
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.
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).
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.
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.
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"
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.
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?
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...
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...
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.
> On Windows land you have something similar
I'm still waiting to hear about a kernel-level exploit that starts with Visicalc or similar.
Visicalc doesn't run on recent versions of Windows without emulation.
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.
>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
This is a fantastic read, thanks for linking it. Linus's pragmatic approach really comes to the fore.
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.
> There's no security model for desktops that works well.
Qubes OS works quite well, if you need security on desktop.
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.)
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...
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.
> 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.
> 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
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!
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.
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...
Barium-class downboats appear to be sinking your battleship! :^O
[dead]
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.
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.
> 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.
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.
> 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.
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!
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.
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.
> 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.
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.
If she has an Android phone, she's already using it.
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".
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?
A large number of years up to and including "this year, right now, like, yesterday".
> 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).
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 an iPad.
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.
That's because the reason for these limitations is to make it harder for the third-party developers to compete with Apple's products.
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"
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)
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?
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...
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...
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.
Yeah and that one app will be SimpleX or I may as well be dead to everyone, if I went down that road.
[dead]
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.
[flagged]
> 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 ;)