3 ms·

So? Local programs also have access to the filesystem, which includes the synced data, config files and procfs. What exactly is your threat model?

by tagrun 8y ago

dddddaviddddd 8y ago
On a multiuser system it could be an issue. Other users with access to make HTTP requests could add a malicious endpoint. e.g. on a shared server of some sort. I could see this in academia or some business settings. Threat model would be an attacker with a foothold on one machine gaining access to the documents of another user.
- tagrun 8y ago
  Could be, theoretically, but this would probably be inconveniencing all syncthing users for a negligible fraction of the userbase. On a shared computer where you perceive your peers as a threat, adding a password to syncthing web UI is probably a minor entry in a long list of things you have to do to secure your processes and data, and to ensure the kernel and programs you're running are trustable (in practice, you can't verify that with 100% confidence; they can be backdoored, out-of-date with known security flaws, etc etc). Ensuring security in such a malicious (where your co-workers/peers are apparently a nasty bunch) shared environment is so hard that to begin with that I personally wouldn't put any sensitive data there at all.
puetzk 8y ago
It defeats user-privilege separate on localhost - I (or an unprivileged daemon) can't get at parts of the filesystem belonging to their user instead of mine, but I can get at TCP ports on localhost that belong to other user's syncthing daemons, and reconfigure their syncthing to send all their data to me.
nicolaslem 8y ago
You assume a machine with a single all powerful user. These days computers don't really work this way, for our own good. A huge amount of effort is put into keeping programs as isolated as possible (unix permissions, chroots, cgroups...). Most systemd units include isolation features enabled by default. Having an API that can reconfigure syncing being available without authentication for anything running on the machine feels backwards to me. More so for a project that focuses on security. If anyone from the project reads this, may I recommend either encouraging users to set a password or mentioning the implications on the page about Security Principles[0]? [0] https://docs.syncthing.net/users/security.html https://docs.syncthing.net/users/security.html
- tagrun 8y ago
  The real reason behind isolated systemd services is to confine the damage if a world-accessible daemon gets breached. If your threat model is you can't trust the programs running on your computer, then maybe you should switch to a different OS, for example Debian, and stick to the package manager.

So? Local programs also have access to the filesystem, which includes the synced data, config files and procfs. What exactly is your threat model?

by tagrun 8y ago

So? Local programs also have access to the filesystem, which includes the synced data, config files and procfs. What exactly is your threat model?

dddddaviddddd 8y ago

On a multiuser system it could be an issue. Other users with access to make HTTP requests could add a malicious endpoint. e.g. on a shared server of some sort. I could see this in academia or some business settings. Threat model would be an attacker with a foothold on one machine gaining access to the documents of another user.

tagrun 8y ago
Could be, theoretically, but this would probably be inconveniencing all syncthing users for a negligible fraction of the userbase. On a shared computer where you perceive your peers as a threat, adding a password to syncthing web UI is probably a minor entry in a long list of things you have to do to secure your processes and data, and to ensure the kernel and programs you're running are trustable (in practice, you can't verify that with 100% confidence; they can be backdoored, out-of-date with known security flaws, etc etc). Ensuring security in such a malicious (where your co-workers/peers are apparently a nasty bunch) shared environment is so hard that to begin with that I personally wouldn't put any sensitive data there at all.

puetzk 8y ago

It defeats user-privilege separate on localhost - I (or an unprivileged daemon) can't get at parts of the filesystem belonging to their user instead of mine, but I can get at TCP ports on localhost that belong to other user's syncthing daemons, and reconfigure their syncthing to send all their data to me.

nicolaslem 8y ago

You assume a machine with a single all powerful user. These days computers don't really work this way, for our own good. A huge amount of effort is put into keeping programs as isolated as possible (unix permissions, chroots, cgroups...). Most systemd units include isolation features enabled by default. Having an API that can reconfigure syncing being available without authentication for anything running on the machine feels backwards to me. More so for a project that focuses on security. If anyone from the project reads this, may I recommend either encouraging users to set a password or mentioning the implications on the page about Security Principles[0]? [0] https://docs.syncthing.net/users/security.html https://docs.syncthing.net/users/security.html

tagrun 8y ago
The real reason behind isolated systemd services is to confine the damage if a world-accessible daemon gets breached. If your threat model is you can't trust the programs running on your computer, then maybe you should switch to a different OS, for example Debian, and stick to the package manager.