mirror of
https://github.com/fleetdm/fleet
synced 2026-04-21 13:37:30 +00:00
Remove proposals (unused) (#26646)
The proposals/ directory approach is not used and hasn't been used in 2 years. Removing it to reduce repository clutter.
This commit is contained in:
Lucas Manuel Rodriguez
GitHub
parent
208d4e704d
commit
d87439faac
7 changed files with 0 additions and 644 deletions
|
|
@ -1,115 +0,0 @@
|
|||
# Controlled Rollout proposal
|
||||
|
||||
## Why
|
||||
|
||||
New features are great, everybody loves them. However, new features come by the hand of new code. New code can have bugs
|
||||
or it can have performance regressions.
|
||||
|
||||
Features aren't perfect for all users. Sometimes they are perfect for some users and not others. Sometimes they are
|
||||
perfect for some hosts and not others.
|
||||
|
||||
Rolling out a feature shouldn't always be a binary choice: enabled/disabled. In an ideal world, all features would be
|
||||
enabled by default, everybody would love them all, and they would work flawlessly for all possible use cases.
|
||||
|
||||
We are in the real world, though, which is not ideal. So we should give people running Fleet tools to rollout features
|
||||
slowly, so that they can update infrastructure if needed, or only use a feature within the scope that is useful for
|
||||
them.
|
||||
|
||||
This is a proposal on how this tool could look like and work.
|
||||
|
||||
## How
|
||||
|
||||
We would create a new type of boolean value in our `AppConfig` called `RolloutBoolean`.
|
||||
|
||||
`RolloutBoolean` will have a function `Get(h *fleet.Host) bool`. So instead of doing this:
|
||||
|
||||
```go
|
||||
if ac.HostSettings.EnableHostUsers {
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
We would do:
|
||||
|
||||
```go
|
||||
if ac.HostSettings.EnableHostUsers.Get(host) {
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
In yaml terms, this is what `RolloutBoolean` would be able to parse:
|
||||
|
||||
1. Regular true/false, 0/1, yes/no values
|
||||
|
||||
```yaml
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: config
|
||||
spec:
|
||||
host_settings:
|
||||
enable_software_inventory: false
|
||||
```
|
||||
|
||||
2. Only enable a feature for certain teams:
|
||||
|
||||
```yaml
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: config
|
||||
spec:
|
||||
host_settings:
|
||||
enable_software_inventory:
|
||||
default: false
|
||||
overrides:
|
||||
teams:
|
||||
- team1: true
|
||||
- team2: true
|
||||
```
|
||||
|
||||
2. Enabled for all except a specified team:
|
||||
|
||||
```yaml
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: config
|
||||
spec:
|
||||
host_settings:
|
||||
enable_software_inventory:
|
||||
default: true
|
||||
overrides:
|
||||
teams:
|
||||
- team1: false
|
||||
```
|
||||
|
||||
3. Enabled only for specific hosts:
|
||||
|
||||
```yaml
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: config
|
||||
spec:
|
||||
host_settings:
|
||||
enable_software_inventory:
|
||||
default: false
|
||||
overrides:
|
||||
host_ids:
|
||||
- 3214: true
|
||||
```
|
||||
|
||||
4. Enabled for hosts on a specific platform (as reported by osquery, not in terms of label membership):
|
||||
|
||||
```yaml
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: config
|
||||
spec:
|
||||
host_settings:
|
||||
enable_software_inventory:
|
||||
default: false
|
||||
overrides:
|
||||
platforms:
|
||||
- linux: true
|
||||
```
|
||||
|
||||
The `Get(h *Host) bool` function will use the provided host to define whether the feature is enabled or not based on
|
||||
how it's defined in the configuration.
|
||||
|
|
@ -1,139 +0,0 @@
|
|||
# Detecting Windows OS vulnerabilities
|
||||
|
||||
The first step in detecting Windows vulnerabilities is understanding how they are remediated. Using
|
||||
the CISA list of know vulnerabilities as a sample, it was determined that all vulnerability
|
||||
remediations follow the form of *applying some software patch* and then *following some
|
||||
steps (if any)* so it follows that to determine if a system is susceptible to a vulnerability we will need to
|
||||
check whether a specific software patch was applied and also if the provided steps were followed. So
|
||||
basically we have three problems we need to solve:
|
||||
1. We need a list of vulnerabilities + remediations. Each remediation is composed of a patch + some steps.
|
||||
2. For a given vulnerability we need to determine whether the proper patch was applied.
|
||||
3. For a given vulnerability we need to determine whether the steps (if any) were followed.
|
||||
|
||||
## List of vulnerabilities
|
||||
|
||||
To get the list of vulnerabilities we can use the [Microsoft Security Updates API](https://api.msrc.microsoft.com/cvrf/v2.0/swagger/index). This [endpoint](api.msrc.microsoft.com/cvrf/v2.0/document/yyyy-mm) in particular exposes all the security updates released for yyyy-mmm formatted according to the [Common Vulnerability Reporting Framework](http://docs.oasis-open.org/csaf/csaf-cvrf/v1.2/csaf-cvrf-v1.2.html#:~:text=The%20CSAF%20Common%20Vulnerability%20Reporting,impact%20and%20remediation%20among%20interested) (cvrf) format, this cvrf document will include entries for vulnerabilities, how to patch them and what products are affected.
|
||||
|
||||
For example, say we have a host running *Windows 10 Version 21H2 x64* and we want to determine whether that host is susceptible to *CVE-2022-26925*. Looking at https://api.msrc.microsoft.com/cvrf/v2.0/document/2022-May we can see that *Windows 10 Version 21H2 for x64* is assigned the Product ID **11931**:
|
||||
|
||||
```
|
||||
...
|
||||
<prod:ProductTree>
|
||||
...
|
||||
<prod:Branch Type="Product Family" Name="Windows">
|
||||
...
|
||||
<prod:FullProductName ProductID="11931">Windows 10 Version 21H2 for x64-based Systems</prod:FullProductName>
|
||||
...
|
||||
</prod:Branch>
|
||||
…
|
||||
<prod:ProductTree>
|
||||
…
|
||||
```
|
||||
|
||||
Looking at the matching vulnerability element (`<vuln:Vulnerability Ordinal="47">`) *CVE-2022-26925*, we can see that
|
||||
*Windows 10 Version 21H2 x64* is indeed affected by it:
|
||||
|
||||
```
|
||||
<vuln:ProductStatuses>
|
||||
<vuln:Status Type="Known Affected">
|
||||
...
|
||||
<vuln:ProductID>11931</vuln:ProductID>
|
||||
...
|
||||
</vuln:Status>
|
||||
</vuln:ProductStatuses>
|
||||
```
|
||||
|
||||
And also the remediation steps:
|
||||
|
||||
```
|
||||
<vuln:Remediations>
|
||||
…
|
||||
<vuln:Remediation Type="Vendor Fix">
|
||||
<vuln:Description>5013942</vuln:Description>
|
||||
<vuln:URL>https://catalog.update.microsoft.com/v7/site/Search.aspx?q=KB5013942</vuln:URL>
|
||||
<vuln:Supercedence>5012599</vuln:Supercedence>
|
||||
..
|
||||
<vuln:ProductID>11931</vuln:ProductID>
|
||||
...
|
||||
<vuln:RestartRequired>Yes</vuln:RestartRequired>
|
||||
…
|
||||
</vuln:Remediation>
|
||||
<vuln:Remediation Type="Known Issue">
|
||||
<vuln:Description>5013942</vuln:Description>
|
||||
<vuln:URL>https://support.microsoft.com/help/5013942</vuln:URL>
|
||||
...
|
||||
<vuln:ProductID>11931</vuln:ProductID>
|
||||
</vuln:Remediation>
|
||||
</vuln:Remediations>
|
||||
```
|
||||
|
||||
For the previous extract we can determine four things:
|
||||
1. The vulnerability was patched (‘Vendor Fix’) on the **KB5013942** update.
|
||||
2. **KB5013942** supersedes **KB5012599** (this is useful for handling cumulative updates).
|
||||
3. After applying **KB5013942** the system will need to be restarted (which can be viewed as an extra step).
|
||||
4. There is also some more info about the vulnerability that might include some extra steps to follow (‘Known Issue’).
|
||||
|
||||
|
||||
## Determine whether the proper patch was applied
|
||||
|
||||
Luckily for us [osquery 5.4](https://github.com/osquery/osquery/pull/7407) will include a new table
|
||||
that exposes windows updates, so we won’t need to do much on the osquery data collection side of
|
||||
things. Here’s what I get when selecting all from the new table on my Windows test machine (Windows 10 Version 21H2 x64):
|
||||
|
||||
| client_app_id | date | description | hresult | operation | result_code | server_selection | service_id | support_url | title | update_id | update_revision |
|
||||
|---------------------------------------------------------------------|------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------|--------------|-------------|------------------|--------------------------------------|------------------------------------------------|------------------------------------------------------------------------------------------------------------------|--------------------------------------|-----------------|
|
||||
| MoUpdateOrchestrator | 1658271402 | Install this update to revise the files that are used to detect viruses, spyware, and other potentially unwanted software. Once you have installed this item, it cannot be removed. | 0 | Installation | Succeeded | WindowsUpdate | | https://go.microsoft.com/fwlink/?LinkId=52661 | Security Intelligence Update for Microsoft Defender Antivirus - KB2267602 (Version 1.371.442.0) | 688fe8b8-e59d-44c8-b083-7ab25a4317f4 | 200 |
|
||||
| MoUpdateOrchestrator | 1658270728 | Install this update to resolve issues in Windows. For a complete listing of the issues that are included in this update, see the associated Microsoft Knowledge Base article for more information. After you install this item, you may have to restart your computer. | -2145116140 | Installation | InProgress | Others | 8b24b027-1dee-babb-9a95-3517dfb9c552 | https://support.microsoft.com/help/5015807 | 2022-07 Cumulative Update for Windows 10 Version 21H2 for x64-based Systems (KB5015807) | 3a328459-dd2c-4af7-97db-8424da0d3e72 | 1 |
|
||||
| MoUpdateOrchestrator | 1658230218 | Install this update to resolve issues in Windows. For a complete listing of the issues that are included in this update, see the associated Microsoft Knowledge Base article for more information. After you install this item, you may have to restart your computer. | -2147024784 | Installation | Failed | Others | 8b24b027-1dee-babb-9a95-3517dfb9c552 | https://support.microsoft.com/help/5015807 | 2022-07 Cumulative Update for Windows 10 Version 21H2 for x64-based Systems (KB5015807) | 3a328459-dd2c-4af7-97db-8424da0d3e72 | 1 |
|
||||
| Windows Defender | 1658228495 | Install this update to revise the files that are used to detect viruses, spyware, and other potentially unwanted software. Once you have installed this item, it cannot be removed. | 0 | Installation | Succeeded | WindowsUpdate | | https://go.microsoft.com/fwlink/?LinkId=52661 | Security Intelligence Update for Microsoft Defender Antivirus - KB2267602 (Version 1.371.415.0) | a0620c31-004f-4e4f-a15c-5172a3d2f3a6 | 200 |
|
||||
| MoUpdateOrchestrator | 1658226954 | After the download, this tool runs one time to check your computer for infection by specific, prevalent malicious software (including Blaster, Sasser, and Mydoom) and helps remove any infection that is found. If an infection is found, the tool will display a status report the next time that you start your computer. A new version of the tool will be offered every month. If you want to manually run the tool on your computer, you can download a copy from the Microsoft Download Center, or you can run an online version from microsoft.com. This tool is not a replacement for an antivirus product. To help protect your computer, you should use an antivirus product. | 0 | Installation | Succeeded | WindowsUpdate | | http://support.microsoft.com | Windows Malicious Software Removal Tool x64 - v5.103 (KB890830) | 675d532b-cdd5-4f87-a918-72af430c86a9 | 200 |
|
||||
| MoUpdateOrchestrator | 1658226800 | After the download, this tool runs one time to check your computer for infection by specific, prevalent malicious software (including Blaster, Sasser, and Mydoom) and helps remove any infection that is found. If an infection is found, the tool will display a status report the next time that you start your computer. A new version of the tool will be offered every month. If you want to manually run the tool on your computer, you can download a copy from the Microsoft Download Center, or you can run an online version from microsoft.com. This tool is not a replacement for an antivirus product. To help protect your computer, you should use an antivirus product. | -2145124341 | Installation | Aborted | WindowsUpdate | | http://support.microsoft.com | Windows Malicious Software Removal Tool x64 - v5.103 (KB890830) | 675d532b-cdd5-4f87-a918-72af430c86a9 | 200 |
|
||||
| MoUpdateOrchestrator | 1658225364 | Install this update to resolve issues in Windows. For a complete listing of the issues that are included in this update, see the associated Microsoft Knowledge Base article for more information. After you install this item, you may have to restart your computer. | 0 | Installation | Succeeded | WindowsUpdate | | http://support.microsoft.com | 2022-06 Cumulative Update for .NET Framework 3.5 and 4.8 for Windows 10 Version 21H2 for x64 (KB5013887) | 17b120c7-57a2-47d3-9128-3b8fa9a22c42 | 200 |
|
||||
| MoUpdateOrchestrator | 1658225234 | Install this update to resolve issues in Windows. For a complete listing of the issues that are included in this update, see the associated Microsoft Knowledge Base article for more information. After you install this item, you may have to restart your computer. | -2145124341 | Installation | Aborted | WindowsUpdate | | http://support.microsoft.com | 2022-06 Cumulative Update for .NET Framework 3.5 and 4.8 for Windows 10 Version 21H2 for x64 (KB5013887) | 17b120c7-57a2-47d3-9128-3b8fa9a22c42 | 200 |
|
||||
| MoUpdateOrchestrator | 1658225225 | A security issue has been identified in a Microsoft software product that could affect your system. You can help protect your system by installing this update from Microsoft. For a complete listing of the issues that are included in this update, see the associated Microsoft Knowledge Base article. After you install this update, you may have to restart your system. | 0 | Installation | Succeeded | WindowsUpdate | | http://support.microsoft.com | 2022-04 Update for Windows 10 Version 21H2 for x64-based Systems (KB5005463) | 9151c073-854c-474e-8e4c-3b7b067824b1 | 200 |
|
||||
| MoUpdateOrchestrator | 1658225201 | A security issue has been identified in a Microsoft software product that could affect your system. You can help protect your system by installing this update from Microsoft. For a complete listing of the issues that are included in this update, see the associated Microsoft Knowledge Base article. After you install this update, you may have to restart your system. | -2145124341 | Installation | Aborted | WindowsUpdate | | http://support.microsoft.com | 2022-04 Update for Windows 10 Version 21H2 for x64-based Systems (KB5005463) | 9151c073-854c-474e-8e4c-3b7b067824b1 | 200 |
|
||||
| MoUpdateOrchestrator | 1658224963 | Install this update to resolve issues in Windows. For a complete listing of the issues that are included in this update, see the associated Microsoft Knowledge Base article for more information. After you install this item, you may have to restart your computer. | 0 | Installation | Succeeded | WindowsUpdate | | http://support.microsoft.com | 2022-02 Cumulative Update Preview for .NET Framework 3.5 and 4.8 for Windows 10 Version 21H2 for x64 (KB5010472) | 89858baf-a5ff-4c7e-b81b-037c0c17155a | 200 |
|
||||
| MoUpdateOrchestrator | 1658224904 | Install this update to resolve issues in Windows. For a complete listing of the issues that are included in this update, see the associated Microsoft Knowledge Base article for more information. After you install this item, you may have to restart your computer. | -2145124341 | Installation | Aborted | WindowsUpdate | | http://support.microsoft.com | 2022-02 Cumulative Update Preview for .NET Framework 3.5 and 4.8 for Windows 10 Version 21H2 for x64 (KB5010472) | 89858baf-a5ff-4c7e-b81b-037c0c17155a | 200 |
|
||||
| MoUpdateOrchestrator | 1658224899 | A security issue has been identified in a Microsoft software product that could affect your system. You can help protect your system by installing this update from Microsoft. For a complete listing of the issues that are included in this update, see the associated Microsoft Knowledge Base article. After you install this update, you may have to restart your system. | -2145116140 | Installation | InProgress | Others | 8b24b027-1dee-babb-9a95-3517dfb9c552 | https://support.microsoft.com/help/4023057 | 2022-04 Update for Windows 10 Version 21H2 for x64-based Systems (KB4023057) | a329b681-ce8c-431d-99f7-052e2901adcb | 1 |
|
||||
| MoUpdateOrchestrator | 1658224892 | Install this update to resolve issues in Windows. For a complete listing of the issues that are included in this update, see the associated Microsoft Knowledge Base article for more information. After you install this item, you may have to restart your computer. | -2145124341 | Installation | Aborted | WindowsUpdate | | http://support.microsoft.com | 2022-02 Cumulative Update Preview for .NET Framework 3.5 and 4.8 for Windows 10 Version 21H2 for x64 (KB5010472) | 89858baf-a5ff-4c7e-b81b-037c0c17155a | 200 |
|
||||
| Windows Defender | 1658222131 | Install this update to revise the files that are used to detect viruses, spyware, and other potentially unwanted software. Once you have installed this item, it cannot be removed. | 0 | Installation | Succeeded | WindowsUpdate | | https://go.microsoft.com/fwlink/?LinkId=52661 | Security Intelligence Update for Microsoft Defender Antivirus - KB2267602 (Version 1.371.400.0) | e73cc969-7675-4d5f-a635-0dd5511a266b | 200 |
|
||||
| Update;ScanForUpdates | 1658190023 | 9NBLGGH3FRZM-1152921505694106457 | -2145124300 | Installation | Failed | Others | 855e8a7c-ecb4-4ca3-b045-1dfa50104289 | | 9NBLGGH3FRZM-Microsoft.VCLibs.140.00 | d82f41c1-893a-4a90-ac94-8f83da52a274 | 1 |
|
||||
| MoUpdateOrchestrator | 1658189063 | Install this update to revise the files that are used to detect viruses, spyware, and other potentially unwanted software. Once you have installed this item, it cannot be removed. | 0 | Installation | Succeeded | WindowsUpdate | | https://go.microsoft.com/fwlink/?LinkId=52661 | Security Intelligence Update for Microsoft Defender Antivirus - KB2267602 (Version 1.371.376.0) | 2b325cd4-4ff1-4ba2-aca7-8a2cb19e4633 | 200 |
|
||||
| MoUpdateOrchestrator | 1658185542 | Install this update to revise the files that are used to detect viruses, spyware, and other potentially unwanted software. Once you have installed this item, it cannot be removed. | 0 | Installation | Succeeded | WindowsUpdate | | https://go.microsoft.com/fwlink/?LinkId=52661 | Security Intelligence Update for Microsoft Defender Antivirus - KB2267602 (Version 1.371.386.0) | 821547ac-9c27-4397-93bc-d51f0aeb2059 | 200 |
|
||||
| Microsoft Defender Antivirus (77BDAF73-B396-481F-9042-AD358843EC24) | 1657929544 | This package will update Microsoft Defender Antivirus antimalware platformΓÇÖs components on the user machine. | 0 | Installation | Succeeded | WindowsUpdate | | https://go.microsoft.com/fwlink/?linkid=862339 | Update for Microsoft Defender Antivirus antimalware platform - KB4052623 (Version 4.18.2205.7) | 2dd6d08b-6754-46b5-bfc8-cde6ad24152f | 200 |
|
||||
| MoUpdateOrchestrator | 1657929207 | Install this update to revise the files that are used to detect viruses, spyware, and other potentially unwanted software. Once you have installed this item, it cannot be removed. | 0 | Installation | Succeeded | WindowsUpdate | | https://go.microsoft.com/fwlink/?LinkId=52661 | Security Intelligence Update for Microsoft Defender Antivirus - KB2267602 (Version 1.371.203.0) | 8325b53b-d4a4-4459-849f-5892c92404ae | 200 |
|
||||
|
||||
|
||||
While playing around with this, I did notice what seems to be a bug. There are two entries for **KB5015807**: one marked as Failed which is true, because the first time I tried to install this patch it failed and the other marked as InProgress which is false because the patch was installed correctly.
|
||||
|
||||
We can store all the props if we want, but I would say that the two most important ones are:
|
||||
|
||||
- date: To determine when the patch was applied.
|
||||
- result_code: To determine whether the update was applied or not.
|
||||
- title: To extract the update id.
|
||||
|
||||
The major complication here will be dealing with the fact that windows updates are cumulative.
|
||||
Looking back at our previous example, given the entries in the windows_updates_history table, we
|
||||
want to determine whether the system is susceptible to *CVE-2022-26925*, we know that vulnerability
|
||||
was patched in **KB5013942** alas, there are no entries matching **KB5013942** in the
|
||||
*windows_updates_history* table but, if we look at the security updates for the next month
|
||||
https://api.msrc.microsoft.com/cvrf/v2.0/document/2022-Jun we can see that **KB5013942** was
|
||||
superseded by **KB5014699** and then if we look at the security updates for the following month
|
||||
https://api.msrc.microsoft.com/cvrf/v2.0/document/2022-Jul we can see that **KB5014699** was in
|
||||
turn superseded by **KB5015807** which is contained in the windows_updates_history table and thus we can
|
||||
say that the host is not susceptible to *CVE-2022-26925*.
|
||||
|
||||
Given the graph nature of the data, we might want to consider storing the parsed list of vulnerabilities as graph instead of a relational table as we typically do.
|
||||
|
||||
## Determine whether the steps (if any) were followed
|
||||
|
||||
This is the hardest part of the problem and probably the bit we might not be able to solve at the
|
||||
moment. Not all vulnerability remediations include extra steps, but if they do, they are written in
|
||||
natural language as a
|
||||
series of steps intended to be followed by a human operator not as a series of
|
||||
declarative statements about the system state (like the OVAL definitions we use for detecting
|
||||
vulnerabilities in Linux).
|
||||
|
||||
AFAIK the only step we will be able to check is whether the system was restarted after a patch was
|
||||
applied, other types of steps will require either some kind of natural language processing or having
|
||||
a human in the middle translating the steps into a parsable format.
|
||||
|
|
@ -1,51 +0,0 @@
|
|||
# Goal
|
||||
|
||||
We need `fleetctl package` functionality to generate all types of packages (PKG, MSI, DEB and RPM) from Linux.
|
||||
|
||||
# How
|
||||
|
||||
Create a new Docker image `fleetdm/fleetctl` that will contain `fleetctl` and all the dependencies ready to create packages.
|
||||
|
||||
Users can then use the image to generate packages
|
||||
```sh
|
||||
$ docker run ... fleetdm/fleetctl:latest package --type={pkg|msi|deb|rpm} ...
|
||||
```
|
||||
|
||||
## DEB and RPM
|
||||
|
||||
DEB and RPM package generation is already native and no extra dependencies are required (uses https://github.com/goreleaser/nfpm).
|
||||
|
||||
## MSI
|
||||
|
||||
### Packaging
|
||||
|
||||
We will need the same dependencies from `fleetdm/wix:latest` on the new `fleetdm/fleetctl:latest` image.
|
||||
|
||||
### Signing (stretch goal)
|
||||
|
||||
For `.msi` signing functionality:
|
||||
- The [relic](https://github.com/sassoftware/relic) tool seems to allow `.msi` signing (in Pure Go).
|
||||
- Alternatively, the [osslsigncode](https://github.com/mtrojnar/osslsigncode) tool could be embedded on the image.
|
||||
|
||||
This is mentioned as a stretch goal because we currently don't have `.msi` signing functionality in `fleetctl package`.
|
||||
|
||||
## PKG
|
||||
|
||||
### Packaging
|
||||
|
||||
To generate a `.pkg` we will need the same dependencies from `fleetdm/bomutils:latest` on the new `fleetdm/fleetctl:latest` image.
|
||||
|
||||
### Signing
|
||||
|
||||
The [relic](https://github.com/sassoftware/relic) tool seems to allow `.pkg` signing (in Pure Go).
|
||||
|
||||
### Notarization
|
||||
|
||||
#### Upload
|
||||
|
||||
We can implement a Go package that uses the new [Notary API](https://developer.apple.com/documentation/notaryapi) to upload and notarize a `.pkg` (pure Go solution).
|
||||
|
||||
#### No Stapling
|
||||
|
||||
The Notary API currently does not offer a way to "staple" a package, and the `stapler` tool that allows this is only available on macOS.
|
||||
It seems stapling is recommended but not a must, see [#116812](https://developer.apple.com/forums/thread/116812).
|
||||
|
|
@ -1,95 +0,0 @@
|
|||
# Fleetctl trigger
|
||||
|
||||
## Goal
|
||||
|
||||
As a user, I would like to trigger a set of async jobs using `fleetctl`. For example, I’d like to
|
||||
trigger a vuln scan, or an MDM dep sync.
|
||||
|
||||
The proposed solution to accomplish this goal enables a new CLI command:
|
||||
`fleetctl trigger --name <NAME>`.
|
||||
|
||||
## Background
|
||||
|
||||
Currently, the Fleet server uses the `schedule` package to create sets of defined jobs that are run
|
||||
serially at defined intervals. The initial schedule interval must be specified at the point the
|
||||
schedule is instantiated via `schedule.New`. Optionally, `schedule. WithConfigReloadInterval`
|
||||
accepts a reload interval function. If specified, the reload interval function is periodically
|
||||
called and its return value becomes the new the schedule interval. This mechanism allows the
|
||||
schedule interval to be modified by user, for example, by changing the app config; however, there no
|
||||
mechanism currently to trigger async jobs on an ad hoc basis.
|
||||
|
||||
## Proposal
|
||||
|
||||
### New CLI command `fleetctl trigger --name <NAME>`
|
||||
- Upon this command, the CLI client makes a request to a new authenticated endpoint (see below) to
|
||||
trigger an ad hoc run of the named schedule.
|
||||
|
||||
### New `schedule` option `WithTrigger`
|
||||
- This option adds a `trigger` channel on the `schedule` struct that will trigger an ad hoc run of
|
||||
the scheduled jobs.
|
||||
- The trigger channel for each `schedule` is exposed via a new `schedules` map on the `Service` struct.
|
||||
|
||||
### New endpoint `GET /trigger?name={:name}`
|
||||
- The request handler first calls `ds.Lock` to check if the named schedule is locked.
|
||||
- If the named schedule is unlocked, request handler sends a trigger signal on the schedule's
|
||||
trigger channel and the server responds with status `202 Accepted`.
|
||||
- If the named schedule is locked (presumably because the schedule is currently running), the server
|
||||
responds with status `409 Conflict` and includes a message indicating the schedule is currently
|
||||
locked. It is up to the user to retry. To facilitate retries, the response message could be expanded to
|
||||
include additional status information, such as the expiration time of the current lock.
|
||||
|
||||
### Schedule locks
|
||||
- Currently, lock duration is based on the schedule interval.
|
||||
- Once an instance takes the lock, it will hold the lock for the duration of the interval, even
|
||||
after it has completed the jobs in the schedule.
|
||||
- For long-running jobs, the lock may expire before the current instance completes its run,
|
||||
meaning that it is currently possible for another instance to start an overlapping job.
|
||||
- If the lockholder instance is terminated or killed, locks are not released, which may frustrate
|
||||
a user's attempt to configure a shorter schedule interval before the lock held by the dead
|
||||
instance expires.
|
||||
|
||||
- Under this proposal, locks become more dynamic.
|
||||
- Current lockholder releases its lock once it finishes running the schedule.
|
||||
- Graceful shutdown process handles release of locks upon termination signals. Jobs are
|
||||
preemptable and an interrupt function must be specified for each job,
|
||||
e.g., `schedule.New(...).WithJob("job_name", jobFn, interruptFn)`.
|
||||
- As a fallback for cases that can't be handled via graceful shutdown (e.g., `SIGKILL`), the
|
||||
expiration for a lock is initially set to a relatively short default duration (e.g., 5 minutes).
|
||||
The expiration is then periodically extended by the current instance so long as scheduled jobs
|
||||
are running. If the current instance dies without graceful shutdown, the lock will only be held
|
||||
by the dead instance for a short period.
|
||||
|
||||
### Additional UX considerations
|
||||
- What are some potential options that would be useful for the `fleetctl trigger` command?
|
||||
- Request the current status of the the named schedule without triggering a new run.
|
||||
For example, `--status` could provide the user with the running time of the schedule (this would
|
||||
require that we expand the `locks` table to include additional timestamp information, such as
|
||||
lock start time and lock release time).
|
||||
- Other useful options?
|
||||
|
||||
- What rules should determine when the interval ticker resets? Consider the following cases where
|
||||
`s.scheduleInterval = 1*time.Hour`:
|
||||
- The schedule is triggered at 55 minutes into the 1-hour interval and takes 1 minute to complete.
|
||||
When should the schedule run again?
|
||||
(a) after 4 minutes;
|
||||
(b) after 1 hour;
|
||||
(c) after 1 hour plus 4 minutes;
|
||||
(d) other
|
||||
- The schedule is triggered at 55 minutes into the 1-hour interval and takes 11 minutes to complete.
|
||||
When should the schedule run again?
|
||||
(a) immediately;
|
||||
(b) after 1 hour;
|
||||
(c) after 54 minutes;
|
||||
(d) other
|
||||
|
||||
- What should be logged?
|
||||
- Debug log if schedule runtime exceeds schedule interval to aid detection/troubleshooting of
|
||||
long-running jobs.
|
||||
- Other useful logs?
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -1,63 +0,0 @@
|
|||
# Planning for a FIPS Compliant Fleet Server for Linux
|
||||
|
||||
This document outlines the steps involved in building a version of the Fleet server that meets the requirements of the Federal Information Processing Standards (FIPS) 140-2 security standard.
|
||||
|
||||
## Summary of cryptographic operations in Fleet
|
||||
|
||||
To make the Fleet server FIPS 140-2 compliant, all cryptographic operations must use a FIPS 140-2 certified cryptographic library.
|
||||
|
||||
Fleet uses cryptographic operations in the following features:
|
||||
- Fleet uses TLS as a client for the following features:
|
||||
- Fleet can conect to MySQL and Redis using TLS.
|
||||
- Vulnerability processing uses TLS client to retrieve data from different sources.
|
||||
- Automations: Webhooks, JIRA and Zendesk integrations make use of a TLS client.
|
||||
- Single Sign On uses TLS to retrieve IdP metadata (from the configured MetadataURL).
|
||||
- MDM functionality connects via TLS to Apple servers (DEP enrollment configuration).
|
||||
- Fleet uses TLS to stream logs to many data stream systems (Kafka, Lambda, Kinesis, Firehose, etc.).
|
||||
- Fleet can act as a TLS server (can terminate TLS).
|
||||
- User authentication: Fleet uses password hashing to store and authenticate user credentials.
|
||||
- The Single Sign On (SSO) feature in Fleet performs cryptographic verification of `SAMLResponse`s signatures. Fleet uses [goxmldsig](https://github.com/russellhaering/goxmldsig) which uses golang's stdlib crypto (`crypto/x509`, `crypto/rsa`, `crypto/sha256`, `crypto/tls` which are all compliant primitives)
|
||||
- Fleet uses `crypto/rand` to generate secrets for authentication ("session tokens" and "node keys" which are used for authenticating users and devices respectively).
|
||||
- MDM functionality (for Windows and macOS) makes use of cryptographic operations (e.g. Fleet acts as a SCEP CA server for authenticating devices)
|
||||
- Fleet license check code uses `JWT` which uses `ECDSA` for public signatures (ECDSA is a FIPS-compliant primitive).
|
||||
|
||||
All these operations (except password hashing, see [Password hashing](#password-hashing) below) make use of Go's `crypto` standard library.
|
||||
|
||||
## Building Go with BoringSSL as cryptographic backend
|
||||
|
||||
As of today, the recommended way to make your Go application be FIPS 140-2 compliant is to use the BoringSSL crypto backend instead of the standard library `crypto` packages.
|
||||
|
||||
Since we use Go 1.19, we only need to build fleet with `CGO_ENABLED=1` (already the case because of our sqlite3 dependency) and with `GOEXPERIMENT=boringcrypto`. This will automatically make Fleet use the BoringSSL cryptographic primitives instead of the stdlib `crypto` implementation (without requiring any code changes).
|
||||
|
||||
See the [POC]https://github.com/fleetdm/fleet/compare/13288-poc-fleet-fips?expand=1()).
|
||||
|
||||
> Source: https://kupczynski.info/posts/fips-golang/
|
||||
|
||||
## Password hashing
|
||||
|
||||
For password hashing Fleet currently uses the [bcrypt](https://en.wikipedia.org/wiki/Bcrypt) function.
|
||||
To be FIPS 140-2 compliant, Fleet will have to use [PBKDF2](https://en.wikipedia.org/wiki/PBKDF2] instead (with SHA-256 as hashing primitive).
|
||||
|
||||
> Source: https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-132.pdf
|
||||
|
||||
## Summary of tasks
|
||||
|
||||
Assumptions around the first customer using the FIPS build:
|
||||
- All MDM funtionality will be disabled/not-used.
|
||||
- The Fleet server won't be doing TLS termination. Thus we don't need to verify/test such feature.
|
||||
- This build will be used as part of a new deployment (not migrating an existing one). This is important because we have to change the password hashing algorithm thus to reduce complexity on the first iteration we don't need to worry about migrating from old to new password hashing.
|
||||
- The `fleetctl` command is outside the scope.
|
||||
|
||||
Tasks:
|
||||
|
||||
- Double check if any cryptographic operations in Fleet were missed in this analysis. // 1 pt.
|
||||
- Add a new target `fleet-fips` to the `Makefile` to build Fleet in FIPS mode. (Would set `GOEXPERIMENT=boringcrypto CGO_ENABLED=1`.) Smoke test the Fleet server when built this way. (See the [POC]https://github.com/fleetdm/fleet/compare/13288-poc-fleet-fips?expand=1()) // 1 pt.
|
||||
- Make changes in goreleaser yamls to create a new docker image fleetdm/fleet-fips // 2 pt.
|
||||
- Perform full QA of the Feet docker image FIPS build (by full QA we mean: we need to test ALL Fleet features). This should be performed by a QA engineer. // 5 pt.
|
||||
- Perform any code changes to fleetd (and add documentation for vanilla osquery) to be able to connect (via TLS) to a FIPS-compliant Fleet. We will know if this is necessary from the previous task (QA). // 2 pt.
|
||||
- Add tests to make sure the Fleet server TLS client is using the FIPS approved ciphers when connecting to TLS servers (SSO, users, vuln processing, webhooks). E.g. by using TLS servers that will fail the connection if the FIPS ciphers are not used. // 3 pt.
|
||||
- Replace bcrypt with PBKDF2 for password hashing (when compiling in FIPS mode) // 5 pt. (assumming we don't need to migrate from bcrypt)
|
||||
- Terminate the Fleet sever if MDM or TLS server is enabled when running the FIPS build (security measure). // 1 pt.
|
||||
- Check if `crypto/subtle` (used by the `/metrics` endpoint for HTTP basic auth) is implemented by BoringSSL. // 1 pt.
|
||||
- Loadtest the Fleet server with expected number of devices. // 5 pt. (depends on number of hosts)
|
||||
- Deploy the Fleet FIPS docker image and dependencies to a FIPS enabled AWS endpoint // 5 pt.
|
||||
|
|
@ -1,64 +0,0 @@
|
|||
# Token Rotation for Fleet Desktop
|
||||
|
||||
This file is based on the original proposal described at [#6348](https://github.com/fleetdm/fleet/issues/6348) modified based on a few lessons we learned and the new communication channel between Orbit and the Fleet server introduced in https://github.com/fleetdm/fleet/issues/6851
|
||||
|
||||
**Compatibility**
|
||||
|
||||
| | Fleet Desktop < v1.0.0 | Fleet Destkop >= v1.0.0 |
|
||||
| -------------- | --------------------------------- | ----------------------- |
|
||||
| Server < 4.21 | OK/Rotation disabled | OK/Rotation disabled |
|
||||
| Server >= 4.21 | Fleet Destkop breaks after 1 hour | OK/Rotation enabled |
|
||||
|
||||
|
||||
## Fleet Server
|
||||
|
||||
1. Add a new endpoint `POST /orbit/<orbit_node_key>/device_token` to create/update device tokens
|
||||
1. Add `created_at` and `updated_at` columns to the `host_device_auth` table.
|
||||
2. Do `INSERT ON DUPLICATE KEY token=token` and not `update updated_at` if the token didn't change.
|
||||
1. Condsider a token expired if `now - updated_at > 1h`, APIs will return the usual authentication error when a token is expired.
|
||||
1. The server doesn't need to make the `orbit_info` in the "extra detail queries" set anymore.
|
||||
|
||||
## Orbit
|
||||
|
||||
1. When Orbit starts
|
||||
1. If we have a token, load and verify its validity by making a request to the Fleet Server
|
||||
1. If we don't have a token or if the token is invalid, [rotate the token](#token-rotation)
|
||||
|
||||
1. Orbit will have two tickers running:
|
||||
- **Ticker I**: runs every 5 minutes and verifies that the current token is still valid by making a request to the Fleet Server. This is to guard against the server invalidating the token (eg: DB restored from back-up, token `updated_at` manually changed, clocks out of sync etc.) If the token is invalid, it [starts a rotation](#token-rotation).
|
||||
- **Ticker II**: runs every 30 seconds and verifies the `mtime` of the identifier file, if `now - mtime > 1h` [starts a rotation](#token-rotation). A short interval (could be even shorter) is needed in case the computer was shut-down or went to sleep.
|
||||
|
||||
**Token Rotation**
|
||||
|
||||
To rotate a token, Orbit will generate a valid UUID and:
|
||||
|
||||
1. Write the value to the `identifier` file, we do this first to signal to Fleet Desktop that a rotation is happening and we can ensure it never operates on an invalid token during the exchange.
|
||||
2. Do a `POST /orbit/<orbit_node_key>/device_token` with the new token value, retry three times in case of failure.
|
||||
|
||||
**Compatibility**
|
||||
|
||||
1. Keep returning `device_auth_token` in the `orbit_info` table, we might want to do this forever anyway to support live queries.
|
||||
2. When Orbit starts, check if the server supports creating tokens via the API, if it doesn't:
|
||||
1. Don't do any kind of check or rotation
|
||||
2. Start a goroutine using `oklog.Group` to ping the server every 10 minutes and see if it supports token rotation. If it does, return from the group actor, which will make Orbit restart.
|
||||
3. Orbit will keep sending the `FLEET_DESKTOP_DEVICE_URL` variable to accomodate old Fleet Destkop versions.
|
||||
|
||||
## Fleet Desktop
|
||||
|
||||
1. Fleet Desktop will receive the path to the identifier file as an environment variable.
|
||||
2. As soon as Flet Desktop starts, it reads the identifier file and caches the `mtime` value in memory.
|
||||
3. Fleet Desktop will have a ticker running every ~5 seconds to check for the `mtime` of the identifier file, if the value differs from the one stored in memory:
|
||||
1. Disable all tray items and show "Connecting..."
|
||||
2. Initialize a ticker to check for the validity of the token, enable the tray items again once we have a valid token.
|
||||
|
||||
**Misc**
|
||||
|
||||
- As soon as any request fails, disable the tray items and show "Connecting..."
|
||||
|
||||
## Release order
|
||||
|
||||
After things have been tested on unstable channels and Dogfood, it's important to release in the following order:
|
||||
|
||||
1. Orbit to the stable channel
|
||||
2. Fleet Desktop to the stable channel
|
||||
3. Fleet Server
|
||||
|
|
@ -1,117 +0,0 @@
|
|||
# Improving vulnerability detection for MacOS
|
||||
|
||||
[6001](https://github.com/fleetdm/fleet/issues/6001) identified some problems with our
|
||||
current approach to vulnerability detection on MacOS:
|
||||
|
||||
- The version reported by software does not fit the standard format. For example, Zoom reports the version as 5.8.3 (2240).
|
||||
- The app name includes extra terms that don't appear in the title. For example, zoom.us is treated
|
||||
as zoom us (2 terms) and does not match the title commonly used for zoom eg "Zoom 4.6.9 for macOS"
|
||||
or "Zoom Meetings 5.8.0 for macOS".
|
||||
- Sometimes the CPE dictionary is incomplete. For example, CVE-2021-24043 should have a matching CPE `cpe:2.3:a:whatsapp:whatsapp:2.2145.0:*:*:*:desktop:*:*:*`, but it is absent. Also not that it would not match on windows because target_sw is empty, but we try to match on windows*. Removing the target_sw would lead to many false positives.
|
||||
|
||||
Our current approach to CPE binding consists of matching the `software name` against the `CPE title` along with the `software version`. Instead, I propose we
|
||||
try to match the software vendor and name parts against the CPE vendor and product parts (standardizing the values when
|
||||
needed) and then we can programmatically look at the version (and the rest of the CPE parts) to
|
||||
determine what CVEs match a given CPE. In other words, instead of looking at CPEs as just strings,
|
||||
we should be looking at them as sets:
|
||||
|
||||
So this:
|
||||
|
||||
```
|
||||
cpe:2.3:a:microsoft:edge:79.0.309.68:*:*:*:*:*:*:*
|
||||
cpe:2.3:a:microsoft:edge:80.0.361.48:*:*:*:*:*:*:*
|
||||
cpe:2.3:a:microsoft:edge:80.0.361.50:*:*:*:*:*:*:*
|
||||
cpe:2.3:a:microsoft:edge:80.0.361.50:*:*:*:*:windows:*:*
|
||||
```
|
||||
Can be visualized as this:
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
id1((vendor: microsoft)) --> id2((product: edge))
|
||||
id2((product: edge)) --> id3((version: 79.0.309.68))
|
||||
id2((product: edge)) --> id4((version: 80.0.361.48))
|
||||
id2((product: edge)) --> id5((version: 80.0.361.50))
|
||||
id3((version: 79.0.309.68)) --> id6((cve_1))
|
||||
id3((version: 79.0.309.68)) --> id7((cve_2))
|
||||
id4((version: 80.0.361.48)) --> id8((cve_3))
|
||||
id5((version: 80.0.361.50)) --> id9((cve_4))
|
||||
id5((version: 80.0.361.50)) --> id10((target_sw: windows))
|
||||
id10((target_sw: windows)) --> id11((cve_5))
|
||||
```
|
||||
|
||||
So having version `80.0.361.50` of `Edge` installed on MacOS should only return `cve_4` but having
|
||||
the same program in Windows should return both `cve_4` and `cve_5`.
|
||||
|
||||
So basically our vulnerability detection problem can be broken down into two sub-problems:
|
||||
1. Binding the software `vendor` and `name` attributes to known CPE `vendor` and `product` attributes (a.k.a the
|
||||
binding problem).
|
||||
2. Once we have the `vendor` and `product`, we will need to match that along with the version and other
|
||||
characteristics (like language, platform, etc) to one or more target CPEs contained in the NVD
|
||||
dataset (a.k.a the matching problem).
|
||||
|
||||
## Binding the vendor portion
|
||||
|
||||
For binding the `vendor`, we can use the `bundle_identifier` - using
|
||||
[this](https://developer.apple.com/documentation/uikit/uidevice/1620059-identifierforvendor) as a
|
||||
guideline - we can extract a 'pseudo vendor id' and filter out any top level domain names (since
|
||||
the `bundle_identifier` is assumed to be in reverse-DNS format) and finally, transform the resulting
|
||||
value if necessary.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
bundle_identifier --> vendor_id
|
||||
vendor_id --> remove_top_lv_domains
|
||||
remove_top_lv_domains --> map_values
|
||||
```
|
||||
Using the data [in
|
||||
here](https://docs.google.com/spreadsheets/d/1D6Ub8_6YhLpVkmxLwTdGP8VWTH7rMS6-ZoBmJcrDDLE/edit?usp=sharing)
|
||||
the following vendor translations where required (this list is not exhaustive):
|
||||
|
||||
| bundle_identifier | extracted vendor | mapped vendor |
|
||||
|---|---|---|
|
||||
| com.postmanlabs.mac | postmanlabs | getpostman |
|
||||
| com.tinyspeck.slackmacgap | tinyspeck | slack |
|
||||
| com.getdropbox.dropbox | getdropbox | dropbox |
|
||||
| ru.keepcoder.Telegram | keepcoder | telegram |
|
||||
| org.virtualbox.app.VirtualBox | virtualbox | oracle |
|
||||
| org.virtualbox.app.VirtualBox | Cisco-Systems | cisco |
|
||||
| net.kovidgoyal.calibre | kovidgoyal | calibre-ebook |
|
||||
|
||||
We will need to host and maintain some kind of metadata like this somewhere.
|
||||
|
||||
## Binding the product portion
|
||||
|
||||
For binding the `product`, we can use both the `bundle_executable` and the `bundle_name`
|
||||
(sometimes we get matches with the `bundle_executable` sometimes we get matches with the
|
||||
`bundle_name`) - the data processing pipeline would look something like this:
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
bundle_executable --> map_values
|
||||
map_values --> to_lower
|
||||
to_lower --> replace_spaces
|
||||
```
|
||||
Again, like with the vendor portion, some translation was required. When testing this approach the
|
||||
following translation were used:
|
||||
|
||||
| vendor | bundle name/ executable | translation |
|
||||
|---|---|---|
|
||||
| oracle | VirtualBox| vm_virtualbox|
|
||||
| agilebits | 1Password 7| 1password|
|
||||
| zoom | zoom.us | zoom |
|
||||
| microsoft | Microsoft AutoUpdate | autoupdate |
|
||||
| microsoft | Microsoft Edge | edge |
|
||||
| microsoft | Code | visual_studio_code |
|
||||
| osquery | oqueryd | osquery |
|
||||
|
||||
## Reference
|
||||
To test this approach I used
|
||||
[this](https://docs.google.com/spreadsheets/d/1D6Ub8_6YhLpVkmxLwTdGP8VWTH7rMS6-ZoBmJcrDDLE/edit?usp=sharing)
|
||||
data as input (the apps sheet). Both the not_found and found sheets contain the apps that were not
|
||||
found and found in the NVD dataset respectively. I checked that all entries in the `not_found` sheet
|
||||
did have entries in the NVD dataset.
|
||||
|
||||
For extracting the vendor and product portions from the NVD dataset I used the [following
|
||||
script](https://gist.github.com/juan-fdz-hawa/52a9a54646a1cdc26359104d4f1a57e3).
|
||||
|
||||
To determine matches/mismatches I used [following script](https://gist.github.com/juan-fdz-hawa/a3eb1cf33f149f7473a37469ecb9feda)
|
||||
Loading…
Reference in a new issue