Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add column for system extensions managed by configuration policy (system_extensions table) #6915

Conversation

kumarak
Copy link
Contributor

@kumarak kumarak commented Jan 24, 2021

System extensions deployed on a managed environment can be configured through a device management profile. The changes add a new column (is_managed) having information if the extension is managed by a payload policy. It scans through the extension payload policies and checks the allowed team identifiers & allowed extensions dictionary.

It will be great to get feedback from the community both on the changes and uses of having the information in the table.

Refs: com.apple.system-extension-policy

@kumarak kumarak changed the title Add column for system extensions managed by configuration policy Add column for system extensions managed by configuration policy (system_extensions table) Jan 24, 2021
@mike-myers-tob mike-myers-tob added macOS macOS Big Sur For things pertaining to macOS 11.0 macOS Catalina For things pertaining to macOS 10.15 virtual tables ready for review Pull requests that are ready to be reviewed by a maintainer labels Jan 25, 2021
@kumarak kumarak force-pushed the kumarak/systemextension_table_update branch from dc36b87 to 5a3de30 Compare January 26, 2021 23:14
@linux-foundation-easycla
Copy link

linux-foundation-easycla bot commented Jan 26, 2021

CLA Signed

The committers are authorized under a signed CLA.

@kumarak kumarak force-pushed the kumarak/systemextension_table_update branch 2 times, most recently from bd9223e to 71af424 Compare January 27, 2021 02:14
osquery/tables/system/darwin/system_extensions.mm Outdated Show resolved Hide resolved
Comment on lines 120 to 121
getExtensionRow(extension_value, r);
getPolicyFlag(ptree, r);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this code is extra recursive? If I read it correctly, you generate the ExtensionRow, which includes the team id that signed it. Then, for each one, you iterate to find the extension policies, and compare to set is_managed. Is that correct?

Naively, it feels simpler to generate the underlying policy outside the forloop, and then pass allowed_extensions and allowed_team_opt to getExtensionRow. Am I mis understanding?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@directionless, getExtensionRow and getPolicyFlag operate on two different nodes of the property tree. The one node has the list of system extension installed and the other have the policy related to the system extension.

The function getExtensionRow only gets the list of the system extension installed and for each extension, it looks into the extension policy node based on team id. The two-level of indirection makes it look extra recursive.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see that getExtensionRow and getPolicyFlag work in different places. But looks like for each row, this calls getPolicyFlag, which mostly does the same parsing, to see if teamid is allowed. So I wonder if parsing for all allowed team IDs, then checking membership would be faster than the repeated parsing. I'm not very confident in my read here.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know that you can call it "recursive." genExtensionsFromPtree has a single loop that calls getExtensionRow then (conditionally) getPolicyFlag

You're right that getPolicyFlag() does not cache its lookups, meaning it will do a small amount of work to walk the ptree again each time even if multiple rows all had the same Team ID and it was determined in the first call to getPolicyFlag() that the Team ID was allowed by MDM policy. But this is a very small amount of unnecessary work, and done only a few times per table query.

specs/darwin/system_extensions.table Outdated Show resolved Hide resolved
@theopolis theopolis removed the ready for review Pull requests that are ready to be reviewed by a maintainer label Feb 5, 2021
@theopolis
Copy link
Member

Ping!

@kumarak
Copy link
Contributor Author

kumarak commented Apr 9, 2021

@theopolis, Sorry for the delay. I got busy with other stuff and didn't get time to finish the PR. I will try to address it this weekend.

@kumarak kumarak requested review from a team as code owners April 13, 2021 16:26
@kumarak
Copy link
Contributor Author

kumarak commented Apr 13, 2021

Seems the commit history went wrong due to rebasing. I will try fixing it.

@kumarak kumarak force-pushed the kumarak/systemextension_table_update branch 2 times, most recently from 4a441a1 to b89f086 Compare April 14, 2021 22:44
Copy link
Member

@theopolis theopolis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's find a more appropriate name for is_managed and then this is good to go.

specs/darwin/system_extensions.table Outdated Show resolved Hide resolved
mike-myers-tob
mike-myers-tob previously approved these changes Apr 20, 2021
Copy link
Member

@mike-myers-tob mike-myers-tob left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've reviewed again, no further changes. Still works on macOS 11.0.2 and again on macOS 11.2.3 on a system with 2 system extensions, but noting that I have no MDM-managed system extensions.

@kumarak kumarak force-pushed the kumarak/systemextension_table_update branch from 2472ebf to 0a322dc Compare April 21, 2021 02:03
@mike-myers-tob mike-myers-tob merged commit 7b4906a into osquery:master Apr 21, 2021
@mike-myers-tob mike-myers-tob deleted the kumarak/systemextension_table_update branch April 21, 2021 16:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
macOS Big Sur For things pertaining to macOS 11.0 macOS Catalina For things pertaining to macOS 10.15 macOS virtual tables
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants