077a7a0378
fix(systemd): Add back chown allowed syscalls IFF the user enables the `syncOwnership` feature AND sets `AmbientCapabilities=CAP_CHOWN CAP_FOWNER` as the docs in https://docs.syncthing.net/users/autostart.html#permissions state, THEN syncthing needs to use the `chown` syscall. PR #10421 added a comprehensive sandbox that breaks `syncOwnership`. In PR #10602 we fixed one part, which is expanding the default `CapabilityBoundingSet` (see the PR for details). But there's a very subtle bug that this PR fixes. PR #10421 sets the following properties: SystemCallFilter=@system-service SystemCallFilter=~@privileged io_uring_enter io_uring_register io_uring_setup (Systemd merges `SystemCallFilter` values; we had to set the property twice because to negate syscalls, the whole list has to start with `~`.) The goal was to allow all syscalls in the `@system-service` set, BUT disallow any `@privileged` syscalls and the `io_uring*` syscalls. But the sets are not disjoint; `chown` is in both `@system-service` and in `@privileged`, so it is removed from the allow list by the second property value. This property is also parsed in a very peculiar way. From systemd docs: > If you specify both types of this option (i.e. allow-listing and > deny-listing), the first encountered will take precedence and will > dictate the default action (termination or approval of a system call). > Then the next occurrences of this option will add or delete the listed > system calls from the set of the filtered system calls, depending of its > type and the default action. (For example, if you have started with an > allow list rule for read() and write(), and right after it add a deny > list rule for write(), then write() will be removed from the set.) Not only does the order of `SystemCallFilter` properties matter (later ones can undo effects of prior ones), but the _type_ of the _first_ property sets the overall behavior of the syscall filter: if the first `SystemCallFilter` value is an allow list, then all syscalls that are not specified are disallowed by default (and reverse if the first value is a deny list). Of course, this is completely different from how other allow/deny lists are implemented in systemd; for example, `IPAddress[Allow|Deny]` properties don't work like this at all. >:( Since this complexity has bit us once, we're removing the additional deny list of syscalls and sticking with just `SystemCallFilter=@system-service`. This leaves some privileged syscalls in the allow list. Other options would require entering the "deny list by default" mode and deny lists are less secure than allow lists in general because they have to be maintained (the kernel always adds new syscalls). The rest of the sandbox (capability bounds) should be sufficient. Fixes #10603 Signed-off-by: Val Markovic <val@markovic.io>
Goals
Syncthing is a continuous file synchronization program. It synchronizes files between two or more computers. We strive to fulfill the goals below. The goals are listed in order of importance, the most important ones first. This is the summary version of the goal list - for more commentary, see the full Goals document.
Syncthing should be:
-
Safe From Data Loss
Protecting the user's data is paramount. We take every reasonable precaution to avoid corrupting the user's files.
-
Secure Against Attackers
Again, protecting the user's data is paramount. Regardless of our other goals, we must never allow the user's data to be susceptible to eavesdropping or modification by unauthorized parties.
-
Easy to Use
Syncthing should be approachable, understandable, and inclusive.
-
Automatic
User interaction should be required only when absolutely necessary.
-
Universally Available
Syncthing should run on every common computer. We are mindful that the latest technology is not always available to every individual.
-
For Individuals
Syncthing is primarily about empowering the individual user with safe, secure, and easy to use file synchronization.
-
Everything Else
There are many things we care about that don't make it on to the list. It is fine to optimize for these values, as long as they are not in conflict with the stated goals above.
Getting Started
Take a look at the getting started guide.
There are a few examples for keeping Syncthing running in the background on your system in the etc directory. There are also several GUI implementations for Windows, Mac, and Linux.
Docker
To run Syncthing in Docker, see the Docker README.
Getting in Touch
The first and best point of contact is the Forum. If you've found something that is clearly a bug, feel free to report it in the GitHub issue tracker.
If you believe that you’ve found a Syncthing-related security vulnerability, please report it by emailing security@syncthing.net. Do not report it in the Forum or issue tracker.
Building
Building Syncthing from source is easy. After extracting the source bundle from
a release or checking out git, you just need to run go run build.go and the
binaries are created in ./bin. There's a guide with more details on the
build process.
Signed Releases
Release binaries are GPG signed with the key available from https://syncthing.net/security/. There is also a built-in automatic upgrade mechanism (disabled in some distribution channels) which uses a compiled in ECDSA signature. macOS and Windows binaries are also code-signed.
Documentation
Please see the Syncthing documentation site [source].
All code is licensed under the MPLv2 License.