On Wed, 2005-07-13 at 16:41 -0400, Robert Locke wrote: > On Wed, 2005-07-13 at 14:16 -0500, Mike McCarty wrote: > > Paul Howarth wrote: > > > > ><snip> > > > > > >My point was that there's no way of knowing what undiscovered > > >vulnerabilities there are on your system, so having multiple layers of > > >defences such as firewalls, mounting /var and /tmp partitions with > > >noexec, selinux etc. all help to mitigate the risk. > > > > > > > > Ah, an aswer. I'm perhaps vulnerable to something being put into > > /var or /tmp (/tmp world writable) and then being executed from there. > > > > Now that's useful information. So, I possibly should remove '..x..x..x' from > > /tmp? That's an idea. BTW, on my system, /tmp is not a separate volume. > > > > Whoa, Mike. Do not change the permissions on /tmp as you seem to be > implying. Lots o' things will break if you change /tmp from it's normal > 1777 permissions (drwxrwxrwt). Remember that "x" on a directory has > nothing to do with executing something really but rather is allowing > someone to "cd" into that directory.... Absolutely! > What the earlier suggestion was getting at for you was to modify the > "mount options" for your separate /tmp filesystem (presuming you have a > separate filesystem for /tmp). You would edit /etc/fstab and find the > line relating to /tmp and change the fourth column to include "noexec" > and/or perhaps "nosuid". Of course, some applications may presume an > ability to "exec" a file in /tmp and some applications may rely on that > file having the "SUID" bit set, so doing this could break something, > YMMV..... The noexec option on /var and /tmp has caused me a few issues in the past, and they can be quite hard to diagnose, as everything may appear to be working normally most of the time. There was a bug (now fixed) in logrotate where it would write the pre- and postrotate scripts in /var or /tmp and try to execute them from there. The net result of this was that some log files didn't get rotated properly the weekend after I turned on the noexec option. Building the stock sendmail RPM didn't work because the default buildroot location is in /var/tmp and the build process tries to use the "makemap" program it's just installed into the buildroot to create the initial databases for /etc/mail. This can be fixed by changing the buildroot to be in a location (e.g. my home directory) where execs are allowed. Anything you do to harden a system may affect its usability in some way - just just have to be on the lookout for issues and have your wits about you to be able to diagnose and fix the issues. Paul. -- Paul Howarth <paul@xxxxxxxxxxxx>
