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.
> 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.
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.
> > 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.
If this is not a use-case that the upstream developer supports, then I
think that's dangerous, because upstream will be happily writing code that
assumes the calling user is trusted (because under normal circumstances,
they are!), and it's up to the Debian maintainers to audit for code that
will break their assumptions whenever they update the Debian package.
Shared library dependencies also become problematic if msmtp is acting
as a security boundary, because msmtp might have chosen to be a security
boundary, but random shared libraries that it happens to use almost
certainly didn't.
It's reasonable to write a MTA that is designed to be setgid and behave
like "part of the OS", but that MTA would need to be as minimal as
possible, and designed around the rule that everything that comes from its
untrusted caller (command-line options, environment variables, resource
limits, inherited file descriptors...) must be distrusted until it has
been proved to be safe. exim works like this (setuid rather than setgid,
but it's the same idea). However, a MTA designed like that shouldn't be
talking to or trusting the D-Bus session bus, because the way the D-Bus
session bus is designed, you can only find out which socket to connect
to by being told by the caller (who we are assuming we don't trust) -
and anyway the session bus and the other programs connected to it (like
gnome-keyring or KWallet) are totally under the user's control too,
so they could also be doing their best to subvert the MTA.
(Also, you can see from exim's entry on the security-tracker that writing
secure setuid/setgid programs is not easy, even if the upstream is an
expert who knows they are writing security-sensitive code: CVE-2010-4345
and CVE-2016-1531 are examples of vulnerabilities at this boundary.)
Equally, it's entirely reasonable to write an unprivileged, "user-facing"
MTA utility similar to esmtp, that can read credentials from gnome-keyring
or KWallet using larger libraries like libsecret and larger per-user
services like the D-Bus session bus - but then that MTA should be
assumed to be entirely under the user's control: it should just be an
ordinary user program doing the same email-sending that the user could
equally well do themselves through something like mutt or Thunderbird,
and should not be setgid or otherwise privileged. I get the impression
that this is the model that msmtp's upstream has in mind?
Those two MTAs are both reasonable, but I don't think they're the same
program - the requirements are different. They could share code, if the
code they share was written defensively enough to be safe for both uses
(but, again, that's dangerous unless your upstream is consistently
thinking like that) but I don't think they can share a binary. One wants
to be small, defensive and setgid, the other wants to be fully-featured
and unprivileged.
Back when msmtp had two builds (msmtp with minimal dependencies, and
msmtp-gnome with gnome-keyring integration) maybe it made some sense
for the minimal build to be setgid, but not msmtp-gnome?
smcv
