Skip to content

Conversation

@JordanMontgomery
Copy link
Member

@JordanMontgomery JordanMontgomery commented Apr 16, 2025

Fixes #24394 by adding new verification logic to detect and verify these profiles. We only verify a subset of the properties because there are certain settings such as the Authentication which Windows seems to upgrade in circumstances where it can(e.g. WPA2 specified but interface + router supports WPA3 results in WPA3 on the client and there are likely other similar scenarios). After discussion with design team we've decided the limited verification is better than what we had before and a good solution for now.

I know this is extremely heavy on comments but the behavior is strange and non obvious.

Also see latest comment on the issue for some testing discussion: #24394 (comment)

Checklist for submitter

If some of the following don't apply, delete the relevant line.

  • Changes file added for user-visible changes in changes/, orbit/changes/ or ee/fleetd-chrome/changes.
    See Changes files for more information.
  • Added/updated automated tests
  • A detailed QA plan exists on the associated ticket (if it isn't there, work with the product group's QA engineer to add it)
  • Manual QA for all new/changed functionality

@codecov
Copy link

codecov bot commented Apr 16, 2025

Codecov Report

Attention: Patch coverage is 82.40000% with 22 lines in your changes missing coverage. Please review.

Project coverage is 63.98%. Comparing base (183d0d8) to head (84df57c).
Report is 32 commits behind head on main.

Files with missing lines Patch % Lines
server/mdm/microsoft/wlanxml/wlanxml.go 83.01% 12 Missing and 6 partials ⚠️
server/mdm/microsoft/profile_verifier.go 73.33% 3 Missing and 1 partial ⚠️
Additional details and impacted files
@@           Coverage Diff           @@
##             main   #28296   +/-   ##
=======================================
  Coverage   63.98%   63.98%           
=======================================
  Files        1783     1784    +1     
  Lines      171258   171327   +69     
  Branches     4945     4945           
=======================================
+ Hits       109576   109625   +49     
- Misses      53036    53054   +18     
- Partials     8646     8648    +2     
Flag Coverage Δ
backend 65.03% <82.40%> (+<0.01%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

mna
mna previously approved these changes Apr 16, 2025
Copy link
Member

@mna mna left a comment

Choose a reason for hiding this comment

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

Looks great! I think the comments are very useful given that it's complementary to the code and provides insights into why that custom Equal stuff is even required. Just had some minor things as feedback, none are blockers to merge (which is why I also "Approve", meaning - up to you to apply the suggestions here, in a later PR or not at all).


// This is a WLAN XML profile
assert.False(t, IsADMX(
`&lt;?xml version=&quot;1.0&quot;?&gt;
Copy link
Member

Choose a reason for hiding this comment

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

Just curious (I don't know what is ADMX?), why does the XML has to be escaped here? (i.e. why don't we send <?xml...?)

Copy link
Member

Choose a reason for hiding this comment

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

Oh I think it's because that's how we receive it from the host for verification, right?

Copy link
Member Author

Choose a reason for hiding this comment

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

Correct. WE get an XML file with a big XMLEncoded blob in it which is itself an XML file and likewise we send something similar.

type wlanXmlProfileSSIDConfig struct {
SSID []wlanXmlProfileSSID `xml:"SSID"`
// Note that this field is optional so if we ever do more inspection of these policies
// we likely need to
Copy link
Member

Choose a reason for hiding this comment

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

Feels like there was more to come here?

Copy link
Member Author

Choose a reason for hiding this comment

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

Good catch. I wrote so many comments trying to capture all the strangeness I was trying to account for I missed this incomplete one.

Copy link
Member Author

Choose a reason for hiding this comment

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

Actually removed comment since it is no longer relevant

IsWLANXML("&lt;Enabled/&gt;&lt;Data id=\"EnableScriptBlockInvocationLogging\" value=\"true\"/&gt;&lt;Data id=\"ExecutionPolicy\" value=\"AllSigned\"/&gt;&lt;Data id=\"Listbox_ModuleNames\" value=\"*\"/&gt;&lt;Data id=\"OutputDirectory\" value=\"false\"/&gt;&lt;Data id=\"SourcePathForUpdateHelp\" value=\"false\"/&gt;"))
assert.False(t, IsWLANXML(admxPolicy))

assert.True(t, IsWLANXML(xmlEncodedProfile1))
Copy link
Member

Choose a reason for hiding this comment

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

Nit: this test would work nicely as table-driven (simple input -> expected output test cases).

Copy link
Member Author

Choose a reason for hiding this comment

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

Refactored this as a table based test

mna
mna previously approved these changes Apr 16, 2025
@getvictor
Copy link
Member

I went over the PR with Jordan. I can re-review after the next set of changes.

@getvictor
Copy link
Member

@JordanMontgomery When the diff fails, do we log the specific error (what is wrong) or print the error in the UI? This info would be useful if we have to debug this in production.

@JordanMontgomery
Copy link
Member Author

@JordanMontgomery When the diff fails, do we log the specific error (what is wrong) or print the error in the UI? This info would be useful if we have to debug this in production.

We don't currently do this for any profile types as best I can tell except in the really bad cases where we completely fail to unmarshal(which shouldn't be common). Right now the error we show in the UI For these generally comes from us trying to re-Add the profile. I think as the code is currently written the easiest way to debug is probably to capture the fleetd logs which show the OSQuery output and allow comparing the profiles, but that is obviously not great.

We could for all failed profiles add a debug log where we log the profiles(expected + received. My only concern with that would be the possibility we leak secrets into the logs

Copy link
Member

@getvictor getvictor left a comment

Choose a reason for hiding this comment

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

LGTM

@JordanMontgomery JordanMontgomery merged commit de7ce43 into main Apr 18, 2025
52 checks passed
@JordanMontgomery JordanMontgomery deleted the JM-24394-wlan-xml-profile-verification branch April 18, 2025 12:45
JordanMontgomery added a commit that referenced this pull request May 2, 2025
For #9943

This will help us avoid issues like this where the log message never
worked right:
#28296 (comment)

Most of the changes are no-op type changes like removing unneeded
typecast or disabling gosec on reviewed lines of code

# Checklist for submitter

If some of the following don't apply, delete the relevant line.

<!-- Note that API documentation changes are now addressed by the
product design team. -->

- [x] Input data is properly validated, `SELECT *` is avoided, SQL
injection is prevented (using placeholders for values in statements)
- [x] Added/updated automated tests
- [x] A detailed QA plan exists on the associated ticket (if it isn't
there, work with the product group's QA engineer to add it)
- [x] Manual QA for all new/changed functionality
- For Orbit and Fleet Desktop changes:
- [x] Make sure fleetd is compatible with the latest released version of
Fleet (see [Must
rule](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/fleetd-development-and-release-strategy.md)).
- [x] Orbit runs on macOS, Linux and Windows. Check if the orbit
feature/bugfix should only apply to one platform (`runtime.GOOS`).
- [x] Manual QA must be performed in the three main OSs, macOS, Windows
and Linux.
- [x] Auto-update manual QA, from released version of component to new
version (see [tools/tuf/test](../tools/tuf/test/README.md)).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Fleet resending WlanXml CSP unnecessarily is causing errors

4 participants