>>> I don't see why this isn't solved by moving this work to init (not
>>> the kernel, please).
>> In this particular instance, it is. But this is not going to be the
>> last time some multi-part privileged task causes trouble because
>> granting the privilege to perform its parts is far more than should
>> be granted to perform the conceptual task
> Fair enough (and that's a nice and concise description of the concern
> we share).
Thank you. :-)
> However:
>> and eventually one of them will be impractically difficult to solve
>> by pushing the whole task into some already-existing privileged
>> process.
> .. at which point a more suitable new privileged process is developed
> to handle the specialised responsibilities involved, including as
> needed new specialised privileges assigned to a dedicated user that
> runs this process. This is still unix, surely?
So, for every new privileged task, a daemon is staretd at boot and sits
around forever just in case anyone happens to want to perform that
task? Because if it can be started on demand, then we have the same
problem all over again, just in a slightly different guise - instead of
performing the original privileged operation, we have to perform the
privileged operation of starting this process. And if it sits around
forever, the system will become cluttered with huge numbers of such
prcesses, as privileged operations keep accumulating daemons to
implement them at need.
Not that there's anything _wrong_ with such a design; that kind of
thing is what microkernel architectures have been doing for a long
time. But it's a fairly radical departure from what the BSDs have
traditionally been, far more than I think just introducing secmodels
calls for. I think it would be much more appropriate to mutate set-ID
bits into something finer-grained, then use that in much the way set-ID
executables have traditionally been used to encapsulate complex
operations.