On Mon 2019-02-11 17:15:53 -0500, Scott Kitterman wrote: > I can see advantages to this approach. I took the path I did since I was > implementing an opendkim replacement and that's how it's done there. > > I think the milter would have to do something obnoxious like fail to start if > it had write access to the keys. I have vague and not well formed concerns > that it being able to do that could be bad.
I agree it would be bad, but i'd be happy with an obnoxious warning
about unnecessarily-writable keys, and not a crash.
> I think a MAC system like SE Linux or Apparmor probably makes more sense as a
> security measure on modern systems than using a chroot, so that's probably
> not
> a concern.
makes sense.
> It would probably cause some significant deployment friction in the short-
> term, since no distros would have it (unless it's something we can include in
> the package, which means something in Python, not C).
>
> In the near-term, I think we need to have two ways to start: one with systemd
> (socket activation) and one for all other init systems. If you can give me
> an
> idea what the socket activation changes might look like, I can think about
> how
> I might integrate the two.
hm, i'm looking at python3-milter -- the main issue i see is that
libmilter seems to want to open the socket on its own, and i don't see a
way to ask libmilter to simply use a file descriptor that you already
have available :( So it's possible that this won't work without some
patches to sendmail (e.g. passing an "fd:3" string to setconn()), which
is a drag.
Is there some pythonic milter implementation that *doesn't* link against
libmilter?
--dkg
signature.asc
Description: PGP signature
