On 7/11/06, Rick Troth <[EMAIL PROTECTED]> wrote:
Consider what Kris said about the '-i' flag on 'sudo'.
It appears there's no such flag in the sudo that I have with SuSE so I can't tell. I believe my approach with coding su for one command is similar in effect? And even the auditing is as much as people want it to be. One of my colleagues coded a shell script in his home directory and then invoked that through sudo, and then modified the script. Very hard to tell what it did. I have been thinking about only allowing programs in /sbin and /usr/sbin. But then that's probably not close enough (/bin/sh is there too). What I did for some utilities is to code them "inside-out" so have a shell script that runs under the non-root id but calls sudo for the various delicate actions inside. This way you avoid side effects of running things as root where you would not need to.
What else would you suggest? We could hack something quickly in C.
I would rather exploit virtual machines to provide this kind of isolation. That is robust and if you do some work along my "Less than Class G" effort, there should be little risk to give customer staff root access on their own foot. It may take some creativity to assure you as service provider can still do what needs to be done. Yes, they may want to change the root password, so you want cryptic key authentication. I have seen customers change /etc/securetty for their (PC) standards but with root logged on at the console you can get far with SCIF. Having the kernel in NSS and maybe some code on R/O disk can add some more protection. Rob ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
