* Arthur de Jong [2017-06-25 12:50:13 +0200]:
> Thanks for your service description. I am a bit reluctant to add
> restart-on-crash to nslcd and it could be a security risk in general
> for daemons.
> 
> One reason for this is that it potentially turns a denial of service
> vulnerability into something much worse (e.g. remote code execution).
> This is especially true when address space randomisation is used.

There is obviously a tradeoff here; the right answer will vary from service
to service and from site to site. I suspect your argument is more applicable
to Apache httpd since it's a lot more exposed to input from untrustworthy
sources.

> If, for example, there is a flaw in a daemon that you can use to
> trigger remote code execution only in a certain percentage of exploit
> attempts (and otherwise causing a crash) with auto-restart you will
> have more attempts at the exploit. If I read the systemd documentation
> correctly it has some mechanisms to limit this though
> (StartLimitIntervalSec and StartLimitBurst).

Such rate-limiting is of course essential, if only to maintain efficiency
when there is some persistent reason a service keeps failing. I believe
it's on by default. An attacker could get more attempts by throttling its
own activities, but that also gives more time to the defence.

> Another issue is that if a daemon crashes there certainly is a bug
> somewhere. If the service is silently restarted on crashes the bug will
> less likely be reported and fixed leaving a bug around longer.

How much less likely? I wonder.

> The biggest reason however for not switching to a systemd service file
> is that I want to keep is starting k5start if nslcd.conf has sasl_mech
> and krb5_ccname configured. This is now implemented in the init script
> and configurable in /etc/default/nslcd. I have not been able to figure
> out how to do this in systemd yet.

I believe there is prior art for this. In any case, I did not mean to
imply that you should provide a native systemd service file, only that
systemd's generator is doing a suboptimal job on your SysV init file and
may need to be given some hints. Incidentally, the solution I described is
such that a system administrator can choose to apply it even if you don't
enable it as a default; it's enough to document it.

(https://wiki.csclub.uwaterloo.ca/LDAP mentions one instance of prior art.
I would also look at the systemd units from source package nfs-utils for
inspiration. I'd probably want nslcd-k5start.service to wait on
network-online.target to keep the time during which nslcd cannot bind to
the LDAP server at a minimum; k5start applies exponential backoff to the
retry interval.)

Reply via email to