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