On 2015-10-28 17:47, Theo de Raadt wrote:
>> I was just trying to pledge(2) spamd(8), nevertheless came across 2
>> priviliges kern_pledge.c is missing for this to work.
>>
>> First spamd(8) needs to read sysctl kern.maxfiles in order to see if it
>> can launch with that value or not, and second if the multicast options
>> are passed as parameters then it also needs IP_MULTICAST_TTL since
>> spamd(8) calls setsockopt(2) with that option set:
>
> I am not a fan of this approach. Your diff is very close to
>
> pledge("everything")
>
> That is a very small stopgap against a problem. Though you now have a
> list of things being done in one process, and good argument for someone
> to refactor this into privsep......
>
> My gut reaction is to not allow these two operations. I normally wait
> until I see evidence other programs need such operations, while being
> very strongly protected from pledge. Not seeing that here.
Also, I wonder what the point of having a sanity check against
kern.maxfiles at all is, especially with the arbitrary-feeling
additional rule of "maxcon may not exceed kern.maxfiles - 200". It feels
redundant to me, and it sort of makes a promise of protection it can't
uphold.
I mean, it's a system-wide limit and spamd has no control over the
resource usage of the rest of the system, so it still has to (hopefully
gracefully) handle the case when it runs up against either kern.maxfiles
or RLIMIT_NOFILE.
Removing that check at least simplifies that part of spamd's pledge().
Regards,
/Benny
