<feed xmlns='http://www.w3.org/2005/Atom'>
<title>fscrypt.git/cli-tests/t_v1_policy.out, branch v0.3.3</title>
<subtitle>Go tool for managing Linux filesystem encryption
</subtitle>
<link rel='alternate' type='text/html' href='https://git.hodgden.net/cgit.cgi/fscrypt.git/'/>
<entry>
<title>Strictly validate metadata file ownership by default</title>
<updated>2022-02-23T20:35:04+00:00</updated>
<author>
<name>Eric Biggers</name>
<email>ebiggers@google.com</email>
</author>
<published>2022-02-23T20:35:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.hodgden.net/cgit.cgi/fscrypt.git/commit/?id=74e870b7bd1585b4b509da47e0e75db66336e576'/>
<id>74e870b7bd1585b4b509da47e0e75db66336e576</id>
<content type='text'>
The metadata validation checks introduced by the previous commits are
good, but to reduce the attack surface it would be much better to avoid
reading and parsing files owned by other users in the first place.

There are some possible use cases for users sharing fscrypt metadata
files, but I think that for the vast majority of users it is unneeded
and just opens up attack surface.  Thus, make fscrypt (and pam_fscrypt)
not process policies or protectors owned by other users by default.
Specifically,

   * If fscrypt or pam_fscrypt is running as a non-root user, only
     policies and protectors owned by the user or by root can be used.

   * If fscrypt is running as root, any policy or protector can be used.
     (This is to match user expectations -- starting a sudo session
     should gain rights, not remove rights.)

   * If pam_fscrypt is running as root, only policies and protectors
     owned by root can be used.  Note that this only applies when the
     root user themselves has an fscrypt login protector, which is rare.

Add an option 'allow_cross_user_metadata' to /etc/fscrypt.conf which
allows restoring the old behavior for anyone who really needs it.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The metadata validation checks introduced by the previous commits are
good, but to reduce the attack surface it would be much better to avoid
reading and parsing files owned by other users in the first place.

There are some possible use cases for users sharing fscrypt metadata
files, but I think that for the vast majority of users it is unneeded
and just opens up attack surface.  Thus, make fscrypt (and pam_fscrypt)
not process policies or protectors owned by other users by default.
Specifically,

   * If fscrypt or pam_fscrypt is running as a non-root user, only
     policies and protectors owned by the user or by root can be used.

   * If fscrypt is running as root, any policy or protector can be used.
     (This is to match user expectations -- starting a sudo session
     should gain rights, not remove rights.)

   * If pam_fscrypt is running as root, only policies and protectors
     owned by root can be used.  Note that this only applies when the
     root user themselves has an fscrypt login protector, which is rare.

Add an option 'allow_cross_user_metadata' to /etc/fscrypt.conf which
allows restoring the old behavior for anyone who really needs it.
</pre>
</div>
</content>
</entry>
<entry>
<title>Make 'fscrypt setup' offer a choice of directory modes</title>
<updated>2022-02-23T20:35:04+00:00</updated>
<author>
<name>Eric Biggers</name>
<email>ebiggers@google.com</email>
</author>
<published>2022-02-23T20:35:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.hodgden.net/cgit.cgi/fscrypt.git/commit/?id=6e355131670ad014e45f879475ddf800f0080d41'/>
<id>6e355131670ad014e45f879475ddf800f0080d41</id>
<content type='text'>
World-writable directories are not appropriate for some systems, so
offer a choice of single-user-writable and world-writable modes, with
single-user-writable being the default.  Add a new documentation section
to help users decide which one to use.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
World-writable directories are not appropriate for some systems, so
offer a choice of single-user-writable and world-writable modes, with
single-user-writable being the default.  Add a new documentation section
to help users decide which one to use.
</pre>
</div>
</content>
</entry>
<entry>
<title>cmd/fscrypt: adjust status message for v1-encrypted dirs</title>
<updated>2020-06-13T17:06:15+00:00</updated>
<author>
<name>Eric Biggers</name>
<email>ebiggers@google.com</email>
</author>
<published>2020-06-13T17:06:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.hodgden.net/cgit.cgi/fscrypt.git/commit/?id=5c1f617c647eb0e9af5ce57758fa58f7e3f4db83'/>
<id>5c1f617c647eb0e9af5ce57758fa58f7e3f4db83</id>
<content type='text'>
When 'fscrypt status DIR' detects that a v1-encrypted directory is still
usable but its key seems to be absent, it shows the status as
"Unlocked: Partially (incompletely locked)".  But actually it can also
be the case that the directory is unlocked by another user.  Adjust the
status message accordingly.

This commit also fixes cli-tests/t_v1_policy.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When 'fscrypt status DIR' detects that a v1-encrypted directory is still
usable but its key seems to be absent, it shows the status as
"Unlocked: Partially (incompletely locked)".  But actually it can also
be the case that the directory is unlocked by another user.  Adjust the
status message accordingly.

This commit also fixes cli-tests/t_v1_policy.
</pre>
</div>
</content>
</entry>
<entry>
<title>cmd/fscrypt: improve errors</title>
<updated>2020-05-09T22:21:31+00:00</updated>
<author>
<name>Eric Biggers</name>
<email>ebiggers@google.com</email>
</author>
<published>2020-05-09T21:52:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.hodgden.net/cgit.cgi/fscrypt.git/commit/?id=181600d6327ed34a3f62eda0dd03a6d2ae49e5f9'/>
<id>181600d6327ed34a3f62eda0dd03a6d2ae49e5f9</id>
<content type='text'>
In checkEncryptable(), check whether the directory is already encrypted
before checking whether it's empty.

Also improve the error message for when a directory is nonempty.

Finally, translate keyring.ErrKeyAddedByOtherUsers and
keyring.ErrKeyFilesOpen into errors which include the directory.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In checkEncryptable(), check whether the directory is already encrypted
before checking whether it's empty.

Also improve the error message for when a directory is nonempty.

Finally, translate keyring.ErrKeyAddedByOtherUsers and
keyring.ErrKeyFilesOpen into errors which include the directory.
</pre>
</div>
</content>
</entry>
<entry>
<title>keyring: improve errors</title>
<updated>2020-05-09T22:21:31+00:00</updated>
<author>
<name>Eric Biggers</name>
<email>ebiggers@google.com</email>
</author>
<published>2020-05-09T21:52:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.hodgden.net/cgit.cgi/fscrypt.git/commit/?id=fb88d74f0335cdf8218bb8dfbaa03f23773318cf'/>
<id>fb88d74f0335cdf8218bb8dfbaa03f23773318cf</id>
<content type='text'>
ErrAccessUserKeyring:
	Include the user, and fix the backwards wrapping.

ErrSessionUserKeyring:
	Include the user.

ErrKeyAdd:
ErrKeyRemove:
ErrKeySearch:
ErrLinkUserKeyring:
	Replace these with one-off unnamed errors because they are
	never checked for, and this makes it easier for the callers to
	provide better messages, e.g. fixing the backwards wrapping.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
ErrAccessUserKeyring:
	Include the user, and fix the backwards wrapping.

ErrSessionUserKeyring:
	Include the user.

ErrKeyAdd:
ErrKeyRemove:
ErrKeySearch:
ErrLinkUserKeyring:
	Replace these with one-off unnamed errors because they are
	never checked for, and this makes it easier for the callers to
	provide better messages, e.g. fixing the backwards wrapping.
</pre>
</div>
</content>
</entry>
<entry>
<title>Try to detect incomplete locking of v1-encrypted directory</title>
<updated>2020-05-09T22:16:13+00:00</updated>
<author>
<name>Eric Biggers</name>
<email>ebiggers@google.com</email>
</author>
<published>2020-05-09T21:17:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.hodgden.net/cgit.cgi/fscrypt.git/commit/?id=de51add609bc74b7247ec4776bd694abbea24a45'/>
<id>de51add609bc74b7247ec4776bd694abbea24a45</id>
<content type='text'>
'fscrypt lock' on a v1-encrypted directory doesn't warn about in-use
files, as the kernel doesn't provide a way to easily detect it.

Instead, implement a heuristic where we check whether a subdirectory can
be created.  If yes, then the directory must not be fully locked.

Make both 'fscrypt lock' and 'fscrypt status' use this heuristic.

Resolves https://github.com/google/fscrypt/issues/215
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
'fscrypt lock' on a v1-encrypted directory doesn't warn about in-use
files, as the kernel doesn't provide a way to easily detect it.

Instead, implement a heuristic where we check whether a subdirectory can
be created.  If yes, then the directory must not be fully locked.

Make both 'fscrypt lock' and 'fscrypt status' use this heuristic.

Resolves https://github.com/google/fscrypt/issues/215
</pre>
</div>
</content>
</entry>
<entry>
<title>cli-tests: add t_v1_policy</title>
<updated>2020-05-09T21:04:47+00:00</updated>
<author>
<name>Eric Biggers</name>
<email>ebiggers@google.com</email>
</author>
<published>2020-05-09T21:04:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.hodgden.net/cgit.cgi/fscrypt.git/commit/?id=b13bfeef21c18302dcb31f7fb6d354da9a5a567b'/>
<id>b13bfeef21c18302dcb31f7fb6d354da9a5a567b</id>
<content type='text'>
Test using v1 encryption policies (deprecated).
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Test using v1 encryption policies (deprecated).
</pre>
</div>
</content>
</entry>
</feed>
