The C program is a good idea but : 1) remove the gcc and other build tools after the development !
2) you will still need Tripwire to be sure nobody replaces your binary... or use a RR dasd. The SETUID bit is a good idea if you are sure that the binary is not modified by a malicious user. A quick hint for RR dasds : do modify the /etc/syslog.conf so that kernel warnings and more important messages are displayed on the console of every admin users, because Linux will let you mount a RR volume as read-write, but you will lose any modification made. By defaults, reports goes directly to the syslog messages. For example, add this line to the end of the file, then restart syslog : kern.warn root,foobar,toto,youruser On 7/11/06, Richard Troth <[EMAIL PROTECTED]> wrote:
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
---------------------------------------------------------------------- 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
