tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: /sbin/reboot and secmodel

At 01:32 AM 3/18/2008 -0400, der Mouse wrote:
>>> 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

I agree with this points raised in this discussion. It seems to me that moving things to init makes the system not-extensible-without-a-kernel-recompile. This is, of course, good for security in some sense; but it's not always practical or convenient. If I understood Elad's comments (big if), the purpose of sysauth was not to prevent extensibility, but to switch to a user-based authentication system.

If extensibility is needed in the context of secauth, it seems that the right thing to do is:

1) add a way for a process to express the intent to do a reboot
2) the secauth framework checks whether the current user is authorized to cause this to happen
3) if so, a token (perhaps a special file handle) is handed back to the process
4) add a way to provide that token as context for subsequent syscalls [again, in that process]. Secauth uses that context, combined with the particular system call, to make its decisions.

The "way" in step 4 could be a meta-syscall, sort of "(provide-security-context-for-syscall <context> (operation))" if one is thinking in lisp.

Best regards,

Home | Main Index | Thread Index | Old Index