{"id":38696,"date":"2023-03-07T14:51:11","date_gmt":"2023-03-07T19:51:11","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=38696"},"modified":"2023-03-07T14:51:11","modified_gmt":"2023-03-07T19:51:11","slug":"how-troubleshooting-has-changed-with-macos-security","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2023\/03\/07\/how-troubleshooting-has-changed-with-macos-security\/","title":{"rendered":"How Troubleshooting Has Changed With macOS Security"},"content":{"rendered":"

Howard Oakley<\/a>:<\/p>\n

\n

With the guaranteed integrity of the SSV and cryptexes on IT2 and AS models, reinstalling the same version of macOS has no effect on the great majority of macOS. Similarly, installing an older version and updating it to the current one can only produce exactly the same result as installing the current version directly.<\/p>\n

Two procedures might be worth considering, though: replacing the latest version of macOS with an older one, in an attempt to clear new problems, and installing macOS and migrating to it from backups. Both of these can also make problems worse as they rely on migration, which could restore other components responsible for a problem, or those incompatible with the version of macOS being installed.<\/p>\n

[…]<\/p>\n

Just as successfully booting macOS is verification of its integrity, so launching an app without a code signature error verifies the code within that app. That applies to all Macs running Ventura, where replacing a misbehaving app with a fresh copy is likely to be pointless.<\/p>\n<\/blockquote>\n

Most non-bug problems these days seem to be caused by bad data files or file permissions.<\/p>\n\n

Howard Oakley<\/a>:<\/p>\n

\n

Every time you run an app or other executable code, such as a command tool, those first run checks are now repeated, although not quite in the same depth, and with slightly greater tolerance for minor errors, it appears.<\/p>\n

[…]<\/p>\n

This shows how Apparency reports an app I crafted to check whether macOS had fixed a longstanding vulnerability in signature checking. Code signatures apply to different architectures, including Intel and Apple silicon. For some time, Gatekeeper checks didn’t cover all architectures correctly, a failure which could have been exploited. This crafted version of my app Cormorant contains two conflicting signatures, as recognised by Apparency.<\/p>\n

[…]<\/p>\n

Certificate expiry dates are a little more complicated than you might expect, and depend on the type and purpose of certificate. For ordinary app and other executable signing, a Developer ID Application<\/em> certificate is used, and remains valid for Gatekeeper even though the certificate has long expired. The crucial date in this case is when the app was signed: so long as the Developer ID Application certificate was valid at that time, then Gatekeeper will accept the certificate many years later.<\/p>\n

That isn’t true of certificates used to sign Installer packages, which are a different type, Developer ID Installer.<\/em><\/p>\n<\/blockquote>\n\n

Previously:<\/p>\n