Expose password policy information

[noahtalerman]

This issue is part of the "Provide obvious value out of the box with Fleet" epic: #4969

Goals

As a Fleet user, I want to know whether or not screen lock is enabled for all my macOS, Windows, and Linux workstations so that I know which devices need to enable this feature to keep them secure and compliant.

As a Fleet user, I want to know if the password to unlock a device (macOS, Windows, and Linux workstations) meets my organizations minimum password requirements so that I know which devices need new passwords to keep them secure and compliant.

How?

• [ ] Research how would we achieve this
• [ ] Draft what would the extension table(s) look like
• [ ] Implement extension

[noahtalerman]

Sharvil: Retrieving screen lock information via osquery may not be very reliable on the latest macOS versions. There is a screen_lock table (macOS). Only works on currently logged in users.

[noahtalerman]

Sharvil: For password policy information, there's a command line utility that we can add as a table to macadmins extension.

[noahtalerman]

Sharvil: I don't think retrieving screen lock and password policy info via osquery is supported on Linux.

[noahtalerman]

@sharvilshah are you able to take on this ticket next week? If so, I'll pass this issue's assignment to you.

I imagine there will be a research step (how would we achieve this?), planning step (what would the extension table(s) look like?), and implementation step.

cc @zwass

[zwass]

Sharvil and I discussed yesterday -- he's taking a look into research and we're going to plan for implementation during the 4.14 sprint.

[sharvilshah]

@noahtalerman yep, as Zach mentioned, I am going to research what needs to be done, and what approach would work best -- whether an osquery extension, or in core or via an MDM API.

Note that this will be initially for macOS only.

[sharvilshah]

For password policy on macOS:

Researched a bit today -- pwpolicy apple's CLI tool enumerates policies available for OpenDirectory, but it's a bit difficult to attribute which policies apply to which users. OpenDirectory also has been deprecated.

Chatted with Guillaume: MDM can push out a profile to enforce password policies. It's not very granular, but it has minLength, alphanumeric, and complex characters. We created a test group and a test profile for password policy, but neither the macadmins extension nor managed policies/preferences expose them currently. Next steps for this would be enroll a VM using the test profile, and figure out/reverse which key/blob would contain that data and extend the mdm extension or the managed policy. The other option would be to shell out to profiles and see if data can be parsed that way (this will have to be part of an extension).

[noahtalerman]

figure out/reverse which key/blob would contain that data and extend the mdm extension or the managed policy. The other option would be to shell out to profiles and see if data can be parsed that way (this will have to be part of an extension).

@sharvilshah do both of these options require that a policy is enforced via MDM?

If I'm understanding correctly, this means that the user would have to (1) enroll their device to MDM, (2) push out a profile to enforce password policies, and then (3) add a policy in Fleet to see if passwords meet the minimum length.

Fleet could provide a large amount of value if only part (3) is necessary. I want to make sure that you're confident that this isn't possible on macOS.

Ideally we'd like to achieve this (no MDM requirement) for both the password policy and screenlock policies in Fleet.

[sharvilshah]

@noahtalerman Doing a bit more research on this, I think it would be possible to cover both MDM and non-MDM cases by combining data from pwpolicy and profiles. There will be edge cases that will be missed, but this should ideally cover the majority of use cases for macOS.

Also: for screenlock on macOS, we already have a table in osquery that shows this data -- Both Zach and I confirmed today that this table still works on latest macOS 12. The only limitation is that screenlock will only show data for currently logged in user (Apple API limitation)

[noahtalerman]

it would be possible to cover both MDM and non-MDM cases by combining data from pwpolicy and profiles

@sharvilshah awesome. It makes sense that there will be edge cases we'll iron out later.

I do think it's worth thinking through what, as a user running a query to collect password policy info, you'd expect to see returned...

• when there is no password policy information available
• incomplete password policy information

It's definitely worth thinking through what data to return

limitation is that screenlock will only show data for currently logged in user (Apple API limitation)

Got it. Is determining if screenlock is enabled, when the user is not logged in, something that we can achieve through a different source (other than the Apple API) ?

[sharvilshah]

@noahtalerman, this is the first pass:

osquery> select * from password_policy;
I0512 15:00:12.948212 55788928 password_policy.cpp:96] 3
+-------------------------------------------------------------------------+----------------------------------------------------------------+-----------------------------------------------------------+
| policy_identifier                                                       | policy_attribute                                               | policy_description                                        |
+-------------------------------------------------------------------------+----------------------------------------------------------------+-----------------------------------------------------------+
| ProfilePayload:1e8725aa-9941-482a-b02d-ed8c4156077e:requireAlphanumeric | policyAttributePassword matches '^(?=.*[0-9])(?=.*[a-zA-Z]).+' | Contain at least one number and one alphabetic character. |
| com.apple.defaultpasswordpolicy.fde                                     | policyAttributePassword matches '.{4,}+'                       | Enter a password that is four characters or more.         |
| ProfilePayload:1e8725aa-9941-482a-b02d-ed8c4156077e:minLength           | policyAttributePassword matches '.{10,}'                       | Contain at least 10 characters.                           |
+-------------------------------------------------------------------------+----------------------------------------------------------------+-----------------------------------------------------------+

Regarding the two points -- if there is no password policy available, like with other things there will be no data returned. I am not sure about incomplete password policy information -- thinking about this and how it would be possible to have "incomplete" information.

[noahtalerman]

This is sweet! ✨

if there is no password policy available, like with other things there will be no data returned

I think I understand. By "password policy" here do you mean a policy enforced by an MDM (Apple MDM protocol) ?

If so, does this mean that the select * from password_policy query above will return no results if the device is not enrolled in MDM ?

Ideally we'd like to achieve this (no MDM requirement) for both the password and screenlock policies in Fleet.

I'm asking these questions to understand if this^ goal still seems possible.

[noahtalerman]

cc @sharvilshah ^

[sharvilshah]

@noahtalerman

Yes, this will work for both locally defined policies on the system (no MDM), as well as the ones pushed by MDM profiles. In the example above, com.apple.defaultpasswordpolicy.fde is the default one that Apple has set, when FIleVault is enabled. The other two starting with ProfilePayload are the ones pushed by MDM.

So we can get at both types of data. I believe this currently implementation will cover almost all of the use cases, but I still want to test a few more cases in a VM

[sharvilshah]

@noahtalerman and screenlock while related is different from these APIs, and as mentioned above, it's a per user setting.

limitation is that screenlock will only show data for currently logged in user (Apple API limitation)

Got it. Is determining if screenlock is enabled, when the user is not logged in, something that we can achieve through a different source (other than the Apple API) ?

Not 100% sure on above, I will need to test. But that is something that I want to look at after finishing up password policies.

[noahtalerman]

I believe this currently implementation will cover almost all of the use cases, but I still want to test a few more cases in a VM

Rockin!

that is something that I want to look at after finishing up password policies.

Sweet 👍

[sharvilshah]

@noahtalerman https://github.com/osquery/osquery/pull/7594

[noahtalerman]

Sweet!

@sharvilshah am I understanding the results correctly?

When I run select * from password_policy the presence of com.apple.defaultpasswordpolicy.fde means that the user's password is at least 4 characters long.

[sharvilshah]

When I run select * from password_policy the presence of com.apple.defaultpasswordpolicy.fde means that the user's password is at least 4 characters long

Yes -- com.apple.defaultpasswordpolicy.fde relates to Full Disk Encryption (FileVault) --the value (default of 4) of the key com.apple.defaultpasswordpolicy.fde when present, means that the filevault (by default macOS syncs this password with the login password) password has to be atleast 4 characters for FileVault

[zhumo]

This is done right? Can we close?

[zhumo]

@sharvilshah can we close this or move this forward? It's done right?

[zhumo]

@noahtalerman @sharvilshah ?

[sharvilshah]

@zhumo password_policy is shipped with osquery 5.4.0. screenlock will require an extension (even the "runas" hack is broken on M1), I will capture that in a new issue.