7 ms·

Sounds good but a problem with Apple's latest releases are that a lot of its security features listen only to Apple and not to the user. This doesn't concern m

Sounds good but a problem with Apple's latest releases are that a lot of its security features listen only to Apple and not to the user. This doesn't concern most of the improvements mentioned in the article, those are purely technical improvements at a very low level. But the signed system volume for example (also mentioned), while a good idea, lacks a convenient way for the user to make changes to it. I'm not very happy leaving my security to a black box and just trusting the supplier implicitly. This is a supplier that introduced a "get root with blank password" bug and the "your password hint is your actual password" one. Sure, everyone makes mistakes, especially for that reason I'd want to have more access than they offer now. macOS is becoming more and more like iOS, which is also way too closed in my opinion. More locks is always good but the user should have a key, not just the supplier.

azinman2 5y ago
You can always disable CSR/SIP generally. macOS is unlike iOS in that many security mitigations can be disabled. The fact that new M1 Macs let you side load a diff non-Apple in iOS should be the ultimate proof you need of this motivation to allow user control on Macs.
- jchw 5y ago
  If one mentions Android’s “openness” as a plus, people (rightly) point out that sure, it is technically open source and you can often sideload, but that doesn’t mean it is friendly towards those things necessarily. A lot of downsides come with rooting and bootloader unlocking after all. That is when comparing to iOS, which is more restrictive than macOS, as you point out. I mention this because I think that it’s good Apple lets you use some of the hardware you own with relatively little restriction if you so choose, but it is a lot less practical than the previous status quo and other systems. You definitely lose some functionality (on M1, I believe you lose at least iOS application support.) If we’re going to be frank about it with Android, I think it’s fair to be frank about it with macOS/M1. I would guess things could be better if user choice was as much of a focus as vendor control.
  - ChuckNorris89 5y ago
    >A lot of downsides come with rooting and bootloader unlocking after all. I think you might be confused. You don't need to root or unlock the bootloader on an Android device to side load apps. Just download desired APK and accept the security prompt of installing from unknown sources. It's literally that easy.
    - eropple 5y ago
      Those applications can't get root, though, and that does limit user control of the device. (I used to root Android phones in the 4.x days, and then stopped, and then went back to iOS as I found myself doing progressively less and less with my phone.)
    - deleted 5y ago
      [deleted]
- upbeat_general 5y ago
  Except doing so doesn’t let you run iOS apps and not to mention is a pain to do so after every update (I believe SSV requires that). The list of things to disable seems to grow every year. Even with Gatekeeper, CSR/SIP disabled I’ll still have issues opening applications which may (or may not) be fixed by taking it out of quarantine, changing the signature, etc
  - saagarjha 5y ago
    You can disable SIP once and it will stay off (although maybe not if you do a full system update).
- GekkePrutser 5y ago
  Yes you can disable it, but then you disable it completely and totally. There is no middle ground. Most of the time these things are totally great ideas. Apple is doing really great work on the security front for sure. It's just what they lack is a way to customise them. Most security improvements they make involve giving Apple the keys and them alone. It doesn't have to be that way. For example I would want to be able to just make an exception for some of the files I want to change.
  - Klonoar 5y ago
    There actually is a middle ground, in some cases - csrutil can, for instance, allow you to disable unsigned kext blocking but keep the rest of SIP enabled.
    - GekkePrutser 5y ago
      I thought those were entirely separate things? There's now a GUI option for the unsigned kernel extension block (in the startup security utility). I don't think that's part of SIP per se. It's also the one you need to run any other OS. Whereas SIP is a thing within the OS itself as far as I know. But I have to admit this is where my knowledge gets fuzzy :) The kind of control I'd want is allowing to add a signator for approved kernel extensions. So that I could add my own key and sign kernel extensions myself. Or trust another party to do this. Just like you can add your own keys to Secure Boot on a PC. The same with the app notarisation. Another feature that's essentially great, but fully under the control of Apple. For example, as a corporate admin it'd be great to be able to notarise which apps I'd allow our employees to use. These security tools would be super powerful and useful if we would be allowed to configure them more.
      - easton 5y ago
        If you’re a corporate admin you can whitelist kernel extensions via MDM, maybe that would help? https://support.apple.com/guide/mdm/kernel-extension-policy-payload-settings-mdm88f99b98a/web https://support.apple.com/guide/mdm/kernel-extension-policy-...
- cma 5y ago
  Won't the next update still wipe out your system changes, putting you back to insecure openssh password auth, etc., or do they have a system to merge your changes over now?
  - GekkePrutser 5y ago
    Exactly. This is the #1 problem I have with the implementation: I want to set up public-key authentication as the only option on openssh ("Remote Login").
    - dev_tty01 5y ago
      You create and run one fixup script as root to modify /etc/ssh/sshd_config. That is root writable and not protected by SIP. It is a tiny hassle, but really no big deal. The fixup script can handle any of these cases, assuming they are in config files that are writable.
hdjjhhvvhga 5y ago
On the other hand, Linux is getting better and better. And with the prevalence of web apps, the main obstacle to running non (MS | Apple) systems is getting smaller. With Linux, you can adjust the level of security you need and you keep the key. Security improvements appear also in BSDs, especially OpenBSD, but honestly I wouldn't recommend people used to macOS to switch to OpenBSD (yet).
- robbyking 5y ago
  It's the year of the Linux desktop!
  - marricks 5y ago
    It always is! (in a good and bad way)
    - taylorfinley 5y ago
      That's the joke. It's been the 'Year of The Linux Desktop!' at least since my senior year of high school, which was all the way back in 2002.
      - pram 5y ago
        Although you could literally buy a desktop with Linux at Walmart in 2001 so, maybe that actually was the year.
        IncRnd 5y ago
        Except, those quickly disappeared. That's the essence of the joke that was mentioned. Each year was called the year of the Linux Desktop, but it never happened.
        pram 5y ago
        I meant the 'year' had come and gone, 20 years ago.
goodpoint 5y ago
> its security features listen only to Apple and not to the user That's the definition of backdoors.
- tyre 5y ago
  No, it isn’t. The password hint bug, for example, was “only listening to Apple” in the narrow sense that the OS wouldn’t let you run your own implementation of password hints or login. But it’s not a backdoor. There are plenty of built-in features that aren’t configurable, which is fine and good. Because most people have no idea what those things do, most of the rest shouldn’t touch them, and leaving them as configurable or editable opens up a whole class of malware.
nuker 5y ago
> signed system volume for example (also mentioned), while a good idea, lacks a convenient way for the user to make changes to it. MacOS has no convenient way to know if changes are made by the user or malware. It is a feature, not a bug, for most users. Why would you need to change system volume anyway?
- dev_tty01 5y ago
  As others have said, you might want to modify sshd_config. However, I disagree that that is a big deal. Just write a little script to fix whatever you want to modify after a major system upgrade. If you are messing with sshd_config, you should now how to write a script to modify it. It is not protected by SIP. I don't understand why so many unix competent people seem to think this is a big problem.
- tinus_hn 5y ago
  I’d imagine no os has a way to see if changes are made by the user or by malware, otherwise you’d just prevent the changes.

azinman2 5y ago

You can always disable CSR/SIP generally. macOS is unlike iOS in that many security mitigations can be disabled. The fact that new M1 Macs let you side load a diff non-Apple in iOS should be the ultimate proof you need of this motivation to allow user control on Macs.

jchw 5y ago
If one mentions Android’s “openness” as a plus, people (rightly) point out that sure, it is technically open source and you can often sideload, but that doesn’t mean it is friendly towards those things necessarily. A lot of downsides come with rooting and bootloader unlocking after all. That is when comparing to iOS, which is more restrictive than macOS, as you point out. I mention this because I think that it’s good Apple lets you use some of the hardware you own with relatively little restriction if you so choose, but it is a lot less practical than the previous status quo and other systems. You definitely lose some functionality (on M1, I believe you lose at least iOS application support.) If we’re going to be frank about it with Android, I think it’s fair to be frank about it with macOS/M1. I would guess things could be better if user choice was as much of a focus as vendor control.
- ChuckNorris89 5y ago
  >A lot of downsides come with rooting and bootloader unlocking after all. I think you might be confused. You don't need to root or unlock the bootloader on an Android device to side load apps. Just download desired APK and accept the security prompt of installing from unknown sources. It's literally that easy.
  - eropple 5y ago
    Those applications can't get root, though, and that does limit user control of the device. (I used to root Android phones in the 4.x days, and then stopped, and then went back to iOS as I found myself doing progressively less and less with my phone.)
  - deleted 5y ago
    [deleted]
upbeat_general 5y ago
Except doing so doesn’t let you run iOS apps and not to mention is a pain to do so after every update (I believe SSV requires that). The list of things to disable seems to grow every year. Even with Gatekeeper, CSR/SIP disabled I’ll still have issues opening applications which may (or may not) be fixed by taking it out of quarantine, changing the signature, etc
- saagarjha 5y ago
  You can disable SIP once and it will stay off (although maybe not if you do a full system update).
GekkePrutser 5y ago
Yes you can disable it, but then you disable it completely and totally. There is no middle ground. Most of the time these things are totally great ideas. Apple is doing really great work on the security front for sure. It's just what they lack is a way to customise them. Most security improvements they make involve giving Apple the keys and them alone. It doesn't have to be that way. For example I would want to be able to just make an exception for some of the files I want to change.
- Klonoar 5y ago
  There actually is a middle ground, in some cases - csrutil can, for instance, allow you to disable unsigned kext blocking but keep the rest of SIP enabled.
  - GekkePrutser 5y ago
    I thought those were entirely separate things? There's now a GUI option for the unsigned kernel extension block (in the startup security utility). I don't think that's part of SIP per se. It's also the one you need to run any other OS. Whereas SIP is a thing within the OS itself as far as I know. But I have to admit this is where my knowledge gets fuzzy :) The kind of control I'd want is allowing to add a signator for approved kernel extensions. So that I could add my own key and sign kernel extensions myself. Or trust another party to do this. Just like you can add your own keys to Secure Boot on a PC. The same with the app notarisation. Another feature that's essentially great, but fully under the control of Apple. For example, as a corporate admin it'd be great to be able to notarise which apps I'd allow our employees to use. These security tools would be super powerful and useful if we would be allowed to configure them more.
    - easton 5y ago
      If you’re a corporate admin you can whitelist kernel extensions via MDM, maybe that would help? https://support.apple.com/guide/mdm/kernel-extension-policy-payload-settings-mdm88f99b98a/web https://support.apple.com/guide/mdm/kernel-extension-policy-...
cma 5y ago
Won't the next update still wipe out your system changes, putting you back to insecure openssh password auth, etc., or do they have a system to merge your changes over now?
- GekkePrutser 5y ago
  Exactly. This is the #1 problem I have with the implementation: I want to set up public-key authentication as the only option on openssh ("Remote Login").
  - dev_tty01 5y ago
    You create and run one fixup script as root to modify /etc/ssh/sshd_config. That is root writable and not protected by SIP. It is a tiny hassle, but really no big deal. The fixup script can handle any of these cases, assuming they are in config files that are writable.

hdjjhhvvhga 5y ago

On the other hand, Linux is getting better and better. And with the prevalence of web apps, the main obstacle to running non (MS | Apple) systems is getting smaller. With Linux, you can adjust the level of security you need and you keep the key. Security improvements appear also in BSDs, especially OpenBSD, but honestly I wouldn't recommend people used to macOS to switch to OpenBSD (yet).

robbyking 5y ago
It's the year of the Linux desktop!
- marricks 5y ago
  It always is! (in a good and bad way)
  - taylorfinley 5y ago
    That's the joke. It's been the 'Year of The Linux Desktop!' at least since my senior year of high school, which was all the way back in 2002.
    - pram 5y ago
      Although you could literally buy a desktop with Linux at Walmart in 2001 so, maybe that actually was the year.
      - IncRnd 5y ago
        Except, those quickly disappeared. That's the essence of the joke that was mentioned. Each year was called the year of the Linux Desktop, but it never happened.
        pram 5y ago
        I meant the 'year' had come and gone, 20 years ago.

goodpoint 5y ago

> its security features listen only to Apple and not to the user That's the definition of backdoors.

tyre 5y ago
No, it isn’t. The password hint bug, for example, was “only listening to Apple” in the narrow sense that the OS wouldn’t let you run your own implementation of password hints or login. But it’s not a backdoor. There are plenty of built-in features that aren’t configurable, which is fine and good. Because most people have no idea what those things do, most of the rest shouldn’t touch them, and leaving them as configurable or editable opens up a whole class of malware.

nuker 5y ago

> signed system volume for example (also mentioned), while a good idea, lacks a convenient way for the user to make changes to it. MacOS has no convenient way to know if changes are made by the user or malware. It is a feature, not a bug, for most users. Why would you need to change system volume anyway?

dev_tty01 5y ago
As others have said, you might want to modify sshd_config. However, I disagree that that is a big deal. Just write a little script to fix whatever you want to modify after a major system upgrade. If you are messing with sshd_config, you should now how to write a script to modify it. It is not protected by SIP. I don't understand why so many unix competent people seem to think this is a big problem.
tinus_hn 5y ago
I’d imagine no os has a way to see if changes are made by the user or by malware, otherwise you’d just prevent the changes.