Re: /sbin/reboot and secmodel

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

        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?
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.
-Brian

On Mar 17,  1:40pm, "Steven M. Bellovin" wrote:
} Subject: Re: /sbin/reboot and secmodel
} On Mon, 17 Mar 2008 13:38:39 +0200
} Elad Efrat <elad%NetBSD.org@localhost> wrote:
} 
} > That one's a bit tricky. The reboot program tries to "gracefully"
} > reboot the system by doing some things it believes it's doing as
} > root. Since at the moment the KAUTH_SYSTEM_REBOOT action applies only
} > to the very reboot(2) syscall, it "breaks" somewhere in the middle
} > when trying to stop init (and later on signal all other processes).
} > 
} > While it may be possible to solve it with a lot of special casing, I
} > wonder if we shouldn't just move a lot of that logic to the kernel,
} > and add a RB_GRACEFUL to reboot(2), telling it "do all the things you
} > used to do in userland".
} > 
} > Is anyone seeing possible problems taking this route? any other ideas
} > on how to address this?
} > 
} What occurs to me is to use secmodel to restrict or grant access to the
} user-level program that does the shutdown -- that would avoid moving
} too much goo to the kernel.
} 
}               --Steve Bellovin, http://www.cs.columbia.edu/~smb
>-- End of excerpt from "Steven M. Bellovin"