Jump to: navigation, search

Comparison with Others/SubgraphOS

This writeup is meant to analyze upcoming Subgraph features from a neutral POV as much as possible:

  • A non-private clearnet mode for programs - contradicts the mission of a privacy OS.
  • A (optional) log collecion system that sends subgraph devs any grsec denied messages on a system. Anonymizing data collected from systems never worked - could leak all kinds of info about what software a user is running. Can be weaken the system if the code is vulnerable.
  • GUI popups when mprotect stops a program - Is a terrible UX decision because most users will have no

idea what these messages mean and they'll be alarmed by a massive amount of false positives.

  • Captive portal authenticator uses webkit which makes it a massive security hole. Webkit security patching is a disaster on Linux because the engine development/patching is fragmented. Only Gecko has a sane policy. Other options on the TAILS page were written in python and didn't use browser engines at all.
  • with lock screen the grsec sysctl for deny_usb is enforced. Sounds good in theory but it won't stop someone resourceful enough from connecting to the hardware memory bus and sniffing encryption keys.
  • Per-app sandbox outgoing connection control (restricting what IPs accessible by guest: Not really useful with a nation-state listening on the backbone. They never have to send exfiltrated data to a specific IP. Leaking it anywhere will get it picked up by their sensors which makes it a silent process.
    • SSL cert pinning as another feature of application sandboxes. Pointless since CA SSL system is subverted by nation-states.
  • The outgoing firewall is of questionable usefulness since an attacker with root can easily bypass that and if not, can exfiltrate via an allowed application instead.
  • Use the buggy and feature lacking tlsdate that is now defunct.

  • "Oz sandbox restricts app connections to .onion servers only. Useful for @coyproject, Ricochet. Maybe "TLS Guard" wrong name"

The feature description is unclear but if all onion addresses are allowed then an attacker can just setup a hidden service and connect to it.

But lets assume some situations where specific addresses can be whitelisted and see if that feature is useful.

(Note: Ricochet is used as an example. Its very securely coded in reality and confirmed so by an audit.)

Threat models:

1) (No address connection restrictions): The container/VM starts off in a clean state and is dedicated to running say Ricochet to connect to some contacts only. A contact is malicious and attacks the IM peer - is then able to extract information from the victim via itself (because it would be whitelisted).

Result: This would happen under the restricted outbound traffic access model anyway.

2) (With address restrictions): Ricochet is running in a shared VM with other programs running.

Result: No browsing would be possible in this VM. So no infection/exfiltration would happen but then that's the same as running a clean Ricochet VM with no restrictions and using it for that purpose only. Restrictions not useful here.

3) (No address restrictions) Apparmor/container/sandbox around Ricochet and TBB. TBB is exploited and can only read limited folders that do not include the IM program.

Result: Limited effect of compromise but not due to network restrictions.

4) (Address restrictions) Ricochet dedicated VM. Trusted contacts but no Onion client authorization enabled. Hypothetical bug in Ricochet. Malicious HSDir sniffs address and then scans and exploits Ricochet.

Result: I'm actually unsure. This may be a situation where limiting outbound can stop data pilfering. Because its an Onion service anyone can connect so inbound access is still possible. Which could establish bidirectional communication. What I saw when testing was: if a HS with client authentication connected to a non authorized client - bidirectional communication became possible even without authorization because the HS initiated contact. This is different though because outbound rather than inbound is restricted.

Thought some more about 4th scenario. It seems like a situation where a user is bending backwards to get exploited then try to do damage control. Authenticated HS is the answer and would make this unnecessary.

5) Kiosk access. well this only works if users are dumb. With physical access to the machine - this can easily be circumvented.