> 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.
Hear here! I like your reference to read-only disk. Good suggestion about hardening scripts, but removes flexibility in the general case. Running through the equivalent of 'su -' forces a fresh environment, minimizing the exposure from a rogue variable passed from unprivileged parent to root-enabled child. With the lack of '-i' Rob points out, one must wrap the operation. Wrapping it in a shell script is quickest (and with sudo controls may be safe). Wrapping it in C is more robust. But clearly 'su -' profiling is needed. Heck, with C you could set the SETUID bit and dispense with 'sudo'. -- R, ---------------------------------------------------------------------- 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
