Diviner: Replace Whitelist and Blacklist with Allowlist and Denylist

+9 -9

src/docs/flavor/things_you_should_do_now.diviner

··· 79 79 does the sanitizing for you. 80 80 81 81 82 - = Never Design a Blacklist-Based Security System = 82 + = Never Design a Denylist-Based Security System = 83 83 84 84 When you have an alternative, don't design security systems which are default 85 - permit, blacklist-based, or otherwise attempt to enumerate badness. When 86 - Facebook launched Platform, it launched with a blacklist-based CSS filter, which 85 + permit, denylist-based, or otherwise attempt to enumerate badness. When 86 + Facebook launched Platform, it launched with a denylist-based CSS filter, which 87 87 basically tried to enumerate all the "bad" parts of CSS and filter them out. 88 88 This was a poor design choice and lead to basically infinite security holes for 89 89 all time. 90 90 91 91 It is very difficult to enumerate badness in a complex system and badness is 92 - often a moving target. Instead of trying to do this, design whitelist-based 92 + often a moving target. Instead of trying to do this, design allowlist-based 93 93 security systems where you list allowed things and reject anything you don't 94 94 understand. Assume things are bad until you verify that they're OK. 95 95 96 - It's tempting to design blacklist-based systems because they're easier to write 96 + It's tempting to design denylist-based systems because they're easier to write 97 97 and accept more inputs. In the case of the CSS filter, the product goal was for 98 98 users to just be able to use CSS normally and feel like this system was no 99 - different from systems they were familiar with. A whitelist-based system would 99 + different from systems they were familiar with. An allowlist-based system would 100 100 reject some valid, safe inputs and create product friction. 101 101 102 - But this is a much better world than the alternative, where the blacklist-based 102 + But this is a much better world than the alternative, where the denylist-based 103 103 system fails to reject some dangerous inputs and creates //security holes//. It 104 104 //also// creates product friction because when you fix those holes you break 105 105 existing uses, and that backward-compatibility friction makes it very difficult 106 - to move the system from a blacklist to a whitelist. So you're basically in 106 + to move the system from a denylist to an allowlist. So you're basically in 107 107 trouble no matter what you do, and have a bunch of security holes you need to 108 108 unbreak immediately, so you won't even have time to feel sorry for yourself. 109 109 110 - Designing blacklist-based security is one of the worst now-vs-future tradeoffs 110 + Designing denylist-based security is one of the worst now-vs-future tradeoffs 111 111 you can make. See also "The Six Dumbest Ideas in Computer Security": 112 112 113 113 http://www.ranum.com/security/computer_security/

+5 -5

src/docs/user/cluster/cluster.diviner

··· 62 62 to be part of the cluster. Hosts in this list are allowed to bend (or even 63 63 break) some of the security and policy rules when they make requests to other 64 64 hosts in the cluster, so this list should be as small as possible. See "Cluster 65 - Whitelist Security" below for discussion. 65 + Allowlist Security" below for discussion. 66 66 67 67 If you are deploying hardware in EC2, a reasonable approach is to launch a 68 - dedicated Phorge VPC, whitelist the whole VPC as a Phorge cluster, 68 + dedicated Phorge VPC, put the whole VPC into the allowlist as a Phorge cluster, 69 69 and then deploy only Phorge services into that VPC. 70 70 71 71 If you have additional auxiliary hosts which run builds and tests via Drydock, ··· 77 77 configuring `cluster.addresses`. 78 78 79 79 80 - Cluster Whitelist Security 80 + Cluster Allowlist Security 81 81 ======================== 82 82 83 83 When you configure `cluster.addresses`, you should keep the list of trusted ··· 91 91 value and spoof traffic from arbitrary remotes. 92 92 93 93 These headers are trusted when they are received from a host on the cluster 94 - address whitelist. This allows requests from cluster loadbalancers to be 94 + address allowlist. This allows requests from cluster loadbalancers to be 95 95 interpreted correctly by default without requiring additional custom code or 96 96 configuration. 97 97 ··· 117 117 These mechanisms are still authenticated (and use asymmetric keys, like SSH 118 118 does), so access to a host in the cluster address block does not mean that an 119 119 attacker can immediately compromise the cluster. However, an over-broad cluster 120 - address whitelist may give an attacker who gains some access additional tools 120 + address allowlist may give an attacker who gains some access additional tools 121 121 to escalate access. 122 122 123 123 Note that if an attacker gains access to an actual cluster host, these extra

+1 -1

src/docs/user/configuration/configuring_inbound_email.diviner

··· 198 198 ``` 199 199 200 200 See also the Postmark section in @{article:Configuring Outbound Email} for 201 - discussion of the remote address whitelist used to verify that requests this 201 + discussion of the remote address allowlist used to verify that requests this 202 202 endpoint receives are authentic requests originating from Postmark. 203 203 204 204

Configure Feed

Configure Feed