tech-kern archive

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

Re: /sbin/reboot and secmodel



On Tuesday, 18 Mar 2008 1:15:15
Daniel Carosone <dan%geek.com.au@localhost> wrote:

> .. at which point a more suitable new privileged process is
> developedto handle the specialised responsibilities involved,
> including asneeded new specialised privileges assigned to a
> dedicated user thatruns this process.  This is still unix, surely?

For this particular case I also think that moving the code to init
would be a good idea.  Init could indeed fork daemons as needed under
the the required credentials for various similar tasks, which it could
delegate RPC-like requests to.

Under such a model it would even be possible for init to only spawn
such privilege-separated processes on-demand (a-la inetd but running
already loaded code, and optionally leaving it running afterwards if
the operation is expected to occur frequently).

Could such a system, if made modular enough, be useful in a number of
other cases?  Also, should a userland<->userland communication
facility be used, or a kernel->init facility only (requireing syscalls
to trigger such, perhaps via a special kqueue filter or ioctl-like
manner)?

If userland to userland, I fail to see how the secmodel module could
deny the request cleanly, although it would be possible for init to do
it (and potentially use an access(2)-like syscall if it needs to query
the secmodel).  If reboot(8) had to use a special syscall to reboot
then it would be possible to do this safely, provided that syscall
internally signals/queries init...
-- 
Matthew Mondor


Home | Main Index | Thread Index | Old Index