Closed sudoyum999 closed 7 years ago
My current understanding is that Streisand has an increased attack surface because it installs so much software. Best practice is to install and enable only the components you would be using to minimize and simplify the aspects that need to be monitored and secured. To quote @trailofbits in their blog post here about why they don't recommend Streisand:
That’s a hefty footprint and it’s too complicated for any reasonable person to secure. If you set up an individual server just for yourself, you’d never know if or when an attacker compromised it.
I'd love to see choice in what services are installed (#23); it would make me feel more confident in the security of the server and my ability to personally audit it. Currently I feel it is too bloated.
Anyone care to comment on this?
I think much of the criticism against Streisand is valid, but overlooks the fact that the primary use case is censorship resistance. This is not the same use case that Qubes or Algo have.
We intend to support modular deployments that will not have the very large # of services installed out-of-box if the user is more interested in a minimally privileged VPN endpoint for personal use than a censorship resistance tool. The primary blocker is maintainer time. In the meantime since this is a duplicate of #23 I'm going to close it. Thanks!
This is why I stopped using Streisand. Some of the first principles of security:
Reduce code. Ensure a minimal and trusted compute base. Minimise what you depend on to the bare essentials. Carefully manage external sources (build tools included). Keep it auditable.
Reduce attack surface. Don't expose unnecessary services and entry points. Don't provide extra code paths for attackers to exercise/exploit. Don't provide unnecessary information gathering opportunities.
Separate and reduce privileges. Including to isolate and sandbox software/components, e.g. limit syscalls and file access. Compartmentalised (inevitable) failures.
You can't have privacy or anonymity without security.
Streisand is an outstanding project. Great concept and we're very fortunate that it's been shared with the community. I hope someone in the community has time to work on Issue #23 to make it more widely applicable. It has many great features, but until some of the more fundamental security issues are addressed, its uptake will be limited. Developing and documenting the threat model, via risk management process such as http://dx.doi.org/10.6028/NIST.SP.800-30r1, would be a great step too.
@dlmetcalf I agree with this. I'd suggest you copy this to #23 as well now that this is closed for future reference. (Sorry, I know this issue is closed, just suggesting this be added to #23.)
There is a debate going on at present on the Qubes Forums [ https://groups.google.com/forum/#!topic/qubes-users/h6GQfL-J_PY ] about the Pros and Cons of using Streisand. The main thrust of the arguments seem to be don't use Streisand as it has numerous attack surfaces. Anyone care to comment on this?