diff options
| -rw-r--r-- | docs/security.md | 23 | ||||
| -rw-r--r-- | windows/winfw/README.md | 8 |
2 files changed, 26 insertions, 5 deletions
diff --git a/docs/security.md b/docs/security.md index 786cf99d8b..40fb188465 100644 --- a/docs/security.md +++ b/docs/security.md @@ -102,7 +102,7 @@ This is the default state that the `mullvad-daemon` starts in when the device bo [connecting] state immediately. The disconnected state behaves very differently depending on the value of the -"block when disconnected" setting. If this setting is enabled, the disconnected state behaves +"always require VPN" setting. If this setting is enabled, the disconnected state behaves like and has the same security properties as, the [error] state. If the setting is disabled (the default), then it is the only state where the app does not enforce any firewall rules. It then behaves the same as if the `mullvad-daemon` was not even running. It lets @@ -217,10 +217,10 @@ then they can't leave at all. Essentially, one can say that the app's "kill switch" is the fact that the [connecting], [disconnecting] and [error] states prevent leaks via firewall rules. -### Block when disconnected +### Always require VPN -The "block when disconnected" setting in the app is regularly misunderstood as the kill switch. -This is not the case. The "block when disconnected" setting only changes whether or not the +The "always require VPN" setting in the app is regularly misunderstood as the kill switch. +This is not the case. The "always require VPN" setting only changes whether or not the [disconnected] state should allow traffic to flow freely or to block it. The disconnected state is not active during intermittent network issues or server changes, when a kill switch would normally be operating. @@ -259,6 +259,21 @@ via unix domain sockets (UDS) on Linux and macOS and via named pipes on Windows. This management interface can be reached by any process running on the device. Locally running malicious programs are outside of the app's threat model. +The service transitions to the [disconnected] state before exiting (i.e., normally when the OS is +being shut down). In general, the last firewall policy is maintained when the service exits, and +lost upon a reboot (except on Windows, see below). In other words, if the "Always require VPN" +option is enabled, the blocking policy will be left intact when the daemon service stops. +Otherwise, the system firewall will be reset to its original state. + +### Windows + +On Windows, persistent firewall filters may be added when the service exits, in case the service +decides to continue to enforce a blocking policy. These filters block any traffic occurring before +the service has started back up again during boot, including before the BFE service has started. + +As with "Always require VPN", enabling "Auto-connect" in the service will cause it to +enforce the blocking policy before being stopped. + ## Desktop Electron GUI The graphical frontend for the app on desktop is an Electron app. This app only ever loads diff --git a/windows/winfw/README.md b/windows/winfw/README.md index 6c4f456bed..59e21afebb 100644 --- a/windows/winfw/README.md +++ b/windows/winfw/README.md @@ -4,11 +4,13 @@ # Organization of sublayers -`winfw` uses a design that involves two different types of sublayers: +In its initialized state, `winfw` uses a design that involves two different types of sublayers: - The baseline sublayer - Other sublayers +When `winfw` is deinitialized, it may create a persistent sublayer to continue applying some policies. Other sublayers and their filters are removed at this time. + ## Baseline sublayer The baseline sublayer is weighted the highest to ensure it sees all traffic first. It contains a large number of permit-filters, with a different subset of them being activated by different policies. The permit-filters are all weighted the same and have the highest possible weight. It doesn't matter which filter sees the traffic first. If traffic is matched by a permit-filter, it's "lifted" out of the sublayer and processing is resumed with the next sublayer. @@ -25,6 +27,10 @@ Same as the baseline sublayer, these sublayers use a design with highly weighted As an example, we have a sublayer that's dedicated to filtering DNS. Traffic that's not related to DNS will still be sent through it, but all the filters we install must deal only with DNS. This way we can install permit-filters with specific conditions that effectively whitelist the traffic we deem safe. To round it off there's a lower-weighted blocking filter that blocks all DNS. +## Persistent sublayer + +The persistent sublayer is only active when `winfw` is deinitialized and instructed to continue enforcing a blocking policy. It has the highest weight possible and only contains blocking filters that match all traffic. These filters ensure that all traffic will be blocked until `winfw` is reinitialized, including at boot-time before BFE is running. Unlike the other sublayers, this sublayer persists even if BFE is restarted (e.g., by rebooting). + ## Advantages of current design - Predictable sublayer weights. |