-
Notifications
You must be signed in to change notification settings - Fork 748
Update WLAN XML profile verification so they aren't resent #28296
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
Update WLAN XML profile verification so they aren't resent #28296
Conversation
Codecov ReportAttention: Patch coverage is
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
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
mna
left a comment
There was a problem hiding this 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( | ||
| `<?xml version="1.0"?> |
There was a problem hiding this comment.
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...?)
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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("<Enabled/><Data id=\"EnableScriptBlockInvocationLogging\" value=\"true\"/><Data id=\"ExecutionPolicy\" value=\"AllSigned\"/><Data id=\"Listbox_ModuleNames\" value=\"*\"/><Data id=\"OutputDirectory\" value=\"false\"/><Data id=\"SourcePathForUpdateHelp\" value=\"false\"/>")) | ||
| assert.False(t, IsWLANXML(admxPolicy)) | ||
|
|
||
| assert.True(t, IsWLANXML(xmlEncodedProfile1)) |
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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
|
I went over the PR with Jordan. I can re-review after the next set of changes. |
|
@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 |
getvictor
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
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)).
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/,orbit/changes/oree/fleetd-chrome/changes.See Changes files for more information.