Re: /sbin/reboot and secmodel

[buhrow%lothlorien.nfbcal.org@localhost (Brian Buhrow)]

        Hello.  I haven't looked, but I assume that reboot(8) and shutdown(8)
currently fetch a list of processes to signal, then signal each process in
turn?  If so, then it would make sense to me to have the sec model either
permit or deny each signal to be sent from one process to another, based on
the sending process's credentials.  Since signal(2) is another system call,
wouldn't it make sense to just have it be another system call that the sec
model guards  It seems like this approach has the advantage that you don't
need to change the already working prorgrams, and there's a general
solution for the question, how can I permit an arbitrary process that's not
root or the current user, to send a signal to another process on the
system?
-Brian

On Mar 17,  5:55pm, Elad Efrat wrote:
} Subject: Re: /sbin/reboot and secmodel
} Brian Buhrow wrote:
} >     Hello.  This may miss the point entirely, but don't you do this by
} > setting the group execute bit on  shutdown(8) only, and putting the users
} > you want to have  access to this utility in the appropriate group?
} >     Or, are you trying to eliminate set[GU]id programs entirely from the
} > system?
} 
} Not shutdown(8) as it can be used to do other things, but maybe
} reboot(8). Anyway, I'd like to be able to implement this as a secmodel
} policy rather than rely on sugid bits. (which, eventually, I'd like to
} get rid off, yes ;)
} 
} > If that's the case, I'm with smb, change the SEC model to allow access to
} > certain system calls by certain uids, or what ever criteria the sec model
} > can use, but make the sec model a gate keeper for the system calls.
} 
} The secmodel already does that. If you'd call reboot(2) directly, you'd
} be granted access to reboot the system (verified). The problem is with
} "graceful" rebooting, where reboot(8) is first trying to send a SIGTERM
} to all processes, etc.
} 
} -e.
>-- End of excerpt from Elad Efrat