Bug 218392
| Summary: | mail/dovecot2: incompatible with security.bsd.see_other_uids and security.bsd.see_other_uids | ||
|---|---|---|---|
| Product: | Ports & Packages | Reporter: | topical <topical> |
| Component: | Individual Port(s) | Assignee: | Adam Weinberger <adamw> |
| Status: | Closed FIXED | ||
| Severity: | Affects Some People | CC: | chris, ler, rob2g2-freebsd, s.adaszewski, xistence |
| Priority: | --- | Flags: | bugzilla:
maintainer-feedback?
(ler) |
| Version: | Latest | ||
| Hardware: | Any | ||
| OS: | Any | ||
I definitely agree about adding a warning message. Have you reported this upstream? (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. 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? 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. 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). You're right, "enable" is unclear. I'll include the improved wording in the next dovecot patch update. 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 Log: 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 Changes: head/mail/dovecot/files/pkg-message.in 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. Hi, Sorry to reopen this but this seems like a pretty major claim. Is there even a proof that this is the case or is it anecdotal? Are we sure, that the situation has not changed upstream since 2017? Dovecot seems to have a TON of code related to locking - also there seem to be multiple locking mechanisms. Is this problem also the case if one runs only with one user (vmail) for a virtual users setup? Or does it already kick in with just the default dovecot/dovenull users? The details in this ticket are very scarce and since it was not reported upstream there is no way to even verify if the developers would have any insights. Thank you in advance for any hint. Best wishes, -- Stan I haven't checked upstream whether the way locking is done has been changed upstream, but I doubt that. I have reduced BSD hardening (I know - bad idea) and just live with that workaround. AFAIK there is a similar issue with samba. I don't know whether this problem still occurs with just one virtual user, but it _could_ be that even doveadm commands make trouble if they are executed as a different user. But all my testing was quite a long time ago. Does this issue happens with specific setup? I use security.bsd.see_other_uids=0 and dovecot for more than a decade in hundreds of servers with hundreds of virtual users on each server under seperate system accounts and didn't notice any issue. Maybe the issue is with Mbox format and not Maildir? I use mdbox instead of maildir. AFAIK maildir is much easier in terms of locking as it has one file per mail. mdbox combines multiple mails and can deduplicate attachments, which saves quite some disk space. But you have the problem that you need some kind of locking. So this really looks like the reason why you've never encountered locking problems. Maybe it should be precised in the pkg message then? I am using Maildir for example and as far as I understand I would not be affected by this "bug". It might be the case for many people and they are currently being driven into downgrading their hardening as long as the warning message remains as it is. I would definitely mention that it was observed with mbox format. |
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.