Hi, There is a lot of critical stuff in /sbin and /usr/sbin... First, you need to fully harden the Linux installation. The lesser you have packages, the better you are protected against vulnerabilities.
I would definitely not let non-admin user run the whole thing on these folders... I'm neither a fan of sudo, but when carefully configured, it is still better than a lot of other solutions. Consider letting the user only executing your own hardened scripts that does not require ANY environment variables - hardcode every binary path - and do run Tripwire to verify that nobody alters the critical files on the system. If you do not want to run Tripwire, just put the scripts and binaries to run with sudo on a locked (RR) dasd, then a malicious user will not be able to modify these scripts. You'll also need to look carefully your log files for abuse of sudo. On 7/11/06, Rob van der Heij <[EMAIL PROTECTED]> wrote:
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
---------------------------------------------------------------------- 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
