6 ms·

>Changing a security model that has been used for decades to a more restrictive model is difficult, especially in something as complicated as macOS. Attaching d

>Changing a security model that has been used for decades to a more restrictive model is difficult, especially in something as complicated as macOS. Attaching debuggers is just one example, there are many similar techniques that could be used to inject code into a different process. Apple has squashed many of these techniques, but many other ones are likely still undiscovered. > Aside from Apple’s own code, these vulnerabilities could also occur in third-party software. It’s quite common to find a process injection vulnerability in a specific application, which means that the permissions (TCC permissions and entitlements) of that application are up for grabs for all other processes. Getting those fixed is a difficult process, because many third-party developers are not familiar with this new security model. Reporting these vulnerabilities often requires fully explaining this new model! Especially Electron applications are infamous for being easy to inject into, as it is possible to replace their JavaScript files without invalidating the code signature. It makes me sad that we are likely not going to see any new fundamental design rethink for security's sake in mainstream operating systems. It is cost prohibitive at this point to do something that gets security right for the world of 2022 and yet not break all the apps which would never be rewritten! Mobile OSes were a good break off point as far as security goes but that came with a lot of functionality sacrifice. Although something like QubesOS can theoretically dream of being semi-mainstream with support from hardware and OSS OS vendors like RH/Suse/Canonical or even Microsoft.

olliej 4y ago
Fuchsia does a pure capability model, and resources, even as basic as the file system are provided through handles - and your file system handle is a handle to what would be a directory elsewhere, but that is the entire file system so it’s not a matter of finding a traversal exploit. In principle you could do something similar with the Mac/iOS sandbox by starting a process with a compute only sandbox, and then provide it with specific sandbox entitlements (from the parent) which includes specific file systems, however they still in principle can see a full version of the fs. And yeah, any OS that isn’t completely new is burdened with support for old apps, but then iOS which used its newness to have a stronger base security model is constantly beaten up for that model.
- blinkingled 4y ago
  Ah, I forgot about Fuchsia - https://arxiv.org/pdf/2108.04183.pdf https://arxiv.org/pdf/2108.04183.pdf seems to do a good job of explaining the security architecture without complicating things. With Google's backing (if they don't lose interest that is) and the potential to take over Nest/Chromebook/Android devices it might go farther than most new OS experiments.
eru 4y ago
> It is cost prohibitive at this point to do something that gets security right for the world of 2022 and yet not break all the apps which would never be rewritten! You could quarantine your old applications to their own individual VMs, while newer programs can make use of your shiny new security features?
- blinkingled 4y ago
  Sort of like Fuchsia/QubesOS combo, interesting.
  - eru 4y ago
    Maybe, I don't know these. I was just pointing out that we can have both progress and backwards compatibility. Just like we can still play old games via dosbox, but that doesn't mean we have to run DOS as our main OS.
- KerrAvon 4y ago
  Harder than it sounds, though. You still have to be able to communicate with other processes to present the user with a usable UI, so the isolation is never really complete. There are lots of variations on this theme and they all have to compromise in some way.
  - hn_throwaway_99 4y ago
    True, but Apple still did it to allow Classic Mac apps to run on OS X when the initial version of OS X was released.
  - eru 4y ago
    Oh, it's definitely no walk in the park. But more realistic than rewriting all old programs in one go.
  - samus 4y ago
    It's perfectly possible to have that with something like the X window system. The irony is that this protocol gives applications way too many capabilities. But Wayland is a chance to fix that for good and finally have proper compartmentalisation in the GUI.
Syonyk 4y ago
> Although something like QubesOS can theoretically dream of being semi-mainstream with support from hardware and OSS OS vendors like RH/Suse/Canonical or even Microsoft. I'm trying to encourage as many people as I can to run it, or at least play with it for some while to gain familiarity with it. Properly applied, I think it does add quite a bit of useful practical security... though it's not going to automatically solve all problems. I like the silos of compromise, at least, and you can do high risk things (like "anything web") in disposable VMs that reset on VM power cycle. My only major concern with Qubes is that I've not decided if it's weird and niche enough to be mostly left alone by the 0day markets, or if it's a super high priority, high value target to attack because of the type of people who are likely to use it. I'd like to see an ARM port of it, because Xen on ARM is quite a bit simpler than Xen on x86, but the hardware to run that doesn't quite exist yet. Maybe with the RK3588... The fundamental problem here is that software developers (and I'm guilty here too, as much as anyone in that industry) tend to view complexity as a one way ratchet function - add features. Add features. Add features. Add knobs. And when it comes crashing down around your ears, "add security" (in the form of sandboxes, or process isolation, or... https://xkcd.com/2044/ https://xkcd.com/2044/ applies here). And then it turns out that "adding complexity to solve problems created by complexity" isn't a strategy with a great long term success rate. I'm slightly encouraged by Apple admitting, as clearly as they ever admit anything, that this strategy isn't working - with their Lockdown mode, that's "only for people with the most extreme threats, blah blah blah," and I'd expect anyone in the security or software industry to turn that on basically as soon as they get iOS 16 and not look back. Or install the beta to give that option.
- dmz73 4y ago
  I have tried the QubesOS and boy does it bring back memories of Windows being called Pentium to 286 converter. It is slow as molasses on hardware where even Windows 10 and Gnome are both fast and to make it usable you have to keep relaxing the security to the point where it is probably less secure than regular OS. And don't even bother if you have to use scaling other than 100%, sure you can scale the DOM0 but the rest of the VMs are not scaled and there is no documentation on how to do it. What we need are simple sandboxes that isolate GUI applications into chroot environment and keep them away from other applications and documents.
userbinator 4y ago
It makes me sad that we are likely not going to see any new fundamental design rethink for security's sake in mainstream operating systems. Contrarily, that makes me happy because if that happens we are really going to lose what little computing freedom we have left, as it will only make the walled garden silos even stronger.
- matheusmoreira 4y ago
  Yeah. The problem with all these security innovations is they allow corporations to seize control. The ability to debug and intercept is also the ability to reverse engineer and override. We need secure software that empowers us, not some secure walled garden.
- eastbound 4y ago
  It’s hard to sign off SOC2 compliance when you know that npm and maven packages can be introduced by any mistake on your team and contain an “Upload all files from HDD to a rogue server” script. I’d need to operate administrative files (customer records, contracts, accounting) on a separate machine from dev… App sandboxing is… the way it will go, for insurance reasons.
  - wila 4y ago
    > I’d need to operate administrative files (customer records, contracts, accounting) on a separate machine from dev You're saying that like it is a bad thing? A developer probably shouldn't have access to all that live data anyways.
    - eastbound 4y ago
      As a founder-developer of a company of 3, would you expect me to have 2 computers, for the security of customer data? It’s an interesting idea, I’m just asking.
      - skrtskrt 4y ago
        For such a small company I would probably expect that data like that would probably just live in a cloud service like GSuite that’s already SOC2 compliant, then if you’re running software integrations against that data, you’re spinning up isolated SOC2-compliant cloud servers to do so. Unfortunately unless you get ridiculously creative and put in a bunch of extra time instead of cloud service spend, SOC2 compliance is gonna be expensive
solarkraft 4y ago
> Mobile OSes were a good break off point as far as security goes but that came with a lot of functionality sacrifice. I have a tiny bit of hope that they'll eventually be able to replace desktop OSes through virtualization. It's actually what I long thought Apple would do with iPad OS (why else put in an M1?).
mhoad 4y ago
Google’s upcoming Fuchsia OS has an entirely new security model that looks really solid. I imagine it’s still a few years away however from any kind of desktop usage.
londons_explore 4y ago
I think a lot of users would be fine with apps being fully silo'ed from eachother with the exception of being able to copy and paste between them, and have 'File Open' dialog boxes able to access files from anywhere. Every other kind of interaction between seperate applications can be blocked without breaking much functionality. And you can limit breakage further by running all 'legacy' applications in the same silo, and only running new applications disconnected from eachother.
- noduerme 4y ago
  Literally any other kind of interaction between applications feels like the apps are spying on me. I don't even want one to suggest which app I should open for a doc. Mac OS has taken security in a strange direction where you can't change the suffix of a file without exposing possible vulnerabilities by apps automatically opening it - and the backstop is supposed to be validating all applications through your "apple account" (whatever that is?). (although in some sense the suffix and permissions flaws have been around since System 7).
deleted 4y ago
[deleted]
still_grokking 4y ago
Well, GNU Hurd 2 is going to be released real soon now. It will fix all the issues with current OS architectures. And than, at some point Google's Fuchsia will also surface in mainstream likely. Both systems will bring capability-security. (You know, almost like seL4, only less secure). A technology that wasn't used until now, even it's available for almost 50 years, and would solve almost all security problems of computers. We could have had that in fact directly supported by hardware almost four decades ago… But the market didn't like that. The problem is that there is and won't be any progress in computer technology. It's like that since at least one hundred years. We're buried in the von Neumann local "optimum" since than… As long as this does not change we're doomed to have crappy, inefficient, and insecure computers. The invisible hand will just prevent any progress until forever. (OK, our future AI-Overlords could change that possibly). But who cares about the status quo? The market insists on it. So any attempt at resistance is therefore futile. ___ Please excuse the slight amounts of sarcasm. I just couldn't hold back. And seriously: There may be some jokes hidden in here. If you try you'll recognize one or two of them, I bet… :-D
highwaylights 4y ago
Qubes is a good product while simultaneously being both the best and an objectively poor solution to a problem that shouldn't exist. That's how much of a mess the situation is. Qubes is sandboxing at a machine level by putting every application set into it's own O/S. Is that in any way clean or ideal? Not at all. But it's necessary if you don't trust your own O/S not to have been compromised by the software running inside it. I get the arguments against centralised software distribution - it encourages monopolistic behaviour and removes user freedom - but it does at least make a problem of this nature fixable if you can enforce compliance to breaking changes at distribution time. I'd like to think a new layer could be added to Linux or BSD that would marshall this kind of compliance centrally without deliberately conflating payment into it, but I've no idea how you'd get widespread adoption of something like that even if you could organise to implement it. You'd also likely need to implement code-signing everywhere which was such a challenge in the past that (at least in the Linux kernel) it was abandoned. A similar model to how domain registration works for white-listing might make sense here, in that it's not centralised - but it's not fully decentralised either - and at some point there needs to be a process to onboard new authorities who everyone needs to trust, at which point it's a slippery slope to self-certification.
MAGZine 4y ago
> It makes me sad that we are likely not going to see any new fundamental design rethink for security's sake in mainstream operating systems. It is cost prohibitive at this point to do something that gets security right for the world of 2022 and yet not break all the apps which would never be rewritten! I don't think that's the case though. Microsoft overhauled the entire security post of windows during Vista. It wasn't a good OS when it came out, but Windows is much better for it. But yes, if you're going to start from the ground up, you're going to lose a bunch of functionality. Not only due to the nature of rewrites, but also because of "what new limitations does the security model imply"?

olliej 4y ago

Fuchsia does a pure capability model, and resources, even as basic as the file system are provided through handles - and your file system handle is a handle to what would be a directory elsewhere, but that is the entire file system so it’s not a matter of finding a traversal exploit. In principle you could do something similar with the Mac/iOS sandbox by starting a process with a compute only sandbox, and then provide it with specific sandbox entitlements (from the parent) which includes specific file systems, however they still in principle can see a full version of the fs. And yeah, any OS that isn’t completely new is burdened with support for old apps, but then iOS which used its newness to have a stronger base security model is constantly beaten up for that model.

blinkingled 4y ago
Ah, I forgot about Fuchsia - https://arxiv.org/pdf/2108.04183.pdf https://arxiv.org/pdf/2108.04183.pdf seems to do a good job of explaining the security architecture without complicating things. With Google's backing (if they don't lose interest that is) and the potential to take over Nest/Chromebook/Android devices it might go farther than most new OS experiments.

eru 4y ago

> It is cost prohibitive at this point to do something that gets security right for the world of 2022 and yet not break all the apps which would never be rewritten! You could quarantine your old applications to their own individual VMs, while newer programs can make use of your shiny new security features?

blinkingled 4y ago
Sort of like Fuchsia/QubesOS combo, interesting.
- eru 4y ago
  Maybe, I don't know these. I was just pointing out that we can have both progress and backwards compatibility. Just like we can still play old games via dosbox, but that doesn't mean we have to run DOS as our main OS.
KerrAvon 4y ago
Harder than it sounds, though. You still have to be able to communicate with other processes to present the user with a usable UI, so the isolation is never really complete. There are lots of variations on this theme and they all have to compromise in some way.
- hn_throwaway_99 4y ago
  True, but Apple still did it to allow Classic Mac apps to run on OS X when the initial version of OS X was released.
- eru 4y ago
  Oh, it's definitely no walk in the park. But more realistic than rewriting all old programs in one go.
- samus 4y ago
  It's perfectly possible to have that with something like the X window system. The irony is that this protocol gives applications way too many capabilities. But Wayland is a chance to fix that for good and finally have proper compartmentalisation in the GUI.

Syonyk 4y ago

> Although something like QubesOS can theoretically dream of being semi-mainstream with support from hardware and OSS OS vendors like RH/Suse/Canonical or even Microsoft. I'm trying to encourage as many people as I can to run it, or at least play with it for some while to gain familiarity with it. Properly applied, I think it does add quite a bit of useful practical security... though it's not going to automatically solve all problems. I like the silos of compromise, at least, and you can do high risk things (like "anything web") in disposable VMs that reset on VM power cycle. My only major concern with Qubes is that I've not decided if it's weird and niche enough to be mostly left alone by the 0day markets, or if it's a super high priority, high value target to attack because of the type of people who are likely to use it. I'd like to see an ARM port of it, because Xen on ARM is quite a bit simpler than Xen on x86, but the hardware to run that doesn't quite exist yet. Maybe with the RK3588... The fundamental problem here is that software developers (and I'm guilty here too, as much as anyone in that industry) tend to view complexity as a one way ratchet function - add features. Add features. Add features. Add knobs. And when it comes crashing down around your ears, "add security" (in the form of sandboxes, or process isolation, or... https://xkcd.com/2044/ https://xkcd.com/2044/ applies here). And then it turns out that "adding complexity to solve problems created by complexity" isn't a strategy with a great long term success rate. I'm slightly encouraged by Apple admitting, as clearly as they ever admit anything, that this strategy isn't working - with their Lockdown mode, that's "only for people with the most extreme threats, blah blah blah," and I'd expect anyone in the security or software industry to turn that on basically as soon as they get iOS 16 and not look back. Or install the beta to give that option.

dmz73 4y ago
I have tried the QubesOS and boy does it bring back memories of Windows being called Pentium to 286 converter. It is slow as molasses on hardware where even Windows 10 and Gnome are both fast and to make it usable you have to keep relaxing the security to the point where it is probably less secure than regular OS. And don't even bother if you have to use scaling other than 100%, sure you can scale the DOM0 but the rest of the VMs are not scaled and there is no documentation on how to do it. What we need are simple sandboxes that isolate GUI applications into chroot environment and keep them away from other applications and documents.

userbinator 4y ago

It makes me sad that we are likely not going to see any new fundamental design rethink for security's sake in mainstream operating systems. Contrarily, that makes me happy because if that happens we are really going to lose what little computing freedom we have left, as it will only make the walled garden silos even stronger.

matheusmoreira 4y ago
Yeah. The problem with all these security innovations is they allow corporations to seize control. The ability to debug and intercept is also the ability to reverse engineer and override. We need secure software that empowers us, not some secure walled garden.
eastbound 4y ago
It’s hard to sign off SOC2 compliance when you know that npm and maven packages can be introduced by any mistake on your team and contain an “Upload all files from HDD to a rogue server” script. I’d need to operate administrative files (customer records, contracts, accounting) on a separate machine from dev… App sandboxing is… the way it will go, for insurance reasons.
- wila 4y ago
  > I’d need to operate administrative files (customer records, contracts, accounting) on a separate machine from dev You're saying that like it is a bad thing? A developer probably shouldn't have access to all that live data anyways.
  - eastbound 4y ago
    As a founder-developer of a company of 3, would you expect me to have 2 computers, for the security of customer data? It’s an interesting idea, I’m just asking.
    - skrtskrt 4y ago
      For such a small company I would probably expect that data like that would probably just live in a cloud service like GSuite that’s already SOC2 compliant, then if you’re running software integrations against that data, you’re spinning up isolated SOC2-compliant cloud servers to do so. Unfortunately unless you get ridiculously creative and put in a bunch of extra time instead of cloud service spend, SOC2 compliance is gonna be expensive

solarkraft 4y ago

> Mobile OSes were a good break off point as far as security goes but that came with a lot of functionality sacrifice. I have a tiny bit of hope that they'll eventually be able to replace desktop OSes through virtualization. It's actually what I long thought Apple would do with iPad OS (why else put in an M1?).

mhoad 4y ago

Google’s upcoming Fuchsia OS has an entirely new security model that looks really solid. I imagine it’s still a few years away however from any kind of desktop usage.

londons_explore 4y ago

I think a lot of users would be fine with apps being fully silo'ed from eachother with the exception of being able to copy and paste between them, and have 'File Open' dialog boxes able to access files from anywhere. Every other kind of interaction between seperate applications can be blocked without breaking much functionality. And you can limit breakage further by running all 'legacy' applications in the same silo, and only running new applications disconnected from eachother.

noduerme 4y ago
Literally any other kind of interaction between applications feels like the apps are spying on me. I don't even want one to suggest which app I should open for a doc. Mac OS has taken security in a strange direction where you can't change the suffix of a file without exposing possible vulnerabilities by apps automatically opening it - and the backstop is supposed to be validating all applications through your "apple account" (whatever that is?). (although in some sense the suffix and permissions flaws have been around since System 7).

deleted 4y ago

[deleted]

still_grokking 4y ago

Well, GNU Hurd 2 is going to be released real soon now. It will fix all the issues with current OS architectures. And than, at some point Google's Fuchsia will also surface in mainstream likely. Both systems will bring capability-security. (You know, almost like seL4, only less secure). A technology that wasn't used until now, even it's available for almost 50 years, and would solve almost all security problems of computers. We could have had that in fact directly supported by hardware almost four decades ago… But the market didn't like that. The problem is that there is and won't be any progress in computer technology. It's like that since at least one hundred years. We're buried in the von Neumann local "optimum" since than… As long as this does not change we're doomed to have crappy, inefficient, and insecure computers. The invisible hand will just prevent any progress until forever. (OK, our future AI-Overlords could change that possibly). But who cares about the status quo? The market insists on it. So any attempt at resistance is therefore futile. ___ Please excuse the slight amounts of sarcasm. I just couldn't hold back. And seriously: There may be some jokes hidden in here. If you try you'll recognize one or two of them, I bet… :-D

highwaylights 4y ago

Qubes is a good product while simultaneously being both the best and an objectively poor solution to a problem that shouldn't exist. That's how much of a mess the situation is. Qubes is sandboxing at a machine level by putting every application set into it's own O/S. Is that in any way clean or ideal? Not at all. But it's necessary if you don't trust your own O/S not to have been compromised by the software running inside it. I get the arguments against centralised software distribution - it encourages monopolistic behaviour and removes user freedom - but it does at least make a problem of this nature fixable if you can enforce compliance to breaking changes at distribution time. I'd like to think a new layer could be added to Linux or BSD that would marshall this kind of compliance centrally without deliberately conflating payment into it, but I've no idea how you'd get widespread adoption of something like that even if you could organise to implement it. You'd also likely need to implement code-signing everywhere which was such a challenge in the past that (at least in the Linux kernel) it was abandoned. A similar model to how domain registration works for white-listing might make sense here, in that it's not centralised - but it's not fully decentralised either - and at some point there needs to be a process to onboard new authorities who everyone needs to trust, at which point it's a slippery slope to self-certification.

MAGZine 4y ago

> It makes me sad that we are likely not going to see any new fundamental design rethink for security's sake in mainstream operating systems. It is cost prohibitive at this point to do something that gets security right for the world of 2022 and yet not break all the apps which would never be rewritten! I don't think that's the case though. Microsoft overhauled the entire security post of windows during Vista. It wasn't a good OS when it came out, but Windows is much better for it. But yes, if you're going to start from the ground up, you're going to lose a bunch of functionality. Not only due to the nature of rewrites, but also because of "what new limitations does the security model imply"?