On Thu, Jul 12, 2001 at 09:22:35PM +0200, Shane Kerr wrote: > (perhaps by using other hooks and dropping privileges for the > processes - i.e. when exec() runs "ntpd" drop all privileges except > for bind() and adjtime(), and when that process calls bind() drop that > privilege - yuck)? Heh, what you are looking for is 'capabilities operating systems', such as KeyKOS or EROS or <insert more names here>. Such fine grain is all one has under capabilities systems. I don't think that any LSM interface could support what you want through permission functions without also being very difficult to get right. Read: commercial unix vendors have tried similar things, and users always seem to be able to use one or the other so-called capabilities to gain more until the user is a full root user with all so-called capabilities. If those others have tried and failed, I think we ought to try to steer clear of this path. Trying to restrict something granted root access versus granting small root-ish permissions to notroot users probably wind up with many of the same problems -- but at least the one is making the admin think, "do I really want this user to have root access?" (i.e., the difference is psychological.) Noble goal, but I don't think Unix is the right starting place. As far as your example here with such clearcut 'bad' syscalls, my first possible solution idea is to use the security blob in the task structure of each process to hold a bitfield or list of allowed syscalls. Then, you could leave the 'adjtime()' calls to your one ntpd process. Interpose on all syscalls (through the normal mechanism), check the list of allowed syscalls, and decide then whether to return -EPERM or call the real syscall. _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Thu Jul 12 2001 - 13:29:25 PDT