© Joe Raedle/Getty Images
If your Mac is running macOS Sequoia version 15.2 and you keep an eye on its security data updates, you may have noticed that those have changed again. Perhaps the only way to make sense of what has happened is to understand how XProtect updates work in recent versions of macOS.
Before doing that, there are two important issues to make clear:
Login
softwareupdate mechanism, and that hasn’t changed.Like other security data updates including XProtect Remediator, XProtect is updated through Software Update, or the command tool softwareupdate, which is how SilentKnight obtains its updates too. Shortly after starting up, and at least daily after that, your Mac’s softwareupdated service contacts Apple’s software update servers and checks whether there are any updates available. If there are, they’ll be automatically downloaded and installed, provided that’s enabled in System Settings.
In this case, XProtect is installed in its traditional place, in /Library/Apple/System/Library/CoreServices as XProtect.bundle.
For this brief period, XProtect updates have been available using either of two methods.
The traditional method using Software Update or softwareupdate continues to install the XProtect bundle in its old location, where it could still be used, but the XProtect service in Sequoia expects to find it in a different location, in /private/var/protected/xprotect, where it’s still known as XProtect.bundle.
The new method installs the XProtect bundle directly into its new location, and doesn’t obtain it using Software Update or softwareupdated, but an undocumented service that connects to iCloud instead. That appears to activate at least once a day, independent of softwareupdated, and silently checks for XProtect updates in iCloud. When it finds one, that’s installed directly to /private/var/protected/xprotect but not the traditional location in /Library/Apple/System/Library/CoreServices. It’s therefore perfectly possible for the two XProtects to get out of sync, although the only one that Sequoia uses is that stored in the new location.
Sequoia also introduces a new command tool xprotect to help manage these new updates. If you runsudo xprotect update
and the version of the XProtect bundle in the traditional location is greater than that in the new location, then the newer version will be copied to the new location to install it there as an update, instead of having to wait for the update through the new iCloud mechanism. This also provides redundancy, but relies on the two sources providing identical updates.
To add a final twist of confusion, if xprotect copies the XProtect bundle from the traditional to the new location, it does so by copying its contents, so its version number changes but the bundle itself retains its previous date of creation and modification, which can prove thoroughly confusing. The lesson here is to check the bundle by its version number, not by its dates.
In the latest release of Sequoia, the traditional method of updating XProtect is no longer used. If softwareupdate were to download and install an update, then it will only end up in the traditional location, and xprotect update can’t use that to update the new location.
In normal use, this means that the user can’t update XProtect until that new version is made available from iCloud. This ensures that the only versions provided to Macs running 15.2 and later are those intended to be used in Sequoia, but it also means that any delay in providing those via iCloud will leave Macs without the latest update.
Apple has modified the xprotect command to provide one let-out, though: usesudo xprotect update --prerelease
and it “will attempt to use a prerelease update, if available.” Note that still can’t use a traditional XProtect update installed in the traditional location, and still has to be able to obtain the update from iCloud, but it might work when xprotect check and xprotect update can’t offer a new update yet. Note that Apple describes that early-bird version as prerelease, and it shouldn’t therefore be used as if it’s a regular release, and only for good reasons.
Because of these changes, as of Sequoia 15.2, SilentKnight is no longer able to provide any assistance in updating XProtect, and its next version 3.0 will also be unable to do anything more useful than inform you that your current version of XProtect is up to date, or out of date. If it is out of date, then it’s up to you what you decide to do about it. In most cases, that should be to leave well alone and let macOS handle the update as it’s intended to.
Because time of release of XProtect updates through softwareupdate and iCloud differ, and vary around the world, availability from one source is no guarantee that the other will also be offering that update. For example, on 17 December, the softwareupdate version became available by about 1830 GMT. A prerelease version for 15.2 was available several hours before that, but the regular release wasn’t available from iCloud until early the following day. If Apple is intending to fork XProtect data for 15.x from those for older versions of macOS, the two update services will be offering quite different bundles anyway, as we experienced briefly in the early days of Sequoia.
Although I do periodically poll traditional softwareupdate servers for new updates, repeatedly doing so for iCloud updates doesn’t appear a good way to proceed, and could in any case be misleading. On the other hand I don’t think it’s intended that apps like SilentKnight should check for prerelease updates as a matter of course, and abuse of that option could lead to its removal. In other words, Apple wants full control over when your Mac can and will update to new versions of XProtect, presumably because Sequoia will be getting different updates in the future.
xprotect command in Terminal. While SilentKnight and Skint will warn you when an XProtect update is expected, you should rely on macOS to handle those updates for you.
Apple has just released updates to XProtect for all supported versions of macOS, bringing it to version 5284, and to XProtect Remediator for all macOS from Catalina onwards, to version 149. As usual, Apple doesn’t release information about what security issues these updates might add or change.
Yara definitions in this version of XProtect augment existing rules for dylibs in MACOS.ADLOAD, and add 2 new rules for MACOS.DOLITTLE, 1 for MACOS.PIRRIT, 5 for MACOS.BUNDLORE and 5 for MACOS.ADLOAD.
XProtect Remediator adds a new scanner module for Bundlore. There are no changes to Bastion rules for the behavioural version of XProtect (Ventura and later).
You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.
A full listing of security data file versions is given by SilentKnight, LockRattler and SystHist for El Capitan to Sequoia available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight, LockRattler, or at the command line.
If you want to install these as named updates in SilentKnight, their labels are XProtectPayloads_10_15-149 and XProtectPlistConfigData_10_15-5284.
For Sequoia 15.2 and later only: XProtect updates are no longer supplied through Software Update, softwareupdate, or SilentKnight. The only way that your Mac can obtain XProtect updates is through a connection to iCloud, which is supposed to happen automatically. If your Mac hasn’t yet been updated to version 5284, you can try using the Terminal commandsudo xprotect update --prerelease
(with a double hyphen not an m-dash)
That should download and install this update even though it hasn’t yet been generally released through iCloud.
For Sequoia 15.1.1 and earlier only: this update hasn’t yet appeared in iCloud, which may still return an XProtect version of 5283. If you download and install it using Software Update, softwareupdate or SilentKnight, then once that’s complete you need to update the primary XProtect bundle in Terminal using the commandsudo xprotect update
then entering your admin password. If you’re unsure what to do, this article explains it comprehensively and simply.
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
I maintain lists of the current versions of security data files for Sequoia on this page, for Sonoma on this page, Ventura on this page, Monterey on this page, Big Sur on this page, Catalina on this page, Mojave on this page, High Sierra on this page, Sierra on this page, and El Capitan on this page.
[Updated blind-guessing the changes in 15.2, at 2030 GMT 17 December 2024.]
The macOS 15.2 update includes the second phase of AI support for Apple silicon Macs, introducing the Image Playground app, and integrated ChatGPT support in both Siri and Writing Tools. AI now extends support to several of the non-US variants of English, including English (UK), although non-English languages won’t gain support until next year.
Apple’s release notes are a real joy to read and contain more detailed information at last, including the following:
Among the more significant bugs fixed is that Apple silicon virtualisation on M4 Macs can now open all VMs, including macOS guests before 13.4. For those running Ruby with YJIT enabled, this update should fix kernel panics with M4 chips. Further fixes are detailed in the developer release notes, and enterprise release notes are here.
Security release notes are available here, and list 42 entries including 4 in the kernel, none of which Apple reports may already have been exploited.
iBoot firmware on Apple silicon Macs is updated to version 11881.61.3, and T2 firmware to 2069.40.2.0.0 (iBridge: 22.16.12093.0.0,0). The macOS build number is 24C101, with kernel version 24.2.0.
Version changes in bundled apps include:
Inevitably, there are many build increments in components related to Apple Intelligence, and a great many across private frameworks. Other significant changes to /System/Library include:
After that lot, the next scheduled update to macOS Sequoia is in the New Year.
As eagerly anticipated, Apple has released the update to macOS 15.2 Sequoia, together with security updates to bring Sonoma to version 14.7.2, and Ventura to 13.7.2. There should also be Safari updates to accompany the latter two.
For Intel Macs, the Sequoia update is 2.72 GB in size, and for Apple silicon models it’s 3.45 GB.
Security release notes for Sequoia list 42 vulnerabilities fixed in the 15.2 update, including four in the kernel, although none are noted as being currently exploited. Release notes for Sonoma list 25, and those for Ventura list just 22.
iBoot is updated to version 11881.61.3 on Apple silicon Macs, and Intel Macs with T2 chips have their firmware updated to 2069.40.2.0.0, iBridge 22.16.12093.0.0,0. Sequoia 15.2 brings Safari version 18.2 (20620.1.16.11.8).
Later tonight I hope to post a summary of changes in 15.2, in a separate article as usual.
[Updated 1938 GMT 11 December 2024.]
Apple has just released an update to XProtect for all supported versions of macOS, bringing it to version 5283. As usual, Apple doesn’t release information about what security issues this update might add or change.
This version adds new rules for MACOS.DUBROBBER.F2 and MACOS.DUBROBBER.H2, and modifies that for MACOS.DUBROBBER.G.
You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.
A full listing of security data file versions is given by SilentKnight, LockRattler and SystHist for El Capitan to Sequoia available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight, LockRattler, or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5283.
For Sequoia only: this update has now been made available in iCloud, which should return an XProtect version of 5283. If you download and install it using Software Update, softwareupdate or SilentKnight, then once that’s complete you need to update the primary XProtect bundle in Terminal using the commandsudo xprotect update
then entering your admin password. If you’re unsure what to do, this article explains it comprehensively and simply.
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
I maintain lists of the current versions of security data files for Sequoia on this page, for Sonoma on this page, Ventura on this page, Monterey on this page, Big Sur on this page, Catalina on this page, Mojave on this page, High Sierra on this page, Sierra on this page, and El Capitan on this page.
Updated 2242 GMT 19 November 2024.
Apple has just released an update to macOS Sequoia, bringing it to version 15.1.1, build 24B91 (all Macs other than M4) or 24B2091 (M4 Macs only). This brings two important security fixes, to JavaScriptCore and WebKit, both of which Apple believes may already have been exploited. The update should be less than 800 MB to download.
Safari is updated to version 18.1.1 (20619.2.8.11.12). There are also matching updates to Safari available for Sonoma and Ventura, addressing the same vulnerabilities.
Security release notes are here.
(Last updated at 1722 GMT 20 November 2024.)
Apple has just released an update to XProtect for all supported versions of macOS, bringing it to version 5282. The last version released was 5279. As usual, Apple doesn’t release information about what security issues this update might add or change.
Relative to the last version released for all supported versions of macOS (5279), this version renames several existing rules, as MACOS.DUBROBBER.A to MACOS.DUBROBBER.E, and adds new rules for MACOS.DUBROBBER.F, MACOS.DUBROBBER.G and MACOS.DUBROBBER.H. It also adds a new rule for MACOS.TAILGATOR.
You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.
A full listing of security data file versions is given by SilentKnight, LockRattler and SystHist for El Capitan to Sequoia available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight, LockRattler, or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5282.
For Sequoia only: this update has already been made available in iCloud, which now returns an XProtect version of 5282. If you download and install it using Software Update, softwareupdate or SilentKnight, then once that’s complete you need to update the primary XProtect bundle in Terminal using the commandsudo xprotect update
then entering your admin password. If you’re unsure what to do, this article explains it comprehensively and simply.
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
I maintain lists of the current versions of security data files for Sequoia on this page, for Sonoma on this page, Ventura on this page, Monterey on this page, Big Sur on this page, Catalina on this page, Mojave on this page, High Sierra on this page, Sierra on this page, and El Capitan on this page.
For the first 15 years of Classic Mac OS, right up to Mac OS 9 in 1999, Macs remained fundamentally single-user, and privacy wasn’t an issue of much concern. In those halcyon years of desktop publishing and HyperCard, users were more excited by opening information up than keeping it private, and the internet was in its infancy. It was Mac OS 9 that first integrated multiple user accounts and started to secure information using keychains.
Mac OS X brought the first full multi-user operating system to the Mac, but as internet connections became increasingly common and lasting, little attention was paid to privacy. By 2011, the Privacy tab in Security & Privacy, then in System Preferences, contained just three items: Location Services, Contacts, and Diagnostics & Usage. While privacy features developed elsewhere, for the sake of simplicity I’ll here focus on that pane in System Preferences, and its successor in System Settings.
Four years later, in OS X 10.10 Yosemite (2015) and still in 10.12 Sierra (2017), those three items had grown to eight, with the addition of Calendars, Reminders, Accessibility, and two social media platforms, Twitter and Facebook.
Then at WWDC in 2018, Apple revealed its new privacy architecture, putting it at the forefront in macOS 10.14 Mojave, and eventually reversing the order to Privacy & Security.
Mojave protected information in the following 15 categories:
Its new protection system was dubbed TCC, for Transparency Consent and Control, and has since become prominent in the nightmares of developers, those who support Macs and many who use them. At its worst, it crashes apps that don’t comply with its rules, as shown in the diagram below for macOS 10.14.
Various classes of protected data are shown at the left, those in red being covered explicitly in Privacy controls. The first step was to determine whether the app trying to access protected data was signed by Apple: if it was, access was determined by private controls, and sometimes regular controls as well.
Apps developed by third parties were checked to see whether they already had access to that particular class of protected data according to Privacy settings. If they had, access was then granted without further dialogs. Note that the effect of adding an app to the Full Disk Access list was to give it access to all protected data, but not services or hardware, without any further consent being sought.
If they hadn’t already been given access, the next check was to see which version of the SDK they were built against. If they were built against 10.13 or earlier, then Mojave didn’t expect them to have support such as usage information, so it should have displayed a dialog inviting consent to the requested access. That would normally only contain the standard text information.
If consent was given, then that app was added to the appropriate class in Privacy settings; if it was declined, then it was denied access, but wasn’t put on any blacklist, so consent could still be given on another occasion.
If the app was built against the 10.14 SDK, then stricter rules were applied. It was then required to have a usage statement for the class of data it was trying to access, where that was in the class-specific list at the top, or a protected device or service. If the app didn’t provide the appropriate usage statement, TCC considered the request to access protected data was unintended, and crashed the app as an ‘unexpected quit’.
If the app did contain a usage statement appropriate for that class of protected data, then Mojave displayed the consent dialog, this time containing the text from that usage statement as well. If consent was then given, the app would be added to the list in Privacy.
Since Mojave, TCC has been a fertile source of vulnerabilities for third-party researchers to discover, and the malicious to exploit. Three were reported shortly after the initial release of 10.14. Two, discovered by Patrick Wardle and Jeff Johnson, weren’t disclosed, to allow Apple to address them, and the third, in ssh, wasn’t so much a vulnerability as a feature that could be exploited.
Each successive major version of macOS has added further to that list from Mojave. Catalina (10.15, 2019) added new locations that required user intent or consent to access, including:
This is one of the late Security & Privacy panes from macOS Catalina in 2019.
By the time that macOS 13 Ventura was released in 2022, its shiny new Privacy & Security section in System Settings listed 20 categories. Some, like Full Disk Access and Files and Folders, overlapped, while others like Accessibility appeared to have been misnamed. Controls provided varied between different categories, and many users dreaded having to tinker with them.
At this rate of growth, Privacy will soon have its own app alongside System Settings.
Apple has just released an update to XProtect for all supported versions of macOS, bringing it to version 5279. As usual, Apple doesn’t release information about what security issues this update might add or change.
Relative to the last version released for all supported versions of macOS (5278), this version makes a small amendment to the detection rule for MACOS.PIRRIT.CHU.
You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.
A full listing of security data file versions is given by SilentKnight, LockRattler and SystHist for El Capitan to Sequoia available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight, LockRattler, or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5279.
For Sequoia only: there’s no sign of this update being made available in iCloud, which now returns an XProtect version of 5278. If you download and install it using Software Update, softwareupdate or SilentKnight, then once that’s complete you need to update the primary XProtect bundle in Terminal using the commandsudo xprotect update
then entering your admin password. If you’re unsure what to do, this article explains it comprehensively and simply.
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
I maintain lists of the current versions of security data files for Sequoia on this page, for Sonoma on this page, Ventura on this page, Monterey on this page, Big Sur on this page, Catalina on this page, Mojave on this page, High Sierra on this page, Sierra on this page, and El Capitan on this page.
Signing and notarization of apps and other executable code is a controversial topic. Over the last decade and more Apple has steadily introduced increasingly demanding standards, now requiring developers to notarize apps and other code they distribute outside the App Store. This article tries to explain why, and how this contributes to Mac security.
I would hope that what we all want is confidence that all executable code that our Mac runs, in particular apps, is exactly as was built by its developer. In addition to that, in the event that any code is found to be malicious, then macOS can promptly protect us by refusing to launch it. The first requirement is thus about verification of apps and code, and the second is about having a system that can block code from being launched in the first place.
The well-proven way to verify that files and bundles haven’t changed is using cryptographic hashes of their contents. Compute a hash, save it in a way that can’t be tampered with, and you can verify a bundle by recomputing its hash and confirming that it hasn’t changed. Apple has been using this for a long time, and its approach is a little more complex, as explained in detail in this excellent tech note.
When an app is signed, hashes are computed for different parts of its contents and assembled into a code directory, a data structure rather than a folder/directory. That data structure is then hashed to form the cdhash, or CDHash with mixed case to aid its reading. Because it’s a hash of hashes, it uniquely identifies that app, bundle or other executable code. CDHashes are thus part of the signing process, and the signature contains those CDHashes. They are also part of the notarization process, in which Apple’s Notary Service signs the CDHashes for code when it undergoes notarization, and that forms the notarization ticket that’s issued for that app, and normally attached or ‘stapled’ to it.
Between them, code signing and notarization thus provide two levels of verification, in a signature attached to the code itself, and in a record kept by Apple following successful notarization.
An unsigned app has no CDHashes, so its contents are uncontrolled and no verification is possible. It can change its own contents, morph itself from benign to malicious, forge its identity by posing as a completely different app, or be hijacked to run malicious code. While macOS could compute its CDHashes and Apple could try to track them, there’s no way to verify its identity, so external checks aren’t feasible, and there’s no way to block the code from being launched, as all it would need to do to evade that would be to change itself so its CDHashes changed.
Although macOS running on Intel Macs long tolerated this, from their release four years ago, Apple silicon Macs have refused to run such unsigned code.
Since Apple required code to be signed for Apple silicon Macs, all self-respecting build systems for macOS have automatically signed the code they generate. However, unless the developer has a certificate issued by Apple, by default they use ‘ad hoc’ certificates that are created locally and lack any chain of trust. That enables anyone to create CDHashes at any time, without any traceability to a trusted root certificate.
This is a slight improvement on completely unsigned code, and does enable an app to be identified by its CDHashes, but as they’re so easy to create, there’s no reliable way to verify that the app hasn’t changed since its original build. Although Apple could try to collect those CDHashes, there’s no useful way to block code from being launched, as all an adversary needs is to resign the code to change its CDHashes: they’re simply too labile to be trustworthy.
For many years, before Apple introduced notarization over six years ago, this was the standard expected, but not required, of apps distributed by third-party developers. Although in theory developers could have used certificates provided by other authorities, not all Certificate Authorities are equal in their diligence, and Apple rightly wanted to be responsible for all revocations.
Certificates add control and verification, within limits determined by the certificate user. CDHashes gathered from code can be collected, but again their provenance relies on their user. At one time, they were commonly abused by those distributing malicious software. Although abused certificates were revoked by Apple, before that could happen, the malware had to be detected and identified, which could allow it to be run by many users for long before it could be blocked.
Certificate checks were another problem with this approach. It isn’t practical to check each certificate every time code is to be launched, so approvals have to be cached locally, adding to the delay before any revocation becomes effective.
To address the limitations of signing code using developer certificates, Apple introduced the process of notarization. In this context, it adds:
This finally checks the provenance of all code being run, through its CDHashes; if they’re not already known to Apple, then that build of the app can’t have been notarized, and can be blocked from launching, provided the user doesn’t disable notarization checks. Screening for malware forces those trying to get malicious code notarized to adopt techniques of obfuscation, but even if those are successful, Apple already has a copy of that app and its CDHashes. That eliminates much of the delay incurred by certificate-signed apps. Together these have proved sufficient disincentive to malware developers to try to abuse notarization.
Key features of notarization are thus:
If you can come up with a system that achieves those and could replace notarization, I’m sure that Apple would love to hear of it.
One of the novel features in the original Finder in Classic Mac OS was the use of distinctive icons for different types of document in an extensible scheme.
Every file had its type and creator codes, each consisting of four single-byte characters. The Desktop databases contained indexes to those, to enable the Finder to display the appropriate icon for a text document of type TEXT created by an app with the creator code of ttxt, SimpleText, for instance.
Apps provided a custom icon in their Resource fork for each type of document they supported. Periodically, those Desktop databases became broken, and documents lost their custom icons. The solution was to rebuild those Desktop databases from the data in each app’s Resources, a procedure that every Mac user became only too familiar with.
At some stage, perhaps in System 6 of 1988, or System 7 of 1991, document icons such as images could be displayed as miniatures or thumbnails instead. This was accomplished by apps creating that file’s thumbnail and saving it as an ICN# resource in the file’s Resource fork. Amazingly, this still works in Sequoia, where I pasted a prepared Resource fork into a Zip file to give it an inappropriate thumbnail.
The raw Resource fork is shown below in xattred as a com.apple.ResourceFork extended attribute.
Initially, Mac OS X continued a similar system, including custom thumbnails, until Apple introduced Quick Look in Mac OS X 10.5 Leopard, in 2007. This came with built-in support for a wide range of common document types, extending to QuickTime media including audio and video. One curious omission at first was that animated GIFs weren’t supported as animations until OS X 10.7.
Display of Thumbnails used the QuickLook framework documented here. This enabled third-parties to extend coverage to their own document types using QuickLook generators with the extension .qlgenerator. Initially, they were installed into /Library/QuickLook from each app bundle.
Normally, when QuickLook generated a Thumbnail or Preview, that was stored in its cache database kept in NSTemporaryDirectory in the path C/com.apple.QuickLook.thumbnailcache/. Those could give revealing insights into images and other documents accessed recently, and Wojciech Regula and Patrick Wardle discovered that, in High Sierra and earlier, it was easy for malicious software to examine that cache. Apple addressed that in macOS 10.14 Mojave by making the cache completely inaccessible.
In-memory caching of Thumbnails has also proved controversial in more recent versions of macOS. To deliver smooth scrolling of Thumbnails in the Finder’s Gallery views in particular, the Finder has taken to caching them in memory for up to two days, sometimes using several GB in the process. That can readily be mistaken for a memory leak, until those cached Thumbnails are finally flushed.
I described how QuickLook Thumbnails worked in early 2019, in the days before the SSV.
When you select a document in the Finder, a dialog, or somewhere else where you expect its icon to be shown, the Finder passes details of the document path and its type (UTI) to IconServices, to fetch the appropriate icon. This calls on its main service, iconservicesd in /System/Library/CoreServices, to check its icon cache.
Although the main icon store is locked away in /Library/Caches/com.apple.iconservices.store, there’s additional data in a folder on a path based on /private/var/folders/…/C/com.apple.iconservices, where … is an unreadable alphanumeric name. For icons used in the Dock, their cache is at /private/var/folders/…/C/com.apple.dock.iconcache. If the icon should be replaced by a QuickLook Thumbnail, such as in a Finder column view, QuickLook is asked to provide that thumbnail. That in turn may be cached in its protected cache at /private/var/folders/…/C/com.apple.QuickLook.thumbnailcache.
QuickLook then relies on there being an appropriate qlgenerator to create a thumbnail of that document type; if the qlgenerator is flawed or can’t cope with the document’s contents, that could easily fall over. For example, if you renamed a text file with a .jpeg extension so that macOS considered it was a JPEG image, the bundled qlgenerator might have simply resulted in the display of a busy spinner, rather than resolving to a generic JPEG document icon. IconServices should then deliver the appropriate icon back to the Finder to display it.
In macOS 10.15 Catalina (2019), Apple started replacing this system with a new framework named QuickLook Thumbnailing, documented here. That replaces qlgenerators with QuickLook preview extensions, in particular Thumbnail Extensions, as explained to developers at WWDC in 2019.
macOS 15.0 Sequoia has finally removed support for qlgenerators. That has resulted in the unfortunate loss of custom Thumbnails and Previews for document types of third-party apps that are still reliant on qlgenerators, and haven’t yet got round to providing equivalent app extensions. It’s almost as if the Desktop databases need to be rebuilt again.
Modern Macs and macOS feature multiple layers of protection, most of which I have recently described. This article tries to assemble them into an overview to see how they all fit together, and protect your Mac from startup to shutdown. There are also many additional options in macOS and third-party products that can augment security, but I’ll here concentrate on making best use of those that come with a modern Mac and macOS. My recommendations are for the ‘standard’ user, as a starting point. If your needs differ, then you may of course choose to be different, but should always do so in the full knowledge of what you are doing and what its penalties are.
Whether your Mac has a T2 or Apple silicon chip, it’s designed to boot securely, which means that every stage of the boot process, from its Boot ROM to running the kernel and its extensions, is verified as being as Apple intends. To ensure that, your Mac should run at Full Security. For a T2 model, that means disabling its ability to boot from external disks; for an Apple silicon Mac, that means no third-party kernel extensions. If you need to run your Mac at reduced security, that should be an informed decision when there’s no good alternative.
A vital part of the Secure Boot process is the firmware loaded by the Boot ROM. That needs to be kept up to date by updating to the latest minor release of the major version of macOS. That doesn’t prevent your Mac from staying with an older supported version of macOS, as Apple supplies the same firmware updates for all three supported versions of macOS.
The System volume should be signed and sealed, as the SSV created by a macOS installer or updater. System Integrity Protection (SIP) should also be fully enabled, as without it many macOS security features work differently or not at all. Some need to disable specific SIP features, but again that should only be set when you’re fully aware of their effects and consequences, and should be the minimum needed for the purpose.
Having got the system up and running, the boot process moves to what is in mutable storage on the Mac’s Data volume. In the internal SSD of a modern Mac, that’s always encrypted, thanks to the Secure Enclave. Although that might appear sufficient, you should always turn FileVault on if your Mac starts up from its internal SSD. That ensures the encryption is protected by your password: an intruder then has to know your password before they can unlock the contents of its Data volume. They have limited attempts to guess that password before the Mac locks them out from making any further attempts. As FileVault comes free from any performance penalty, there’s no good reason for not using it.
Good security is even more important for Data volumes on external boot disks, where FileVault is just as important, but needs additional physical measures to ensure the external disk isn’t mislaid or stolen. That’s a more complex issue, for which the simplest solution is to start your Mac up from its internal SSD with the benefit from FileVault there.
With the user logged in successfully, and the Data volume fully accessible, the next stage to consider is running apps and other software. For this there’s another series of security layers.
When an app is launched or other code run, Gatekeeper will first check it, and in many circumstances run a check for malware using XProtect. Those shouldn’t be disabled, or macOS will still make those checks, but will simply ignore the results. XProtect looks for evidence that the code about to be run matches that of known malware. Although on its own this won’t detect unknown malware, it’s an effective screen against what’s most common. You also need to keep your Mac up to date with the latest security data updates, as those can change every week or two as new malware is identified and included.
Currently, no well-known malware has been notarized by Apple, and most isn’t even signed using a trusted developer certificate. Most therefore attempt to trick you into bypassing checks made by macOS. In Sonoma and earlier, the most common is to show you how to use the Finder’s Open command to bypass the requirement for notarization. As that has changed in Sequoia, those who develop malware have had to adapt, and some now try to trick you into dropping a malicious script into Terminal. Expect these to become more sophisticated and persuasive as more upgrade to Sequoia.
There are simple rules you can apply to avoid getting caught by these. The first time you run any new app supplied outside macOS or the App Store, drag the app to your Applications folder and double-click it in the Finder to open it. If it can’t be launched that way, don’t be tempted to use the Finder’s Open bypass, or (in Sequoia) to enable the app in Privacy & Security settings. Instead, ask its developer why it isn’t correctly notarized. Never use an unconventional method to launch an app: that’s a giveaway that it’s malicious and you shouldn’t go anywhere near it.
macOS now checks the hashes (CDHashes) of apps and code it doesn’t already recognise, for notarization and known malware. Those checks are run over a connection to iCloud that doesn’t need the user to be signed in. Don’t intentionally or inadvertently block those connections, for instance using a software firewall, as they’re in your interest.
Traditional Unix permissions weren’t intended to protect your privacy. Now so many of us keep important or valuable secrets in our Home folders, privacy protection is essential. While you might trust an app to check through some files, you may not expect or want that app to be looking up details of your bank cards and accounts.
Privacy protection is centred on a system known as TCC (Transparency, Consent and Control), and its labyrinthine Privacy & Security settings. One of the most tedious but important routine tasks is to check through these every so often to ensure that nothing is getting access to what it shouldn’t.
No matter how conscientious we might be, there’s always the request for access that you don’t have time to read properly, or items that end up getting peculiar consents, like a text editor that has access to your Photos library or your Mac’s camera. Take the time to check through each category and disable those you don’t think are in your best interests. If you get through a lot of new apps, you might need to do this every week or two, but it needn’t be as frequent in normal use, and shouldn’t become an obsession.
There’s some dispute over whether it’s better to leave an app turned off in a category that you control, like Full Disk Access, or to remove it. I tend to disable rather than remove, with the intention of removal later, but seldom get round to that.
While macOS continues checking apps in Gatekeeper and XProtect, there are a couple of other important protections you need to know about. Since macOS Catalina, every 24 hours or so macOS runs a paired set of scans by XProtect Remediator, looking for signs of known malware. If it finds any, it then attempts to remove, or remediate, that. The snag is that it does this in complete silence, so you don’t know whether it has run any scans, and you don’t know if it came across anything nasty, or removed it. I like to know about such things, and have written my own software that lets me find out, in SilentKnight, Skint and XProCheck. One day Apple might follow suit.
Some browsers like Safari have a potentially dangerous setting, in which they will automatically open files they consider to be safe, once they have been downloaded. This can include Zip archives that might not be as innocent as you expect. If you leave that behaviour set, you could discover your Downloads folder with all sorts of items in it. I much prefer to turn that off and handle those downloads myself. You’ll find this control in Safari’s General settings, where it’s called Open “safe” files after downloading.
Most of the protection so far relies more on features in your Mac and macOS, and less on your habits and behaviour. But it’s the user who is the kingpin in both security and privacy protection. Nowhere is this more important than dealing with links in web pages, emails, messages, and elsewhere. If you’re happy to click on a link without checking it carefully, you can so easily end up in the company of your attackers, inviting them into your Mac and all your personal data.
Unless it’s a trusted web page or contact, I always inspect each link before even considering whether to open it. For emails, my general rule is never, and I inspect the text source of each message to see what that really links to. It’s harder on the web, where even ads placed by Google can whisk your browser into an ambush. One invaluable aid here is Link Unshortener, from the App Store, which is a ridiculously cheap and simple way to understand just where those cryptic shortened links will take you. If you can’t convince yourself that a link is safe and wholesome, then don’t whatever you do click on it, just pass on in safety.
That has been a whirlwind tour through getting the best from macOS security, summarised in the following diagram. Fuller details about each of those topics are easy to find using the Search tool at the top right of this page. There’s plenty more to read, and for deeper technical information, try Apple’s Platform Security Guide.
Work and play safely!
The macOS 15.1 update is the first scheduled update since Sequoia’s release last month, and brings with it a great many fixes as expected. From user reports, it’s believed to complete correcting problems reported with networking in 15.0, some of which were addressed in 15.0.1, although Apple hasn’t confirmed that.
Apple’s release notes are helpfully more detailed than usual, and include the following:
To clarify the requirement to get Writing Tools and other AI to work, the Mac must have an Apple silicon chip (M1 to M4), and:
Once those are set, you should be able to turn Apple Intelligence on. There will then be a short period on the waiting list, for macOS to download the additional models required. You’ll be notified when it’s ready to use.
Security release notes are available here, and list 50 entries, none of which Apple suspects may already have been exploited.
iBoot firmware on Apple silicon Macs is updated to version 11881.41.5, and T2 firmware to 2069.40.2.0.0 (iBridge: 22.16.11072.0.0,0). The macOS build number is 24B83, with kernel version 24.1.0. There are no firmware updates for Intel Macs without T2 chips.
Significant changes seen in bundled apps include:
Inevitably, there are many build increments in components related to Apple Intelligence. Other significant changes to /System/Library include:
Although this isn’t a particularly large update, it does come with the first wave of AI features, and a wide range of other improvements and bug fixes.
Updated 2030 GMT 1 November 2024 with info on non-T2 Intel firmware updates.
As expected, Apple has released the update to macOS 15.1 Sequoia, together with security updates to bring Sonoma to version 14.7.1, and Ventura to 13.7.1. There should also be Safari updates to accompany the latter two.
The Sequoia update is around 2.9 GB for Apple silicon Macs, and about 2.4 GB for Intel models.
As expected, this brings the first release of Writing Tools, in the first wave of new AI features, only for Apple silicon Macs using US English as both their primary language, and that set for Siri. Apple hasn’t got round to providing any list of new or changed features, and you may find that offered by Software Update is the same as for 15.0.
Security release notes are available here for 15.1, which has around 50 entries, here for 14.7.1 with around 39, and here for 13.7.1 with around 36.
iBoot firmware on Apple silicon Macs is updated to version 11881.41.5, T2 firmware to 2069.40.2.0.0 (iBridge: 22.16.11072.0.0,0), and Safari to 18.1 (20619.2.8.11.10).
I will post details of changes found later tonight.
[Updated 1820 GMT 28 October 2024.]
It’s essential to know when an authentication request is genuine. Without that knowledge, it’s all too easy to give your password away to malware, or to a badly-behaved app that’s trying to work around macOS security rules. By far the best way to authenticate now is using Touch ID, but many Macs don’t support it, either because they can’t, or because their keyboard doesn’t, and macOS doesn’t always offer it anyway. This article looks at how you can recognise genuine requests.
The traditional non-biometric dialog is still in widespread use, and can appear on any Mac, even when Touch ID is available, and in Sequoia. I’ve been trying to work out a simple rule to predict when you should expect to see a classic request, and it appears to be associated with more traditional apps like Keychain Access, and when asking to access a file-based keychain such as the login keychain. But there don’t appear to be any simple and robust rules.
When an app needs to access a secret that requires authentication, the security system, not the app, displays a dialog asking you for the password to that keychain to authenticate before it will provide the password or other secret to the app.
That authentication dialog is very important: although malware might try to forge it, it contains distinctive features you should always look for:
Note that this doesn’t provide or ask for your user name, only the password for that keychain.
If Touch ID isn’t currently available to your Mac, either because it doesn’t support it, or because it doesn’t have a keyboard connected that includes Touch ID support, you should see the non-biometric versions of other dialogs requesting authentication. These are for purposes other than keychain access that require elevated privileges, such as for a process to run a privileged helper, or to make changes in System Settings.
This new vertical format should contain the following:
If your Mac supports Touch ID (all Intel Macs with T2 chips, and all Apple silicon Macs), and currently has a keyboard connected to it with support for Touch ID, macOS should offer you the biometric version of that authentication dialog.
This should contain the following:
This dialog has distinctive behaviour that’s difficult to forge. When you place your fingertip on the Touch ID button on the keyboard, it will either authenticate successfully, so dismissing the dialog, or the dialog shakes to indicate you should try placing your fingertip on the button again.
If Touch ID authentication fails, or you click on the button to Use Password…, the dialog expands to resemble the non-biometric version above, with the following two important differences:
Although you will continue to encounter classic non-biometric authentication dialogs on a Mac with full Touch ID support, you may also come across some that you might have expected still to use the old dialog, but which now use a biometric dialog, such as that below.
Perhaps as Touch ID support extends this will become more consistent.
Encrypting all your data didn’t become a thing until well after the first release of Mac OS X. Even then, the system provided little support, and most of us who wanted to secure private data relied on third-party products like PGP (Pretty Good Privacy).
Apple released the first version of FileVault, now normally referred to as FileVault 1 or Legacy FileVault, in Mac OS X 10.3 Panther in 2003. Initially, that only encrypted a user’s Home folder into a sparse disk image, then in 10.5 Leopard it started using sparse bundles instead. These caused problems with Time Machine backup when it too arrived in Leopard, and proved so easy to crack that in 2006 Jacob Appelbaum and Ralf-Philipp Weinmann released a tool, VileFault, to decrypt FileVault disk images.
FileVault 1 was controlled in the Security pane of System Preferences, shown here in 2004.
Each new user added in the Accounts pane could have their Home folder stored in an encrypted disk image. Encryption keys were based on the user’s password, with a master password set for all accounts on the same Mac.
FileVault 2 was introduced in Mac OS X 10.7 Lion in 2011, and at last provided whole-volume encryption based on the user password. Encryption was performed using the XTS-AES mode of AES with a 256-bit key, by the CPU. At that time, more recent Intel processors had instructions to make this easier and quicker, but all data written to an encrypted volume had to be encrypted before it was written to disk, and all data read from it had to be decrypted before it could be used. This imposed significant overhead of around 3%, which was more noticeable on slower storage such as hard disks, and with slower Macs.
Apple didn’t implement this by modifying the HFS+ file system to add support for encryption, but by adding encryption support to CoreStorage, the logical volume manager. In theory this would have enabled it to encrypt other file systems, but I don’t think that was ever done.
Turning FileVault on and off was quite a pain, as the whole volume had to be encrypted or decrypted in the background, a process that could take many hours or even days. Most users tried to avoid doing this too often as a result so, while FileVault 2 was secure and effective, it wasn’t as widely used as it should have been.
These screenshots step through the process of enabling FileVault in 2017.
Control was in the FileVault tab in System Preferences.
iCloud Recovery was added as an alternative to the original recovery key.
Encryption began following a restart, and then proceeded in the background for however long it took. Shrewd users enabled FileVault when a minimum had been installed to the startup volume, to minimise time taken for encryption.
With a minimal install, it was possible to complete initial encryption in less than an hour. With full systems, it could take days if you were unlucky.
Although FileVault has had a few security glitches, it has done its job well. Perhaps its greatest threat came in the early days of macOS Sierra, when Ulf Frisk developed a simple method for retrieving the FileVault password for any Mac with a Thunderbolt port. An attacker could connect a special Thunderbolt device to a sleeping or locked Mac, force a restart, then read the password off within 30 seconds. This exploited a vulnerability in the handling of DMA, and was addressed by enabling VT-d in EFI, in Sierra 10.12.2 and 10.12.4.
The next big leap forward came at the end of 2017, with the release of the first Macs with T2 chips, as intermediates on the road to Apple silicon. One of Apple’s goals in T2 and Apple Silicon chips was to make encrypted volumes the default. To achieve that, T2 and M-series chips incorporate secure enclaves and perform encryption and decryption in hardware, rather than using CPU cycles.
The Secure Enclave incorporate the storage controller for the internal SSD, so all data transferred between CPU and SSD passes through an encryption stage in the enclave. When FileVault is disabled, data on protected volumes is still encrypted using a volume encryption key (VEK), in turn protected by a hardware key and a xART key used to protect from replay attacks.
When FileVault is enabled, the same VEK is used, but it’s protected by a key encryption key (KEK), and the user password is required to unwrap that KEK, so protecting the VEK used to perform encryption/decryption. This means that the user can change their password without the volume having to be re-encrypted, and allows the use of special recovery keys in case the user password is lost or forgotten. Keys are only handled in the secure enclave.
Securely erasing an encrypted volume, also performed when ‘erasing all content and settings’, results in the secure enclave deleting its VEK and the xART key, rendering the residual volume data inaccessible even to the secure enclave itself. This ensures that there’s no need to delete or overwrite any residual data from an encrypted volume: once the volume’s encryption key has been deleted, its previous contents are immediately unrecoverable.
Coverage of boot volumes by encryption varies according to the version of macOS. Prior to macOS Catalina, where macOS has a single system volume, the whole of that is encrypted; in Catalina, both System and Data volumes are encrypted; in Big Sur and later, the Signed System Volume (SSV) isn’t encrypted, nor are Recovery volumes, but the Data volume is.
Hardware encryption and FileVault’s ingenious tricks aren’t available for external disks, but APFS was designed to incorporate software encryption from the outset. As with internal SSDs, the key used to encrypt the volume contents isn’t exposed, but accessed via a series of wrappers, enabling the use of recovery keys if the user password is lost or forgotten. This involves a KEK and VEK in a similar manner to FileVault on internal SSDs. As the file system on the volume is also encrypted, after the KEK and VEK have been unwrapped, the next task in accessing an encrypted volume is to decrypt the file system B-tree using the VEK.
Enabling FileVault has been streamlined in recent years, as shown here in System Settings last year, for an external SSD, thus not using hardware encryption.
FileVault control has moved to Privacy & Security in System Settings.
The choice of iCloud Recovery or a recovery key remains.
Because only the Data volume is now encrypted, enabling FileVault before populating the Home folder allows encryption to be almost instantaneous, on an external disk.
The most recent enhancement to FileVault protection extends support to Sequoia virtual machines running on Sequoia hosts. Apple hasn’t yet explained how that one works, although I suspect the word exclave is likely to appear in the answer.
If your Mac has a T2 or Apple silicon chip and you haven’t enabled FileVault, then you’re missing one of the Mac’s best features.
Apple has just released an update to XProtect Remediator security software for Catalina or later, bringing it to version 147. The previous version was 145.
Apple doesn’t release information about what security issues this update might add or change. There are no changes in the number or names of its scanning modules, and Bastion rules also remain unchanged.
You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.
A full listing of security data file versions is given by SilentKnight, LockRattler and SystHist for El Capitan to Sequoia available from their product page. If your Mac has not yet installed this update, you can force it using SilentKnight, LockRattler, or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPayloads_10_15-147.
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
I maintain lists of the current versions of security data files for Sequoia on this page, for Sonoma on this page, Ventura on this page, Monterey on this page, Big Sur on this page, Catalina on this page, Mojave on this page, High Sierra on this page, Sierra on this page, and El Capitan on this page.
Apple has just released an update to XProtect for all supported versions of macOS, bringing it to version 5278. As usual, Apple doesn’t release information about what security issues this update might add or change.
Relative to the last version released for all supported versions of macOS (5277), this version adds three new definitions for MACOS.ADLOAD.I, MACOS.SOMA.G and MACOS.SOMA.H.
You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.
A full listing of security data file versions is given by SilentKnight, LockRattler and SystHist for El Capitan to Sequoia available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight, LockRattler, or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5278.
For Sequoia only: there’s no sign of this update being made available in iCloud, which still returns an XProtect version of 5272. If you download and install it using Software Update, softwareupdate or SilentKnight, then once that’s complete you need to update the primary XProtect bundle in Terminal using the commandsudo xprotect update
then entering your admin password. If you’re unsure what to do, this article explains it comprehensively and simply.
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
I maintain lists of the current versions of security data files for Sequoia on this page, for Sonoma on this page, Ventura on this page, Monterey on this page, Big Sur on this page, Catalina on this page, Mojave on this page, High Sierra on this page, Sierra on this page, and El Capitan on this page.
Apple has just released an update to XProtect for all supported versions of macOS, bringing it to version 5277. As usual, Apple doesn’t release information about what security issues this update might add or change.
Relative to the last version released for all supported versions of macOS (5276), this version contains extensive changes, largely of an editorial nature. It adds one new detection rule for MACOS.PIRRIT.CHU, and removes rules for OSX.Genieo.C, OSX.Genieo.B, OSX.Genieo.A and OSX.Leverage.a.
Many rules have changes to their detection hashes, where existing SHA1 hashes are replaced with SHA256. Among the rules changed by this are 36:
You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.
A full listing of security data file versions is given by SilentKnight, LockRattler and SystHist for El Capitan to Sequoia available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight, LockRattler, or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5277.
For Sequoia only: so far, I have seen no sign of this update in iCloud, which still returns an XProtect version of 5272. If you download and install it using Software Update, softwareupdate or SilentKnight, then once that is complete you need to update the primary XProtect bundle in Terminal using the commandsudo xprotect update
then entering your admin password.
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
I maintain lists of the current versions of security data files for Sequoia on this page, for Sonoma on this page, Ventura on this page, Monterey on this page, Big Sur on this page, Catalina on this page, Mojave on this page, High Sierra on this page, Sierra on this page, and El Capitan on this page.
Apple has just released an update to XProtect for all supported versions of macOS, bringing it to version 5276. As usual, Apple doesn’t release information about what security issues this update might add or change.
Relative to the last version released for Sequoia (5275), this version removes all the new-style rules that had been added to that and 5273. Relative to the general release version 5274, and 5275, it adds one new rule for MACOS.PIRRIT.BM.OBF.
You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.
A full listing of security data file versions is given by SilentKnight, LockRattler and SystHist for El Capitan to Sequoia available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight, LockRattler, or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5276.
For Sequoia only: so far, I have seen no sign of this update in iCloud, which still returns an XProtect version of 5272. If you download and install it using Software Update, softwareupdate or SilentKnight, then you need to update the primary XProtect bundle in Terminal using the commandsudo xprotect update
then entering your admin password.
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
I maintain lists of the current versions of security data files for Sequoia on this page, for Sonoma on this page, Ventura on this page, Monterey on this page, Big Sur on this page, Catalina on this page, Mojave on this page, High Sierra on this page, Sierra on this page, and El Capitan on this page.
——这篇攻略和是否外置硬盘盒，没多大关系。普通内置硬盘也可以这样加密安装。
最新的 Ubuntu 22.04 之后的版本，在安装界面里自带了 LVM 全盘加密安装的选项。但是并不能满足第 3 条需求。所以还需要一些复杂的手动操作。
安装过程尽量围绕 ubuntu 的图形安装界面，对新人友好。参考并验证了这篇教程。但原文连同 /boot 引导分区也一起加密了，于是在配置上略显繁琐。我觉得加密 /boot 并不是很有必要，做了一些改动。最终的硬盘分区结构为（以 512GB 硬盘为例）：
下载 Ubuntu，制作 USB 安装盘（过程略）。——然后，强烈建议在整个安装过程之前，在电脑的 BIOS 里，把内置的其它硬盘暂时卸载。
插上移动硬盘和 USB 启动盘。从 U 盘启动电脑，选择 Try Ubuntu。最新的 Ubuntu 22.04 安装程序里，已经内置了所需的 cryptsetup 和 cryptsetup-initramfs 软件包。因此，整个安装过程中，应该不需要连接互联网。
首先，把硬盘预分区。分区软件有很多种，可以用原文的 sgdidk，也可以直接用图形界面下的 Disk 或者 Gparted。在硬盘上创建 GPT 分区表，然后分成：
这些分区都先不用格式化。记住第二个分区的名字，本文假定为 /dev/sda2。
分区成功后，关闭分区软件，打开 Terminal 命令界面，执行 root 权限
sudo -i将系统分区加密。按提示输入密码，——这个密码，就是以后每次启动时，挂在硬盘用的密码。和安装 Ubuntu 时的用户密码，并不是一回事。
cryptsetup luksFormat --type=luks1 /dev/sda2解锁刚刚加密的分区：
cryptsetup open /dev/sda2 hd2_crypt创建逻辑卷组（LVM），然后在其中创建 2GB 的 swap 交换分区，再把剩余的空间创建为系统分区（这两个分区的大小，大家自行调整）：
pvcreate /dev/mapper/hd2_crypt
vgcreate ubuntu--vg /dev/mapper/hd2_crypt
lvcreate -L 2G -n swap_1 ubuntu--vg
lvcreate -l 100%FREE -n root ubuntu--vg然后，运行桌面上的 Ubuntu 安装程序（Terminal 先不要关），在磁盘分区页面，选择 Something else，进行手动分区。
点击 Install Now，确认对分区的设置。注意，到了下一步创建用户的界面时，先不要继续。切换回 Terminal 命令行界面，正式安装前，在 GRUB 中启用加密（能看懂下面这些命令的话，也可以直接去编辑相应的文件）：
while [ ! -d /target/etc/default/grub.d ]; do sleep 1; done; echo "GRUB_ENABLE_CRYPTODISK=y" > /target/etc/default/grub.d/local.cfg然后回到创建用户的页面，点击继续，开始安装系统。安装结束后，先不要 restart。而是点击 Continue Testing。
回到 Terminal 命令行界面，chroot 到新装的系统：
mount /dev/mapper/ubuntu----vg-root /target
for n in proc sys dev etc/resolv.conf; do mount --rbind /$n /target/$n; done
chroot /target
mount -a原文说此时需要（联网）安装 apt install cryptsetup-initramfs；但我用的 ubuntu 安装程序已经自带了，并不需要联网安装软件包。
添加密钥文件相关设置：
echo "KEYFILE_PATTERN=/etc/luks/*.keyfile" >> /etc/cryptsetup-initramfs/conf-hook
echo "UMASK=0077" >> /etc/initramfs-tools/initramfs.conf创建密钥文件并将其添加到 LUKS
mkdir /etc/luks
dd if=/dev/urandom of=/etc/luks/boot_os.keyfile bs=512 count=1
chmod u=rx,go-rwx /etc/luks
chmod u=r,go-rwx /etc/luks/boot_os.keyfile将密钥添加到 boot_os.file 和 Crypttab
cryptsetup luksAddKey /dev/sda2 /etc/luks/boot_os.keyfile
echo "hd2_crypt UUID=$(blkid -s UUID -o value /dev/sda2) /etc/luks/boot_os.keyfile luks,discard" >> /etc/crypttab更新 Initialramfs 内核映像
update-initramfs -u -k all此时全部结束。可以重启系统啦。
最简单的方式，是在已经启动的移动硬盘系统里，先通过 disk 等分区软件，确认加密分区的名字（这里假设仍然是 /dev/sda2，但实际上不一定了），打开 Terminal 界面，
sudo -i
cryptsetup luksChangeKey /dev/sda2按照提示，输入旧密码，再输入两遍新密码。最后，更新 initramfs，
update-initramfs -u -k all就可以了。
