Re: smaclennan/doorknob

[Sean MacLennan]

On Sun, 27 Jan 2019 14:39:16 +
Jonathan de Boyne Pollard 
wrote:

> A lot of constructive comments on doorknob which I am not going to
> include here.

Well, I have updated doorknob to *hopefully* respond to all the
comments. I have pushed the changes to github if anybody is interested.

The big changes are moving the default location of the directories and
changing ownership.

Doorknob now has its own user. It basically does:

1. change to queue directory
2. setup inotify
3. drop privileges to doorknob user
4. read config
5. start handling messages

sendmail and mailq are now owned by the mail user and group
(configurable) and are +s.

The queues are now (by default):

chown mail.mail /var/spool/doorknob
chown mail.mail /var/spool/doorknob/queue
chown mail.mail /var/spool/doorknob/tmp
chmod 750 /var/spool/doorknob
chmod 777 /var/spool/doorknob/queue
chmod 700 /var/spool/doorknob/tmp

Everything is configurable. You can make the doorknob user root, the
mail user root, and everything is as before.

Comments welcome.

Cheers,
   Sean

smaclennan/doorknob

[Jonathan de Boyne Pollard]

 *

   The plural of "address" is "addresses".  "-ii" is not how any word
   pluralizes in English.

 *

   The way to monitor such a directory nowadays is with
   |kevent(EVFILT_VNODE)| or |inotify_*()|.

 *

   Long-known multi-user spool security precautions: /Always/ check the
   |d_type|; /always/ |fstatat()|/|fstat()| the spool file and check
   for |S_ISREG()|.

 *

   Long-known multi-user spool security precautions: Spool areas should
   be beneath a non-world-accessible parent directory, and the program
   that dumps into the spool should be set-group-ID to a group (or a
   /non-owner/ user) that has search access on the parent in order to
   reach the spool directory beneath.  Not doing this is an error that
   was initially made in Postfix years ago, avoiding all set-ID
   programs without realizing that set-ID is a necessarymechanism for
   secure multi-user spooling when it is in this form. (See Bruce
   Guenter's bcron  for an example of an
   alternative way that multi-user spooling can be structured using a
   submission server and UCSPI-UNIX.)

   The spool-processing dæmon itself does not need to run under the
   aegis of this group, if it is simply started up already in its spool
   directory using |chdir|
    (or cd
    or equivalent) in
   the |run| script.  (This also means that it does not need to
   hardcode the location of its spool directory.  Its spool directory
   is its working directory, where it works.)

 *

   Other security precautions: Dæmons such as this should /always/
   |setuidgid|
    away
   from the superuser in their |run| scripts to an account dedicated to
   the dæmon.  (Compare the |run| script in Bruce Guenter's nullmailer
   .)

 o

   Jonathan de Boyne Pollard (2019). "Limiting services: Running
   under the aegises of unprivileged user accounts
   ".
   /nosh Guide/. Softwares.

 o

   https://unix.stackexchange.com/questions/450251/

 *

   Other spool-processing dæmon security measures: The dedicated user
   account has no need to own /anything/, neither the spooled files nor
   the spool directory itself.  It needs only read+write+execute
   permission on the spool directory, and read permission on the spool
   files.  Having ownership permission as well permits compromised
   dæmons to change ACLs and permissions.

 o

   Jonathan de Boyne Pollard (2019). "Log service security:
   Dedicated log user accounts
   
"./nosh
   Guide/. Softwares.

 *

   Debian family operating system conventions:  That has not been the
   way to write a van Smoorenburg |rc| script for Debian family
   operating systems since 2014.

 o

   Petter Reinholdtsen (2014-02-09). init-d-script
   
.
   /File formats manual/. Debian.

 *

   C language standards: |stdout| is fully buffered if it is not an
   interactive device, which a pipe is indeed not. |stderr| is of
   course /not/ fully buffered.

 *

   Unix conventions: Logs go to standard error.