search

fleetdm / fleet

Open-source platform for IT, security, and infrastructure teams. (Linux, macOS, Chrome, Windows, cloud, data center)
https://fleetdm.com
Other
3.01k stars 418 forks source link

Access FileVault disk encryption key, store in Fleet database, and serve via API endpoints #8708

Closed lukeheath closed 1 year ago

lukeheath commented 1 year ago

Problem

IT admins use the FileVault (disk encryption) feature to require that macOS hosts use a password to unlock the disk.

If a contributor leaves an organization, the IT admin may need to see the data on the host. However, the IT admin doesn't have access to the contributor's password.

Currently, IT admins use their MDM solution to retrieve the FileVault recovery key (disk encryption key) that they can use to unlock the host. If the IT admin doesn't have an MDM solution or their MDM solution doesn't store the key, this makes it nearly impossible for the IT admin to unlock the host.

Business Case

Most, if not all, MDM solutions support storing the disk encryption key.

Related

Requirements

  1. Fleet admins, maintainers, and observers can see the disk encryption key for macOS hosts.
  2. The API naming supports adding the same info for Windows later (cross-platform).
    • Noah: I think this means that the name would be something like disk_encryption_key (instead of filevault_key). This is because Windows called its disk encryption feature BitLocker. While macOS calls it FileVault.
  3. Event is tracked activity feed when a user looks at the key.
  4. Document how to log in to a host with the key (recovery instructions.)
  5. Document that Fleet stores the key as part of MDM documentation.
  6. Update the fleetdm.com/transparency page to document that Fleet stores the key.
  7. Should work w/ macOS 10.15+

Notes

The recovery key can be retrieved using the SecurtyInfo MDM command if File Vault Escrow is configured. There are three configuration profiles at play here:

  1. com.apple.security.FDERecoveryKeyEscrow configures the escrow
  2. com.apple.security.pkcs1 carries a certificate referenced by 1
  3. com.apple.MCX.FileVault2 enables file vault

Important note: com.apple.security.FDERecoveryKeyEscrow needs to be installed before the disk is encrypted, otherwise you can't escrow the key. Some MDM solutions even send two different profiles, one with 1 and 2 above, and they only send 3 after that is installed. Up to the developer to decide if we can send the three configs in a single profile.

Recovery process

Configuration profile

First, send a configuration profile, here is a profile that enables FileVault and escrow at the same time (please look at the note above in regards to this)

enable-filevault-and-escrow.mobileconfig 
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>PayloadContent</key>
    <array>
        <dict>
            <key>Defer</key>
            <true/>
            <key>Enable</key>
            <string>On</string>
            <key>PayloadDisplayName</key>
            <string>FileVault 2</string>
            <key>PayloadIdentifier</key>
            <string>com.apple.MCX.FileVault2.3548D750-6357-4910-8DEA-D80ADCE2C787</string>
            <key>PayloadType</key>
            <string>com.apple.MCX.FileVault2</string>
            <key>PayloadUUID</key>
            <string>3548D750-6357-4910-8DEA-D80ADCE2C787</string>
            <key>PayloadVersion</key>
            <integer>1</integer>
            <key>ShowRecoveryKey</key>
            <false/>
        </dict>
        <dict>
            <key>EncryptCertPayloadUUID</key>
            <string>A326B71F-EB80-41A5-A8CD-A6F932544281</string>
            <key>Location</key>
            <string>Fleet</string>
            <key>PayloadDisplayName</key>
            <string>FileVault Recovery Key Escrow</string>
            <key>PayloadIdentifier</key>
            <string>com.apple.security.FDERecoveryKeyEscrow.3690D771-DCB8-4D5D-97D6-209A138DF03E</string>
            <key>PayloadType</key>
            <string>com.apple.security.FDERecoveryKeyEscrow</string>
            <key>PayloadUUID</key>
            <string>3C329F2B-3D47-4141-A2B5-5C52A2FD74F8</string>
            <key>PayloadVersion</key>
            <integer>1</integer>
        </dict>
        <dict>
            <key>PayloadCertificateFileName</key>
            <string>fleet-mdm-apple-scep</string>
            <key>PayloadContent</key>
            <data>
            MIIDGzCCAgOgAwIBAgIBATANBgkqhkiG9w0BAQsFADAvMQkwBwYD
            VQQGEwAxEDAOBgNVBAoTB3NjZXAtY2ExEDAOBgNVBAsTB1NDRVAg
            Q0EwHhcNMjIxMjIyMTM0NDMzWhcNMzIxMjIyMTM0NDMzWjAvMQkw
            BwYDVQQGEwAxEDAOBgNVBAoTB3NjZXAtY2ExEDAOBgNVBAsTB1ND
            RVAgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDV
            u9YVfl7gu0UgUkOJoES/XrN0WZdIjgvS2upKfvP4LSJOq1Mnp3bH
            wWOA2NkHem/kjOVeotOk1aEYIzxbic6VlvNOz9huOhbJyoV4TO5v
            tp/GFFcJ4IXh+f1Q4vm/NeH/XxEWn9S20B9OkSMOUievYsAu6iSi
            oWaa74q1mnfpzM29p3dNM82mCKutYdkW0EusixU/CQxcVhdcxC+R
            RyM4jzBFIipa7H20UtqdkZ03/9BoowJb/h/r4X7TN4tKg2vcwpZK
            uJo7VcTBNPxhBowzg3JUmzjCnxPbuU/Ow5kPGOLJtbf4766ToNTM
            /J63i3UPshKUBqAE8mIZO3qb7s25AgMBAAGjQjBAMA4GA1UdDwEB
            /wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTxPEY4
            WvsLCt+HDQfnEPOKrHu0gTANBgkqhkiG9w0BAQsFAAOCAQEAGNf5
            R60vRxIfvSOUyV3X7lUk+fVvi1CKC43DsP5OsQ6g5YVGcVXN40U4
            2o7JUeb9K1jvqnzWB/3k+lSCkEb0a5KabjZE5Vpdt9xctmgrfNnQ
            PBCfDdyb0Upjm61CJeB2SW9+ibT2L+OtL/nZjjlugL7ir9ramQBh
            0IY6oB9Yc3TyZyPjnXwbi0jv5cildzIYaYPvPkPPTjezOUqUDgUH
            JtdWRBQeJ/6WxAAm9il0KVXOsRPgAsdiDJTF6FdW4lsY8V/R6y0H
            hTN1ZSyqklKAuvEZZznfmJsrNYRII2Fv2zOk0Uv/+E+EKTOHbgcC
            PQAARDBzDlWvlMGWcbdrdypdeA==
            </data>
            <key>PayloadDisplayName</key>
            <string>Certificate Root</string>
            <key>PayloadIdentifier</key>
            <string>com.apple.security.root.A326B71F-EB80-41A5-A8CD-A6F932544281</string>
            <key>PayloadType</key>
            <string>com.apple.security.pkcs1</string>
            <key>PayloadUUID</key>
            <string>A326B71F-EB80-41A5-A8CD-A6F932544281</string>
            <key>PayloadVersion</key>
            <integer>1</integer>
        </dict>
    </array>
    <key>PayloadDisplayName</key>
    <string>Enable FileVault</string>
    <key>PayloadIdentifier</key>
    <string>Robertos-MacBook-Pro.70DD9242-4F3B-4597-969C-0FCB68AA6E1B</string>
    <key>PayloadType</key>
    <string>Configuration</string>
    <key>PayloadUUID</key>
    <string>74FEAC88-B614-468E-A4B4-B4B0C93B5D52</string>
    <key>PayloadVersion</key>
    <integer>1</integer>
</dict>
</plist>
fleet-mdm-apple-scep.key (private key) 

-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEA1bvWFX5e4LtFIFJDiaBEv16zdFmXSI4L0trqSn7z+C0iTqtT
J6d2x8FjgNjZB3pv5IzlXqLTpNWhGCM8W4nOlZbzTs/YbjoWycqFeEzub7afxhRX
CeCF4fn9UOL5vzXh/18RFp/UttAfTpEjDlInr2LALuokoqFmmu+KtZp36czNvad3
TTPNpgirrWHZFtBLrIsVPwkMXFYXXMQvkUcjOI8wRSIqWux9tFLanZGdN//QaKMC
W/4f6+F+0zeLSoNr3MKWSriaO1XEwTT8YQaMM4NyVJs4wp8T27lPzsOZDxjiybW3
+O+uk6DUzPyet4t1D7ISlAagBPJiGTt6m+7NuQIDAQABAoIBAE6LXL1BV3SW3Wxn
TtKAx0Lcdm5HjkTnjojKUldWGCoXzAfFBiYIcKov83UiO394Cy6eaJxCkix9JVpN
eJzbI8PtWTSZRRwc1MsLVclD3EvJfSW5y9KhZBILYIAdKVKPZqIGOa1qxyz3hsnE
pHFa16KoU5/qA9SQI7jEVuEuBusv4D/dRlEWvva7QOhnLrBPrSnTSZ5LxCFKRviS
XrEQ9AuRJeXCKx4WzXd4IZPpgldYHMJSSGMr0TeVcURbsfveI2IWvOLag0ofTHhx
tolBT2sKzInItLTwt/irZEp5lV08mMGxHuxoCdzhxjFQP8eGOZzPW65c6/D9hEXd
DzWnjdECgYEA9QtTQosOTtAyU1i4Fm76ltT6nywHy23KAMhBaoKgTMccNtjaOCg/
5FCCRD+qoo7TF4jdliP2NrMIbAIhr4jEfHSMKaD/rae1xqInseDCrGi9gzvm8UxG
84VG30Id8s70ZQWZjR/PFFDeNZjNhlk8COO0XoLaqJSZr+A30aSyeUsCgYEA30ok
3EvO1+/gjZv28J9vApdbiEwtO9xoteghElFzdtuEuzA+wL83w8xvKvdb4Rk5xigE
6mV69dBPj8zSyGp0lFTYLFvry5N4S8L6QPzt2nk+Lc3cDKSA5CkAkQ5Dmt5JwhxF
qIPDNZGXmoldIWJ0p/ZSu98/1yXBMQ9gCje/losCgYBwuk4KLbheT27nYsgFIfbL
zpyg/vty/UXRiE53tjISQALdxHLXJMUHvnW++d8Au12m1QLDIDYTQdddALoIa42g
h2k3eWZFuAJqp4xFS1WjROfx6Gu8k8+MFcLd0CfA3K4XjzTtdDWqbe1bkLjz1jdF
C6OdWutGZF4zR53GJtMn8wKBgCfA95cRGB5x4rTTk797YzQ+5lj51wPVVf8s+NZe
EgSTSKpbCJEgejkt6IzpxT3qU9LnxRhGQQIKuF+Nw+lSqrbN9D7RjsWL19sFN7Di
VyaSd3OINyk5EImOkz9AHuEvukoI5o3+B38+EJO+6QnMkaBlxo0UTjVrz12As0Se
cEnJAoGBAOUXjez9oUSzLzqG/WJFrIfHyjDA1vBS1j39XuhDuJGqMdNLlCE8Yr7h
d3gpZeuV3ZC33QAuwAXfRBNnKIDtDGpcrozM1NndcBVDs9GYvobaTiUaODGjsH44
oHwpyQbv9Qs+3bjPOQ7DkwekT+w1cptEKudBCC3WQKui1P0NNL0R
-----END RSA PRIVATE KEY-----

A couple of notes:

a. There are no restrictions on the certificate/key pair as long as it's in PKCS#1 format, here I'm using the SCEP certificate generated by fleetctl generate mdm-apple b. If you want to use iMazing to generate your own profile instead of using this, you need to provide the certificate in DER format. c. Related to b, iMazing sets the wrong PayloadType for the certificate, you need to manually edit the file and set it to com.apple.security.pkcs1

Escrow

Once the profile is installed and the disk has been encrypted, you can issue a SecurityInfo command, the response from the host contains a key named FDE_PersonalRecoveryKeyCMS.

The content of FDE_PersonalRecoveryKeyCMS is a PKCS#7 envelope in DER format, base64 encrypted, so this is what I have done (I'm sure there's a better way, leaving this here just for reference)

# tmpfile contains the contents of FDE_PersonalRecoveryKeyCMS
$ cat tmpfile | base64 -D > key.encrypted
$ openssl smime -decrypt -in key.encrypted -inkey fleet-mdm-apple-scep.key -inform der
VX62-5QQA-HB3J-KYRN-ZBB8-TQXV

Design

UI

https://www.figma.com/file/hdALBDsrti77QuDNSzLdkx/%F0%9F%9A%A7-Fleet-EE-(dev-ready%2C-scratchpad)?node-id=10686%3A316128

Epic

API

GET /hosts/{id}/encryption_key: 

{
  "host_id": 1,
  "encryption_key": {
    "updated_at": "2022-10-14T17:07:11Z",
    "key": "abc123"
  }
}

Tasks

1

2

3

4

5

6

lukeheath commented 1 year ago

@noahtalerman Based on the conversation with @fx5 in Slack, it appears /var/db/ConfigurationProfiles/fdesetup.plist is not a universal file, and the provided query will not work for many hosts. How would you like to handle this ticket?

noahtalerman commented 1 year ago

Ok! Thanks for calling this out.

My understanding is that…

@sharvilshah and @fx5, is there a better location we could use?

The goal here is to be able to display the FileVault recovery key. I think it’s ok this requires that FileVault is turned on by a MDM solution.

cc @lukeheath

fx5 commented 1 year ago

@noahtalerman as I understand it, this file location is probably only valid for the mdm solution/settings we are using.

lukeheath commented 1 year ago

this file location is probably only valid for the mdm solution/settings we are using.

I think the question is whether or not our MDM solution (the one we're building, not currently using), can extract the key and place it in the same location. I'm not sure who the best person to direct that question to is. @chiiph or @michalnicp do you have any insight here?

michalnicp commented 1 year ago

There may be a way to get the recovery key using mdm. According to Manage FileVault with mobile device management you can install a FDERecoveryKeyEscrow profile which will allow mdm to get the FDE_PersonalRecoveryKeyCMS field from the SecurityInfo command. There may be some additional work to decrypt it, but it should be possible. I don't know if this requires FileVault to be enabled by the user or via MDM.

If we go with this approach, I would strongly recommend against trying to save it back to a file on the device and using osquery to retrieve it again.

noahtalerman commented 1 year ago

Michal: There may be a way to get the recovery key using mdm.

There is!

That said, a requirement for this issue was to get the key without using MDM. This way, both users who have MDM features turned on in Fleet and users who don't (some other MDM solution) can access the recovery key.

If there isn't a consistent location for the key, then we'll come back to using the MDM escrow functionality.

Frank: as I understand it, this file location is probably only valid for the mdm solution/settings we are using.

Got it. By MDM solution I assume you mean "SimpleMDM."

I ran the following query on all Mac hosts in dogfood, and I got the key for hosts using Fleet's MDM on dogfood and hosts using SimpleMDM:

SELECT * FROM file_lines WHERE path='/var/db/ConfigurationProfiles/fdesetup.plist';

@lukeheath can an engineer on the Interface team please test if there is a consistent location for the key? One possible way to do this is to see if the query returns the key for hosts using these MDM solutions: SimpleMDM, Jamf, Kandji, and JumpCloud. Maybe it makes sense to carve out a separate issue.

This way, we can confirm/deny that there is a consistent location for storing the FileVault recovery.

lukeheath commented 1 year ago

@noahtalerman

an an engineer on the Interface team please test if there is a consistent location for the key? One possible way to do this is to see if the query returns the key for hosts using these MDM solutions: SimpleMDM, Jamf, Kandji, and JumpCloud. Maybe it makes sense to carve out a separate issue.

No problem. I spec'd this as a separate research issue: #8746. It will take a bit of effort to install and test the various MDM solutions, so I'd like to estimate with the team so it can be allocated into the next release cycle.

noahtalerman commented 1 year ago

I'd like to estimate with the team so it can be allocated into the next release cycle.

Makes sense. Thanks!

lukeheath commented 1 year ago

@mna Based on Mo's comment in #8746 we have approval to move forward with this ticket as spec'd.

Based on my research, we expect that SimpleMDM and Jamf can be configured to place the plist file in the filesystem, but Kandji and JumpCloud cannot.

We are most concerned with it working for our MDM solution, and any others will be a bonus.

sharvilshah commented 1 year ago

@sharvilshah and @fx5, is there a better location we could use?

The goal here is to be able to display the FileVault recovery key. I think it’s ok this requires that FileVault is turned on by a > MDM solution.

@noahtalerman Not aware of any standard location per se, /Library/Application Support/... could be a viable one as well.

There may be a way to get the recovery key using mdm. According to Manage FileVault with mobile device management you can install a FDERecoveryKeyEscrow profile which will allow mdm to get the FDE_PersonalRecoveryKeyCMS field from the SecurityInfo command. There may be some additional work to decrypt it, but it should be possible. I don't know if this requires FileVault to be enabled by the user or via MDM.

If we go with this approach, I would strongly recommend against trying to save it back to a file on the device and using osquery to retrieve it again.

Yep! Agree, and this will only work in the mdm-case (which is fine).

michalnicp commented 1 year ago

@mna Based on Mo's https://github.com/fleetdm/fleet/issues/8746#issuecomment-1318975417 in https://github.com/fleetdm/fleet/issues/8746 we have approval to move forward with this ticket as spec'd.

I think we are missing support for getting the recovery key when FileVault is enabled using Fleet MDM. It seems like we are assuming the recovery key can be found in /var/db/ConfigurationProfiles/fdesetup.plist which is only the case if FileVault was enabled using SimpleMDM.

@noahtalerman @zhumo

zhumo commented 1 year ago

@michalnicp Could Fleet MDM put the file in the same place?

michalnicp commented 1 year ago

@zhumo The method for getting the recovery key is described in https://github.com/fleetdm/fleet/issues/8708#issuecomment-1317573499. We could write it to a file on the host, but there may be security concerns and it would be additional (unecessary) work.

noahtalerman commented 1 year ago

@michalnicp @zhumo it seems like we don't have a great understanding of how the /var/db/ConfigurationProfiles/fdesetup.plist file gets created.

However, we do know that this file is being created by our dogfood MDM.

We also know when this file is created. The file is created if our dogfood MDM turns on FileVault. The file is not created if the end user turned on FileVault.

When I run this query in dogfood, I get my key (my host had FileVault turned on by dogfood):

SELECT * FROM file_lines WHERE path='/var/db/ConfigurationProfiles/fdesetup.plist';
michalnicp commented 1 year ago

Confirmed that /var/db/ConfigurationProfiles/fdesetup.plist does get created. This location seems to be controlled by the OutputPath in /Library/Preferences/com.apple.fdesetup.plist which is created when deferred enablement is active.

See https://developer.apple.com/documentation/devicemanagement/fdefilevault for more info on the configuration profile to enable filevault.

roperzh commented 1 year ago

@noahtalerman in regards to this:

Fleet admins, maintainers, and observers can see the disk encryption key for macOS hosts.

Is that valid across teams? Eg: I'm an admin on team "A" (not a global admin), can I read a host recovery key that belongs to team "B"?

edit: and also, if I belong to a team, can I read recovery keys from hosts without a team? ("global" hosts)

noahtalerman commented 1 year ago

I'm an admin on team "A" (not a global admin), can I read a host recovery key that belongs to team "B"?

if I belong to a team, can I read recovery keys from hosts without a team?

@roperzh no to both. If I'm an admin (or maintainer or observer) on Team A I can only see information about hosts assigned to Team A.

I can't see recovery keys or any other info for hosts assigned to Team B.

I can't see recovery keys or any other info for hosts assigned to no team.

michalnicp commented 1 year ago

Create a dedicated API endpoint to retrieve the encryption key. Because this is an encryption key, we don't want to include it in the general details GET /host/{id} endpoint. Instead, we want to create a new endpoint at GET /host/{id}/encryption_key.

Why do we need a dedicated api endpoint? It sounds like we are planning to have the same permissions scheme for hosts as for the host encryption keys. If someone has permission to view a host, they also have permission to view the encryption key

Fleet admins, maintainers, and observers can see the disk encryption key for macOS hosts.

This also means the UI will need to make an extra api request.

@noahtalerman

noahtalerman commented 1 year ago

@lukeheath updates from the "Disk encryption (FileVault) keys" call with Roberto and Mo:

lukeheath commented 1 year ago

@michalnicp

Why do we need a dedicated api endpoint? It sounds like we are planning to have the same permissions scheme for hosts as for the host encryption keys. If someone has permission to view a host, they also have permission to view the encryption key

This is because there is a requirement to record an activity item every time an encryption key is accessed.

lukeheath commented 1 year ago

@noahtalerman Got it. We have other MDM work to focus on, so I'll hold the frontend portion of this for now.

noahtalerman commented 1 year ago

2022-12-8: Some option in UI to turn on FileVault with escrow. Creating a profile for the user the enables escrow when they select this option.

noahtalerman commented 1 year ago

During the UX direction for MDM features (profiles + non-MDM settings + FileVault) call (2022-12-8), we decided that Fleet will use the SCEP cert + key for FileVault escrow.

We also decided to make FileVault a "clicky" option in the Fleet UI. Clicking something like "Turn on FileVault" in the UI will turn on FileVault with default settings (see below) and FileVault key escrow. This is covered by a separate issue here: #8961

This way, the user does not have to retrieve/generate a cert + key pair to escrow FileVault keys. Instead Fleet does this for the user.

Note that the user will generate and upload a profile with iMazing Profile Editor to modify macOS settings other than FileVault.

Here's a profile (XML) with the default FileVault settings: 

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>PayloadContent</key>
    <array>
        <dict>
            <key>Defer</key>
            <true/>
            <key>DeferForceAtUserLoginMaxBypassAttempts</key>
            <integer>3</integer>
            <key>Enable</key>
            <string>On</string>
            <key>PayloadDisplayName</key>
            <string>FileVault 2</string>
            <key>PayloadIdentifier</key>
            <string>com.apple.MCX.FileVault2.6E3A4FD5-5E08-49A3-AAC2-524AF922AB71</string>
            <key>PayloadType</key>
            <string>com.apple.MCX.FileVault2</string>
            <key>PayloadUUID</key>
            <string>6E3A4FD5-5E08-49A3-AAC2-524AF922AB71</string>
            <key>PayloadVersion</key>
            <integer>1</integer>
            <key>ShowRecoveryKey</key>
            <false/>
        </dict>
    </array>
    <key>PayloadDisplayName</key>
    <string>default-filevault</string>
    <key>PayloadIdentifier</key>
    <string>Noah-Talermans-MacBook-Pro.BEFAEF2E-5FFA-450D-873C-BF6EB1F14C12</string>
    <key>PayloadType</key>
    <string>Configuration</string>
    <key>PayloadUUID</key>
    <string>BEFAEF2E-5FFA-450D-873C-BF6EB1F14C12</string>
    <key>PayloadVersion</key>
    <integer>1</integer>
</dict>
</plist>

cc @zhumo @zwass @lukeheath @roperzh

roperzh commented 1 year ago

@noahtalerman @lukeheath from the Configuration Profile Reference, under the "FDE Recovery Key Escrow Payload" payload description (emphasis mine):

If FileVault is enabled after this payload is installed on the system, the FileVault PRK will be encrypted with the specified certificate, wrapped with a CMS envelope and stored at /var/db/FileVaultPRK.dat. The encrypted data will be made available to the MDM server as part of the SecurityInfo command. Alternatively, if a site uses its own administration software, it can extract the PRK from the foregoing location at any time

I have verified that, if /var/db/FileVaultPRK.dat doesn't exist, we don't get the encrypted key from the MDM SecurityInfo command either.

So, we could keep the plan of getting the key from osquery which will allow us to move faster without having to worry about setting up mechanisms to ingest data from MDM (we'll probably eventually need to do this.)

Any thoughts?

lukeheath commented 1 year ago

@roperzh Thanks for noticing this! That is good news. I'm in favor of going back to retrieving the file with osquery. It solves one concern I had with the previous approach: storying the key in plaintext on the filesystem. Can we think of any cases where the key may not be updated?

roperzh commented 1 year ago

Based on my testing, it gets updated as expected.

Note that we still need to install the file vault recovery escrow payload

zhumo commented 1 year ago

Hey! We discussed this on slack a few days ago, but wanted to bring it here...

My understanding is that Roberto's research indicates that we would still need to implement the filevault escrow functionality. Since we're going to be implementing filevault escrow anyway, we should just use the established protocol rather than do it through osquery.

fleet-release commented 1 year ago

` is supported on 10.15+ only.

A haiku about this improvement:

Data secured safe and sound Fleet stores encryption key Peace of mind abounds