Bug 218392 - mail/dovecot2: incompatible with security.bsd.see_other_uids and security.bsd.see_other_uids
Summary: mail/dovecot2: incompatible with security.bsd.see_other_uids and security.bsd...
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Adam Weinberger
Depends on:
Reported: 2017-04-05 07:27 UTC by topical
Modified: 2018-03-02 20:07 UTC (History)
3 users (show)

See Also:
bugzilla: maintainer-feedback? (adamw)


Note You need to log in before you can comment on or make changes to this bug.
Description topical 2017-04-05 07:27:41 UTC
If you harden your FreeBSD system by enabling security.bsd.see_other_uids (or security.bsd.see_other_uids), dovecot locking gets broken leading to data loss. 

Dovecot uses lock files to make sure at most one process writes to a data file. In case the writer process has died unexpectedly and didn't remove the lock file, the file would be locked forever. To handle this, dovecot always checks the PID existence of the lock owner and wipes the lock if the PID doesn't exist.

If security.bsd.see_other_uids is active, the PID existence always fails if the process owning the lock ("A") runs with a different UID then the process that wants to acquire the lock ("B"). The second process ("B") thus assumes that the current owner ("A") has died, wipes the lock and writes concurrently(!) to the data file. This means that locking doesn't work at all and data loss is unevitable. 

Later on, the original owner ("A") will generate a syslog warning that its lock file got lost somehow, but it's too late and the data file has been broken already leading to further problems like lost mailboxes etc.

Workaround is to disable this hardening.

As this side-effect is far from obvious, I suggest to add a clearly visible hint to the release notes of dovecot2.
Comment 1 Adam Weinberger freebsd_committer 2017-04-05 15:44:08 UTC
I definitely agree about adding a warning message.

Have you reported this upstream?
Comment 2 topical 2017-04-05 18:29:09 UTC
(In reply to Adam Weinberger from comment #1)

I haven't reported this upstream as I regard this as a very FreeBSD specific problem the dovecot developers cannot really be aware of. Perhaps there should be even some code to be added that refuses to start dovecot under these circumstances or least print a big warning. Being relatively new to FreeBSD I have no idea who takes care of such things.
Comment 3 Adam Weinberger freebsd_committer 2017-04-08 17:51:44 UTC
I'll add a warning about this in the pkg-message in the upcoming 2.2.29 update. 

see_other_uids/gids is an important hardening tool, and I hate to declare them totally incompatible. Can procfs be leveraged to work around this?
Comment 4 Adam Weinberger freebsd_committer 2017-04-11 00:25:20 UTC
Okay, I've added a warning for this in r438222. Thanks for submitting this. I strongly urge you to report this upstream. I'm leaving this PR open for now.
Comment 5 Jeremy Chadwick 2017-05-03 19:52:16 UTC
This PR is confusing.  The descriptions given of the conditions for this problem to happen don't make sense, i.e. terminology/grammar thing.  The problem itself makes sense, but the information pertaining to the sysctls do not.

Let's get this out of the way: descriptions of the sysctls themselves and their default values on FreeBSD 9.3 and 10.3 (haven't looked at 11.x):

root@freebsd:~ # sysctl -d security.bsd.see_other_uids security.bsd.see_other_gids
security.bsd.see_other_uids: Unprivileged processes may see subjects/objects with different real uid
security.bsd.see_other_gids: Unprivileged processes may see subjects/objects with different real gid

root@freebsd:~ # sysctl security.bsd.see_other_uids security.bsd.see_other_gids
security.bsd.see_other_uids: 1
security.bsd.see_other_gids: 1

These defaults are normal for any UNIX or UNIX-like (ex. Linux) system out there; out-of-the-box, non-root users can see other non-root users' processes.  Setting the above sysctls to 0 inhibits that behaviour (i.e. UID 1000 can only see UID 1000's processes, GID 500 can only see GID 500's processes, etc.).

Here is where the confusion begins, and proliferates throughout the PR and now the port:

> If you harden your FreeBSD system by enabling security.bsd.see_other_uids (or security.bsd.see_other_uids) ...
> If security.bsd.see_other_uids is active

Does this mean security.bsd.see_other_uids=1 or security.bsd.see_other_uids=0?  The phrase "is active" implies 1, but "hardening security" implies 0.

This what ended up in pkg-message:

> To avoid a risk of mailbox corruption, do not enable the
> security.bsd.see_other_uids or .see_other_guids sysctls if Dovecot
> is storing mail for multiple concurrent users (PR 218392).

The wording here says "do not enable", which implies 1.  (Also, it is "gids", not "guids").

My gut feeling is the issue only happens with security.bsd.see_other_{uids,gids}=0, which means "do not enable" is backwards.  It should instead say "do not DISABLE", because the sysctl itself is named "see_other_uids" and defaults to 1.

**If** this happens when the value is 0, then might I suggest ceasing use of enable/disable and instead state the sysctl value, i.e.:

> To avoid a risk of mailbox corruption, do not set sysctls
> security.bsd.see_other_uids or .see_other_gids to 0 if Dovecot
> is storing mail for multiple concurrent users (PR 218392).
Comment 6 Adam Weinberger freebsd_committer 2017-05-03 22:36:21 UTC
You're right, "enable" is unclear. I'll include the improved wording in the next dovecot patch update.
Comment 7 commit-hook freebsd_committer 2018-03-02 20:06:02 UTC
A commit references this bug:

Author: adamw
Date: Fri Mar  2 20:05:21 UTC 2018
New revision: 463446
URL: https://svnweb.freebsd.org/changeset/ports/463446

  Improve clarity of dovecot's pkg-message

  Change an ambigious "enable" to the actual value that causes a problem,
  and fix spelling of "gid".

  No PORTREVISION bump---there's a major update coming shortly, and this
  change will get picked up then.

  PR:		218392
  Submitted by:	Jeremy Chadwick

Comment 8 Adam Weinberger freebsd_committer 2018-03-02 20:07:38 UTC
Jeez, I forgot all about this! I'm so sorry. This should have been committed ages ago.

I've committed Jeremy's wording. I didn't bump the PORTREVISION, but it'll get picked up in the packages later this month when 2.3.1 comes out.