On 2021-02-17 8:30 p.m., Simon McVittie wrote:
On Wed, 17 Feb 2021 at 18:01:26 -0500, Simon Deziel wrote:
1) you are worried that since msmtp wasn't written with setgid in mind,
there's a risk of someone elevating their privileges to $USER:msmtp to
execute code
=> Doesn't that just give you read access to /etc/msmtprc?
I don't know, I don't use msmtp. Presumably yes?
If this is worth protecting by using OS-level security boundaries,
then it seems to me that it's worth protecting in a way that isn't
easily defeated - otherwise the effect is to give sysadmins a false
sense of security.
If by easily defeated, you mean leaking the SMTP password with 'msmtp
--debug' then I fully agree. If on the other hand you are implying that
the setgid feature could be abused to leak the SMTP password, then I
wouldn't consider this easily defeated.
2) Glib should be hardened to treat setgid processes specially to make it
more secure. Doing so breaks the msmtp libsecret integration.
Yes, ish. It's more like: GLib should ideally be hardened to treat all
processes that have the AT_SECURE flag equally specially. AT_SECURE is
the kernel telling us "you have privileges, be careful not to trust your
parent process", and ideally GLib would always respond to that by being
as careful as possible.
However, GLib 2.66.4-2 tried being as careful as possible, and it turns
out to make programs (at least msmtp and gnome-keyring) regress, by
preventing them from learning the address of the D-Bus session bus. At the
moment, GLib is second-guessing that warning from the kernel and asking
"but am I *really* privileged, or just *slightly* privileged?" in order to
keep msmtp and gnome-keyring working, but that's extra security exposure -
and not just in msmtp, but also in programs that are protecting something
more important than a SMTP password.
Thanks for the clear explanation!
GLib is not really in a position to know that setgid msmtp is any less
dangerous than setgid shadow, or setgid adm, or setgid sudo. If we tried
to hard-code which privileges are genuinely important and which privileges
are unimportant, that would scale really badly.
Agreed.
I would recommend removing the setgid support from msmtp, and recommending
that people who want a system-wide authenticating MTA whose credentials
are not disclosed to unprivileged users
Doing so by default would let everyone read creds from /etc/msmtprc which
sounds easier than abusing a setgid (even one not designed to run that way).
If Debian wasn't telling sysadmins "it's safe to put msmtp credentials in
/etc/msmtprc, unprivileged users won't be able to read them", then they
could make their own decision about whether it's acceptable for unprivileged
users on their systems to be able to see the SMTP password.
If that's fine for that particular sysadmin's threat model, then the setgid
mechanism would be unnecessary.
If not, then that sysadmin should probably be choosing something "heavier"
than msmtp, that does put a real security boundary between users and
SMTP credentials, and treats it as a security vulnerability with CVE IDs
and advisories if that boundary fails - like exim or postfix. And, yes,
that often implies running a daemon. The sysadmin will have to decide
whether that's worth it.
That said, msmtp is really nice due to not having to run a daemon.
Of course - I don't use msmtp myself, but I've used similar small
SMTP-sending implementations like esmtp in the past, and I recognise the
advantages of that architecture. However, this architecture comes with
limitations, and I think it's important to be realistic about what msmtp
can and can't promise.
>
As a user, I guess I wouldn't mind having that setgid behind a debconf
question. Would that middle ground work?
I'm not sure that really helps. If the sysadmin doesn't trust msmtp
to keep passwords safe from unprivileged users, they can just not put
those passwords in /etc/msmtprc, or at the other extreme, if they don't
care whether unprivileged users can read those passwords, then they can
make it world-readable. The problem case is in the middle, where msmtp
is promising that it will protect the credentials, and the sysadmin
believes its promise, but actually they should not have done. If a
sysadmin is in that position, then they'll answer the debconf question
"yes, make it setgid" and then be disappointed or angry when their
passwords are disclosed.
If msmtp is promising to protect the credentials from unprivileged users,
under at least some configurations, then it needs to be designed to do
that. If it's going to do that in a way that lives up to that promise, > then
every line of code that ends up in its process space (including
libraries) needs to have been written, or at least reviewed, while
thinking "what's the worst possible way this could be tricked by a
malicious user?" - otherwise it's just providing a false sense of
security.
That represents a *lot* of effort and as you pointed out, exim tried and
failed, leading to escalations to root.
I think the non-world-readable /etc/msmtprc config is a special case
meant to allow unprivileged users to send emails (like cron).
I would (naively?) assume that msmtp could detect that and disable most
features (--debug, --server, --proxy, etc) when that's the case. This
way the local sysadmin could say "yes, make it setgid" and have at least
some protections around the SMTP password rather than none otherwise.
It wouldn't be perfect but I believe it would raise the bar at a
fraction of the cost.
As for the false sense of security, the above proposal could be coupled
with a warning around the setgid debconf question. Something like:
> The system-wide configuration file (/etc/msmtprc) can contain SMTP
> credentials that are best kept secret. To let regular users use msmtp
> while preventing them from reading the file, the permissions can be
> adjusted that way:
>
> # chmod 0640 /etc/msmtprc
> # chgrp msmtp /etc/msmtprc
>
> And the msmtp binary can be "setgid" to execute as the "msmtp" group.
>
> CAUTION: the "setgid" only provides a weak protection. If the SMTP
> credentials need better protection, please consider a
> different MTA like exim or postfix that offer clear security
> boundaries.
I realize it's all up in there air and I cannot contribute the code to
have msmtp special case /etc/msmtprc's config but I appreciate the
discussion :)
Regards,
Simon
p.s.: switching to client-side TLS certs would also require a setgid
binary but presumably it would be harder to leak this form of creds. I
really wanted a simple daemonless MTA no needing world-readable creds :/
