[pkg-go] Comments regarding prometheus-postfix-exporter_0.1.2-1_amd64.changes

[Scott Kitterman]

The distinction is that showq is specifically documented as an internal 
interface and postqueue is public.  From an FTP team perspective, this isn't 
more problematic than other things in the archive, so I'm going to accept is, 
but I would encourage you to work with upstream to move to the public 
interface (even if that means working with the postfix developers to extend 
postqueue).

Scott K


On Monday, February 04, 2019 11:10:34 AM Daniel Swarbrick wrote:
> Hi Scott,
> 
> Thanks for your feedback.
> 
> On Debian (and other) systems running Postfix, /usr/bin/mailq is a
> symlink to /usr/sbin/sendmail. When running "sendmail -bp" to view the
> contents of the queue, this execve's "/usr/sbin/postqueue -p", which
> outputs the contents of the mailq in the traditional format. Postqueue
> is a setgid binary (postdrop group), which is how it is able to access
> the showq socket inside Postfix's chroot (/var/spool/postfix).
> 
> There is nothing to prevent local shell users from running this command
> as often as they please, however Postfix limits the number of
> simultaneous showq processes to 100 by default.
> 
> Obviously prometheus-postfix-exporter removes the hurdle that an
> attacker needs to have a local shell account. In the Prometheus docs on
> security (https://prometheus.io/docs/operating/security/), they state:
> 
>     Prometheus and its components do not provide any server-side
>     authentication, authorisation or encryption. If you require this, it
>     is recommended to use a reverse proxy.
> 
> It is generally accepted in the Prometheus community that exporters
> should only be accessible to trusted clients. Since HTTP request
> security is (currently) out of scope for Prometheus, the usual practice
> is to host exporters behind a small reverse proxy daemon, which
> implements authn / authz and optionally request rate limiting, if
> security is a concern.
> 
> Many of the already published Prometheus exporters have the potential to
> DoS the services that they connect to or hosts they run on, if they are
> scraped frequently enough.
> 
> On 02.02.19 08:28, Scott Kitterman wrote:
> > I am concerned that an external package using showq is going to be
> > problematic.  Some excerpts from showq (8):
> > 
> > The showq(8) daemon reports the Postfix mail queue status.  The output is
> > meant to be formatted by the postqueue(1) command, as it emulates the
> > Sendmail `mailq' command.
> > 
> > SECURITY
> > 
> >         The  showq(8)  daemon  can  run in a chroot jail at fixed low
> > 
> > privilege, and takes no input from the client. Its service port is
> > accessible to local untrusted users, so the service can be susceptible to
> > denial of service attacks.
> > 
> > STANDARDS
> > 
> >         None. The showq(8) daemon does not interact with the outside
> >         world.
> > 
> > We don't install showq on the system path for a reason.
> > 
> > How does this package make sure it doesn't DOS postfix?
> > 
> > Before we accept/reject this package, I'd appreciate some feedback on the
> > design.  It's not obviously something that is appropriate for Debian.
> > 
> > Scott K