WARNING:DO NOT UPGRADE TO CORE 4
paul at city-fan.org
Thu Jul 14 08:34:59 UTC 2005
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....
> 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,
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 Howarth <paul at city-fan.org>
More information about the users