The workaround for Go versions before 1.10 was already removed by
commit 3022c1603d96 ("Ensure setting user privileges is reversible").
In preparation for introducing support for the new filesystem-level keyrings, move the existing user keyring management code from security/keyring.go and crypto/crypto.go into a new package, 'keyring'. This package provides functions AddEncryptionKey, RemoveEncryptionKey, and GetEncryptionKeyStatus which delegate to either the filesystem keyring (added by a later patch) or to the user keyring. This provides a common interface to both types of keyrings, to the extent possible.
When userKeyringIDLookup() looks up a user keyring, it links it into the process keyring to ensure that the process retains the "possessor privileges" over the user keyring, then caches the user keyring's ID. Unfortunately, this use of the process keyring randomly fails because Go creates threads before even init() and main() are run, and then can run code on them later. Since the kernel doesn't create the process keyring until userspace requests it and the process keyring is actually a per-thread property that's only inherited by new threads, different threads in a Go process may see different process keyrings. Fix this by removing the user keyring cache, switching from the process keyring to the thread keyring, and using LockOSThread() to pin the goroutine to an OS thread while needed to perform a keyring operation. Resolves https://github.com/google/fscrypt/issues/176
Refer to the target User as 'targetUser' rather than simply 'target'. This will help avoid confusion when we add support for the filesystem keyring, since then the Mount will also be a "target".
These were found by a combination of manual review and a custom script that checks for common errors. Also removed an outdated sentence from the comment for setupBefore().
* Remove spelling mistakes in the repository * Add travis script to check for typos. * Add command to Makefile to check for typos. * Fixes #71
This change makes sure that, when we set the ruid and euid in order to get the user keyring linked into the current process keyring, we will always be able to reverse these changes (using a suid of 0). This fixes an issue where "su <user>" would result in a system error when called by an unprivileged user. It also explains exactly how and why we are making these privilege changes.
This change makes sure after dropping then elevating privileges for a process, the euid, guid, and groups are all the same as they were originally. This significantly simplifies the privilege logic. This fixes CVE-2018-6558, which allowed an unprivleged user to gain membership in the root group (gid 0) due to the groups not being properly reset in the process.
After enabling pam_fscrypt for "session" and creating a directory protected with a login protector, I was no longer able to log in as that user. The problem is that the Go runtime is creating threads after pam_fscrypt drops privileges, but pam_fscrypt is not re-acquiring privileges on those threads because the Go wrappers for setreuid(), setregid(), and setgroups() in the "sys/unix" package are using the raw syscalls which operate on the calling thread only. This violates glibc's assumption that all threads have the same uids and gids, causing it to abort() the process when a later module in the PAM stack (pam_mail in my case) tries to drop privileges using the glibc functions. Fix it by dropping and regaining privileges using the glibc functions rather than the "sys/unix" functions. This also avoids any possibility that privileges could be changed in a thread other than the "main" one for pam_fscrypt, since the Go runtime does not guarantee which OS-level thread runs what. It would be nice to also exit all Go worker threads before returning from pam_fscrypt, but the Go runtime doesn't seem to support that.
The tests added in this change are trivial, but they make sure that every package has a non-zero number of tests. This is important for eventually increasing test coverage.