aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2017-12-05fusefrontend_reverse: secure OpenDir against symlink racesJakob Unterwurzacher
...by using the new OpenNofollow helper. The benchmark shows a small but acceptable performance loss: $ ./benchmark-reverse.bash LS: 2.182 CAT: 18.221 Tracking ticket: https://github.com/rfjakob/gocryptfs/issues/165
2017-12-05syscallcompat: OpenNofollow: fix relPath="" caseJakob Unterwurzacher
Sometimes want to open baseDir itself. This case was broken, fix it.
2017-12-05Documentation: Add reverse mode benchmark resultsJakob Unterwurzacher
2017-12-03syscallcompat: convert Getdents to fd input, add emulationJakob Unterwurzacher
Now that we have Fstatat we can use it in Getdents to get rid of the path name. Also, add an emulated version of getdents for MacOS. This allows to drop the !HaveGetdents special cases from fusefrontend. Modify the getdents test to test both native getdents and the emulated version.
2017-12-03syscallcompat: add Fstatat + emulation + testJakob Unterwurzacher
Fstatat has recently been added to x/sys/unix. Make it available for use in gocryptfs.
2017-12-02fusefrontend_reverse: secure StatFs agains symlink racesJakob Unterwurzacher
...by ignoring the path that was passed in. https://github.com/rfjakob/gocryptfs/issues/165
2017-12-02fusefrontend_reverse: secure Open against symlink racesJakob Unterwurzacher
...using the new syscallcompat.OpenNofollow helper. This change secures Open() against symlink race attacks as described in https://github.com/rfjakob/gocryptfs/issues/165
2017-12-02syscallcompat: add OpenNofollow helperJakob Unterwurzacher
OpenNofollow = symlink-race-safe Open Prepares fixing https://github.com/rfjakob/gocryptfs/issues/165
2017-12-02syscallcompat: move test setup into its own fileJakob Unterwurzacher
The infrastructure will also be used by the upcoming OpenNofollow tests.
2017-12-02syscallcompat: use Unlinkat and Symlinkat from x/sys/unixJakob Unterwurzacher
I'm unsure why I did not notice this earlier, but the syscall wrappers provided by x/sys/unix seem to do just fine. Drop our own version.
2017-12-01syscallcompat: Improve the Openat and Mknodat syscall emulationSebastian Lackner
This avoids the conversion to an absolute path.
2017-12-01syscallcompat: Fix syscall emulation for absolute pathsSebastian Lackner
For absolute paths, the file descriptor should be ignored. In such a case there is also no need to hold the lock or change the working directory.
2017-12-01fusefrontend: Improve documentation of mkdirWithIv and WriteDirIVSebastian Lackner
As requested in https://github.com/rfjakob/gocryptfs/pull/179
2017-11-30syscallcompat: check that we get NOFOLLOW wherever possibleJakob Unterwurzacher
...and fix the instances where the AT_SYMLINK_NOFOLLOW / O_NOFOLLOW / O_EXCL flag was missing.
2017-11-30syscallcompat: add tests for emulated syscallsJakob Unterwurzacher
Also fix the bug in emulateFchmodat that was found by the tests.
2017-11-30syscallcompat: build emulated syscalls under linux, tooJakob Unterwurzacher
This will allow to test them under linux as well.
2017-11-29fusefrontend: allow_other: close race between mkdir and chownSebastian Lackner
Fixes the same problem as described in 72b975867a3b9bdf53fc2da62e2ba4a328d7e4ab, except for directories instead of device nodes.
2017-11-29fusefrontend: Use Fchownat to implement ChownSebastian Lackner
2017-11-29fusefrontend: Use Fchmodat to implement ChmodSebastian Lackner
2017-11-29syscallcompat: Introduce unlinkat syscall with flags argumentSebastian Lackner
2017-11-28fusefrontend: Use openBackingPath in Unlink and simplify codeSebastian Lackner
2017-11-28fusefrontend: Handle PlaintextNames mode in UnlinkSebastian Lackner
In PlaintextNames mode the "gocryptfs.longname." prefix does not have any special meaning. We should not attempt to delete any .name files. Partially fixes https://github.com/rfjakob/gocryptfs/issues/174
2017-11-28fusefrontend: Introduce a openBackingPath helper and use it to simplify ↵Sebastian Lackner
Mknod and Symlink
2017-11-28fusefrontend: allow_other: close race between symlink and chownSebastian Lackner
Fixes the same problem as described in 72b975867a3b9bdf53fc2da62e2ba4a328d7e4ab, except for symlinks instead of device nodes.
2017-11-28fusefrontend: Use the Symlinkat syscall for longname handlingSebastian Lackner
2017-11-28fusefrontend: Set owner after symlink creation in PlaintextNames modeSebastian Lackner
This is already done in regular mode, but was missing when PlaintextNames mode is enabled. As a result, symlinks created by non-root users were still owned by root afterwards. Fixes https://github.com/rfjakob/gocryptfs/issues/176
2017-11-28fusefrontend: Handle PlaintextNames mode in MknodSebastian Lackner
In PlaintextNames mode the "gocryptfs.longname." prefix does not have any special meaning. We should not attempt to read the directory IV or to create special .name files. Partially fixes https://github.com/rfjakob/gocryptfs/issues/174
2017-11-28syscallcompat: Fix Fchownat syscall wrapper on darwinSebastian Lackner
* Acquire the lock before reading the current directory * Fix a file descriptor leak
2017-11-27fusefronted: allow_other: close race between mknod and chownJakob Unterwurzacher
If the user manages to replace the directory with a symlink at just the right time, we could be tricked into chown'ing the wrong file. This change fixes the race by using fchownat, which unfortunately is not available on darwin, hence a compat wrapper is added. Scenario, as described by @slackner at https://github.com/rfjakob/gocryptfs/issues/177 : 1. Create a forward mount point with `plaintextnames` enabled 2. Mount as root user with `allow_other` 3. For testing purposes create a file `/tmp/file_owned_by_root` which is owned by the root user 4. As a regular user run inside of the GoCryptFS mount: ``` mkdir tempdir mknod tempdir/file_owned_by_root p & mv tempdir tempdir2 ln -s /tmp tempdir ``` When the steps are done fast enough and in the right order (run in a loop!), the device file will be created in `tempdir`, but the `lchown` will be executed by following the symlink. As a result, the ownership of the file located at `/tmp/file_owned_by_root` will be changed.
2017-11-26reverse: reject too-long symlink target reads with ENAMETOOLONGJakob Unterwurzacher
If the symlink target gets too long due to base64 encoding, we should return ENAMETOOLONG instead of having the kernel reject the data and returning an I/O error to the user. Fixes https://github.com/rfjakob/gocryptfs/issues/167
2017-11-25fusefrontend_reverse: Do not mix up cache information for different directoriesSebastian Lackner
Fixes https://github.com/rfjakob/gocryptfs/issues/168 Steps to reproduce the problem: * Create a regular reverse mount point * Create files with the same very long name in multiple directories - so far everything works as expected, and it will appear with a different name each time, for example, gocryptfs.longname.A in directory A and gocryptfs.longname.B in directory B * Try to access a path with A/gocryptfs.longname.B or B/gocryptfs.longname.A - this should fail, but it actually works. The problem is that the longname cache only uses the path as key and not the dir or divIV. Assume an attacker can directly interact with a reverse mount and knows the relation longname path -> unencoded path in one directory, it allows to test if the same unencoded filename appears in any other directory.
2017-11-25fusefrontend: Skip gocryptfs.diriv handling when directory was deleted ↵Sebastian Lackner
successfully Fixes https://github.com/rfjakob/gocryptfs/issues/171 Steps to reproduce: * Create a regular forward mount point * Create a new directory in the mount point * Manually delete the gocryptfs.diriv file from the corresponding ciphertext directory * Attempt to delete the directory with 'rmdir <dirname>' Although the code explicitly checks for empty directories, it will still attempt to move the non-existent gocryptfs.diriv file and fails with: rmdir: failed to remove '<dirname>': No such file or directory
2017-11-25fusefrontend: Fix longname handling for renames with existing targetSebastian Lackner
Fixes https://github.com/rfjakob/gocryptfs/issues/170 Steps to reproduce the problem: * Create a regular forward mount point * Create a file with a shortname and one with a long filename * Try to run 'mv <shortname> <longname>' This should actually work and replace the existing file, but instead it fails with: mv: cannot move '<shortname>' to '<longname>': File exists The problem is the creation of the .name file. If the target already exists we can safely ignore the EEXIST error and just keep the existing .name file.
2017-11-23tests: Add test for access to encrypted version of '.' and '..'Sebastian Lackner
To show that https://github.com/rfjakob/gocryptfs/issues/163 has been fixed.
2017-11-22fusefrontend_reverse: Add a missing Close() callSebastian Lackner
2017-11-22nametransform: Return error if decrypted name is '.' or '..'Sebastian Lackner
2017-11-21main: Add '-devrandom' commandline optionSebastian Lackner
Allows to use /dev/random for generating the master key instead of the default Go implementation. When the kernel random generator has been properly initialized both are considered equally secure, however: * Versions of Go prior to 1.9 just fall back to /dev/urandom if the getrandom() syscall would be blocking (Go Bug #19274) * Kernel versions prior to 3.17 do not support getrandom(), and there is no check if the random generator has been properly initialized before reading from /dev/urandom This is especially useful for embedded hardware with low-entroy. Please note that generation of the master key might block indefinitely if the kernel cannot harvest enough entropy.
2017-11-15main: print clear error message if CIPHERDIR is missingJakob Unterwurzacher
Getting just the help text in response to gocryptfs -info -config external.config is confusing: https://github.com/rfjakob/gocryptfs/issues/157
2017-11-12main: add "-sharedstorage" flagJakob Unterwurzacher
At the moment, it does two things: 1. Disable stat() caching so changes to the backing storage show up immediately. 2. Disable hard link tracking, as the inode numbers on the backing storage are not stable when files are deleted and re-created behind our back. This would otherwise produce strange "file does not exist" and other errors. Mitigates https://github.com/rfjakob/gocryptfs/issues/156
2017-11-12test.bash: don't run "go tool vet" if vendor dir existsJakob Unterwurzacher
...this fails in a thousand ways: [...] vendor/golang.org/x/crypto/sha3/keccakf_amd64.s:324: [amd64] keccakF1600: unknown variable state; offset 0 is a+0(FP) vendor/golang.org/x/crypto/ssh/certs.go:172: declaration of "err" shadows declaration at vendor/golang.org/x/crypto/ssh/certs.go:166 vendor/golang.org/x/crypto/ssh/certs.go:187: declaration of "rest" shadows declaration at vendor/golang.org/x/crypto/ssh/certs.go:161 vendor/golang.org/x/crypto/ssh/certs.go:187: declaration of "ok" shadows declaration at vendor/golang.org/x/crypto/ssh/certs.go:161 vendor/golang.org/x/crypto/ssh/client_auth.go:226: declaration of "err" shadows declaration at vendor/golang.org/x/crypto/ssh/client_auth.go:193 vendor/golang.org/x/crypto/ssh/client_auth.go:394: declaration of "err" shadows declaration at vendor/golang.org/x/crypto/ssh/client_auth.go:380 vendor/golang.org/x/crypto/ssh/client_auth.go:405: declaration of "err" shadows declaration at vendor/golang.org/x/crypto/ssh/client_auth.go:380 vendor/golang.org/x/crypto/ssh/handshake.go:566: declaration of "err" shadows declaration at vendor/golang.org/x/crypto/ssh/handshake.go:547 vendor/golang.org/x/crypto/ssh/handshake.go:592: declaration of "err" shadows declaration at vendor/golang.org/x/crypto/ssh/handshake.go:547 vendor/golang.org/x/crypto/ssh/handshake.go:630: declaration of "err" shadows declaration at vendor/golang.org/x/crypto/ssh/handshake.go:620 [...]
2017-11-01package-source.bash: replace plus sign in file nameJakob Unterwurzacher
Plus signs are apparently not supported on github, and replaced by a dot.
2017-11-01package-source.bash: create VERSION filev1.4.2Jakob Unterwurzacher
...and delete if after packaging is done.
2017-11-01README: Update changelog for v1.4.2Jakob Unterwurzacher
2017-11-01dep: update dependenciesJakob Unterwurzacher
2017-11-01travis: update Go versionsJakob Unterwurzacher
...to latest point releases acc. to https://golang.org/dl/
2017-11-01Add source packaging scriptJakob Unterwurzacher
2017-11-01build.bash: support VERSION file and vendored go-fuseJakob Unterwurzacher
Prepares for the release of all-in-one source tarballs that include all non-stdlib dependencies.
2017-10-31main: disallow recursively encrypting ourselvesJakob Unterwurzacher
From https://github.com/rfjakob/gocryptfs/issues/150: mkdir a mkdir a/b gocryptsfs -init -reverse a/ gocryptfs -reverse a/ a/b Now directory a/b/ contains encrypted view of 'a' but it is possible to descend into encrypted version of b (e.g. a/b/43873uhj538765387/) which contains double encrypted 'a' and so on. Reported-by: https://github.com/tigmac
2017-10-22tests: don't read /proc, the number of entries changes too quicklyJakob Unterwurzacher
This could lead to test failures like this: --- FAIL: TestGetdents (0.02s) getdents_test.go:57: len(getdentsEntries)=362, len(readdirEntries)=360 FAIL
2017-10-22Revert "test.bash: use "go vet" instead of "go tool vet""Jakob Unterwurzacher
"go vet" on Go 1.8 and older does not support flags: $ go version go version go1.8.3 linux/amd64 $ ./test.bash gocryptfs v1.4.1-27-g8c1b363 without_openssl; go-fuse v20170619-21-gcf21bc2; 2017-10-22 go1.8.3 gocryptfs v1.4.1-27-g8c1b363; go-fuse v20170619-21-gcf21bc2; 2017-10-22 go1.8.3 flag provided but not defined: -all usage: vet [-n] [-x] [build flags] [packages] Vet runs the Go vet command on the packages named by the import paths. For more about vet, see 'go doc cmd/vet'. For more about specifying packages, see 'go help packages'. To run the vet tool with specific options, run 'go tool vet'. The -n flag prints commands that would be executed. The -x flag prints commands as they are executed. For more about build flags, see 'go help build'. See also: go fmt, go fix. This reverts commit a1170be979cb75da11e84f45f67d3f5468d97669.
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-05 05:35:13 +0000