Main navigation

Last Week on My Mac: Successful release

I hope, if you have upgraded to Mojave, that all went well and you’re now happy that you made the right decision. Looking around, there seem to be remarkably few problems or regrets. That’s not to say that Mojave has been an instant success, but it doesn’t seem to be the lemon that some had feared.

Apart from a few model-specific problems, such as the strange dislike for the iMac 27-inch Late 2012, 3 TB hard disk with a Boot Camp partition, and ongoing issues with some MacBook Pro 2018s, most who have upgraded seem not to have hit problems, and the support forums are quite quiet.

The biggest issues are centred on Mojave’s new privacy management, TCC, which most of us expected. TCC has actually been around in the background of macOS for quite a few years now, but has been keeping a low profile.

The last time that it was in the news was when DropBox abused Accessibility features two years ago. Since then, it has largely been the concern of those distributing their apps through the App Store. That should have kept TCC away from the limelight, until early September when Trend Micro was caught exfiltrating private data from its App Store apps.

Glance at the headlines, and you’d think that the three vulnerabilities reported so far in TCC rendered it pretty well dead on arrival, and a serious blow to Mojave as a whole. However, at this stage of the cycle, I’m not sure that this is a particularly serious problem, at least not for users.

One of the ‘vulnerabilities’, in which someone can ssh in and then has free access to private data, is surely not accidental. There are several issues involved here, but fundamentally the problem is one of the virtues of ssh: its power. If your Mac has Remote Login enabled and is thereby vulnerable to attack, the privacy of your data is a secondary concern, as it’s a disaster waiting to happen.

On the other hand, trying to impose privacy restrictions on remote connections via ssh is neither a particularly tractable problem, nor one in which any apparent solution would be acceptable. For command tools, TCC uses an Attribution Chain, which tracks privacy permissions upwards in the hope of reaching a caller which can interact with the user. For local commands executed in Terminal, it is Terminal’s ability to fire off a consent dialog which you will notice.

When a system administrator tries to connect to an unresponsive Mac using ssh over a local network, that Attribution Chain lacks a head. The sysadmin might be connecting over VPN from a Linux laptop on a beach in the Bahamas, and for TCC to start asking them for consent would be a real nightmare.

The biggest problem with ssh is not its ability to bypass privacy protection, but the fact that no Mac which has Remote Login enabled has given any warning during Mojave’s configuration that that allows a remote user to bypass TCC’s privacy protection. It is surely enabling Remote Login which needs one of TCC’s dialogs, with a very explicit warning as to what this can do. In response to comment, I discuss these issues further in the Appendix below.

The other two vulnerabilities, announced by Patrick Wardle and Jeff Johnson, shouldn’t be too surprising. Both are real macOS wizards, and I’d be a little disappointed if neither could find a way around TCC at this stage. Given that TCC didn’t reach any sort of maturity until quite late during beta-testing, in August when many developers were on holiday, means that Apple’s ferocious product development cycle hasn’t really allowed much testing by third parties as yet.

What is much more important at this stage is how well Apple responds, and whether these prove to be mere bugs, or more deeply embedded in TCC’s architecture. We should find that out over the coming weeks.

Even then, more persistent issues in TCC’s robustness may not be as important as they might seem now. This is because Mojave’s privacy protection is only a small part of a much bigger change which is happening in macOS. Another important component is ‘Notarization’, which in Mojave is voluntary, but intended at some time in the future to become a requirement of third-party apps which are not delivered by the App Store.

Imagine for a moment if, in macOS 10.15 next autumn/fall, there were four classes of apps and executable code:

Apple’s apps, signed by an Apple certificate and using Apple’s private entitlements and privacy rules;

App Store apps, sandboxed and only able to step outside when they have appropriate ‘entitlements’;

Notarized apps, ‘hardened’ with their own entitlements which are more liberal than those of the App Store, but well-enforced;

Other apps, deemed high risk and only able to be run when the user accepts full responsibility.

Default settings would limit the great majority of users to classes 1-3, and only the most adventurous would elect to enable class 4.

We have seen that it is possible to sneak deceptive apps, perhaps even the occasional item of malware, through class 2, and I’m sure that someone will try with class 3. But, as should have been the case of Trend Micro, deliberately circumventing the rules and protections would prove instantly fatal once detected. If Apple’s screening of class 2 and 3 apps is thorough enough, it could make it practically impossible to get a deceptive app approved either for the Store or for notarization.

This would also reduce any reliance on the detection or removal of conventional malware, making XProtect and MRT almost vestigial.

Apple needs to get TCC and its protection right. Given its relative immaturity, it has actually got off to a good start, as has Mojave. As others have pointed out, even if the new privacy protection is quite limited, it can only be an improvement on High Sierra, and at least APFS is finally of release quality.

Appendix: Remote Login and TCC

Currently, almost all Macs which are running Mojave have been upgraded from an earlier version of macOS which doesn’t enjoy the same privacy protection as that in Mojave. Some/many of those who have upgraded are probably unaware that they have Remote Login enabled, and that that in turn allows someone who connects to that Mac using ssh to access data which they would reasonably presume should now be protected.

It would not be difficult for Apple to incorporate a valuable step in the initial configuration of the upgraded system in which Remote Login status is assessed. If it is enabled, then the user should be advised of the fact that this would enable a remote user to bypass their privacy protection, and to offer as a default to disable Remote Login. I believe that many of those who currently have Remote Login enabled would choose then to follow that default and to disable it.

I do not know whether Apple’s default setup for new Mojave installations is to enable or disable Remote Login. Experience tells me that this isn’t always consistent: it is only a couple of years ago that batches of new MacBook Pros were delivered with SIP disabled by default! However, I believe that all new Macs should by default be configured with Remote Login disabled.

Regardless of whether Mojave was installed as an upgrade or as the initial version of macOS on a Mac, enabling Remote Login necessarily changes privacy protection on that Mac. Therefore, whenever a user enables Remote Login, they should be alerted by a dialog informing them that this will enable a remote user to bypass all the privacy protection on that Mac.

I should have guessed that trying to wrap these issues up in just two sentences was probably a bit optimistic, and my original statement misleading.

I accept that the original claim that I made in this article that “The biggest problem with ssh is not its ability to bypass privacy protection, but the fact that by default Remote Login is enabled in most, if not all, macOS installations” is not accurate, for which I apologise. Remote Login is though enabled on a great many Macs, but no user has been alerted during the Mojave setup or upgrade process that that allows a remote user to bypass their privacy protection by connecting using ssh. That needs to change.

Thank you.
Yes, I have seen a few similar comments. The difficulty is working out common features which might suggest a pattern. At the moment, it seems confined to a few users on a range of different MacBook Pro models, some of which are using FileVault on the boot volume. It’s not even clear whether FileVault is a common factor.
Is it that common? That’s very hard to know. Given the huge numbers of Macs which have been upgraded, it currently looks quite rare.
Throughout the betas, my boot times were very slow, but that was to the appearance of the Apple logo, and I was booting Mojave from an external SSD. Since upgrading the internal SSD from 10.13.6 to 10.14, every boot here has consistently been around 10 seconds.
Hopefully a pattern will become clear, and Apple will be able to address whatever the problem is.
Howard.

In my case You are right. FileVault is enabled. But I think there must be some other problem, because after let´s say 2min waiting and see the loginscreen my desktop appears. Than I see the Wheel-of-death an another 2min nothing happens. Animated Dock sticks and the whole desktop freeze.
After this everything seems to work right, but the first opening of programs (e.g. skype) will take another 1-2min.
And this appearce everytime I logout and login!

I’d still split #4 into #4 and #5, i.e. #4 apps code-signed with an Apple dev cert (or another cert; see below), but not hardened/notarized, and #5 unsigned apps (“Allow all apps”). I would keep #5 a secret setting, only accessible via Terminal.

But what I’d like Apple to do is to include in #4 other code signing certificates. Some open source developers use Comodo code signing certs, some use self-issued certificates, and I would like to use my own self-signed certs for all my local stuff, and while macOS should definitely not accept these by default, it should be allowed if the user imports the 3rd-party certs and manually enables the trust in Keychain Access.

I think the lesson for 2018 (if not before) is that code signing alone is now insufficient to do anything other than get in the way of non-developers writing their own scripts. Allowing the user to run code other than that in 1-3 exposes them to risk that the average user shouldn’t be going near.
On the other hand, there are macOS users who need to be able to run code in class 4. Trying to make fine distinctions between degrees of risk there is both unnecessary and misleading, given that most macOS malware is now signed with a developer ID. So why make the system even more complicated?
Howard.

It’s been a long time since I did a clean install of macOS, but I’m pretty sure that no new installation on any of my computers has ever had remote login/ssh enabled by default, and I’m surprised to hear you say otherwise.

It was on this MacBook Pro 2017.
Besides, my point here is that TCC should surely warn the user if they enable Remote Login that this will enable those who connect to access protected data. At the moment, there is no such warning, is there?
Howard.

I’m sorry, I thought you said: “The biggest problem with ssh is not its ability to bypass privacy protection, but the fact that by default Remote Login is enabled in most, if not all, macOS installations.”

That seemed to be your point.

Since OS X 10.2 the first thing I’ve always done after install is to go to System Preferences and enable ssh. You say that’s changed, but I have to admit I won’t be convinced until I install a new copy of macOS somewhere and see it for myself – there’s no shortage of articles on the web telling users how to do that.

In fairness, you have there quoted the first of two sentences in their own paragraph.
However, for the sake of clarity I have now expanded and explained in an Appendix. I hope this makes my points more explicit.
Howard.

Hi Howard, just regarding your concerns about Remote Login in Sharing Settings: I just don’t think it is ‘on by default’ on macOS installations. I have Remote Login Off, I don’t remember to switch it off my self, so probably it was like that by default. I checked our 3 other Macs, they all have Remote Login Off, even the Mojave upgraded from Sierra 10.12.6 has this Off.

Otherwise, true, it would be really thread to macOS Security. But I don’t believe that Apple would go into this sensitive setting by default leaving thousands of Macs vulnerable.

Another commenter suggested adding a Class 5; I’d also add a Class 6: apps I developed myself for my own use — which I might very well want to do without opening myself to the risks of Class 4 apps from other developers.

Although that’s a good idea, I’d be interested to know how you might test for such an app. For most users, those would be apps without a signature, or self-signed, which isn’t a very helpful class!
Howard.

That’s what I had as part of Class #4: codesigned non-notarized apps, not only those signed with an Apple cert, but also self-issued certs for running stuff locally, or certs by Comodo etc. If you want to distribute a non-Apple-signed app, which some developers do, then you should give the user the option to locally authorize these non-Apple-issued certificates and manually elevate e.g. a self-signed app to basically the same status as an Apple-signed app—with the system giving you an appropriate security warning. Currently it’s a hassle: you can export the certificate (or certificate chain) with the codesign CLI, and you can import these certificates into the macOS keychain, where you can also trust them, but it doesn’t have any effect on Gatekeeper behavior.

Yes, it is Xcode 10 only. There is a tool provided to ‘staple’ the notarization certificate to a hardened app, but as far as I can see at present, there isn’t command line support for ‘hardening’ an app (a pre-requisite), nor for submitting it to Apple for the notarization process.
You can only get apps with bundles notarized at present: there’s no support in Xcode for notarizing command tools.
It is a very new scheme. Hopefully it will grow and become more flexible in the coming months.
Of course, it may never be required for command tools even in the future.
Howard.

Hey my problem “long startup” was Little Snitch. Didn´t know why, but aufter deinstall my mac boots up within 20sec! Another thing I didn´t understand is a slaggy open-dialog in some apps. Oenoffice, pages, keynote, safari and many other works fine (subsecond). But taccy, bbedit and other take 20-30 Seconds and die console is flut with listings. Did You know why?

It says “app translocation” in there, so Gatekeeper seems to be launching the app from a secret read-only DMG in /private/var/folders, which might account for the laggy behavior. Try to unquarantine the app with `xattr -dr com.apple.quarantine /path/to/App.app`.

Hey my problem “long startup” was Little Snitch. Didn´t know why, but aufter deinstall my mac boots up within 20sec! Another thing I didn´t understand is a slaggy open-dialog in some apps. Oenoffice, pages, keynote, safari and many other works fine (subsecond). But taccy, bbedit and other take 20-30 Seconds and die console is flut with listings. Did You know why?

First, check that your boot disk is in the right format. One way to do this is in Recovery mode, using Disk Utility from there.
If the format looks good, I would be tempted to re-install Mojave. I think that should fix these problems. There’s nothing unusual in the log excerpt which you have provided – if you look through my recent articles here on apps starting up and booting macOS 10.14, you’ll see many similar entries. But they should be taking over 20 seconds – that shows that there’s something wrong, either with your disk format or macOS installation.
Howard.