On Thu, 2005-07-14 at 14:17 +0100, Timothy Murphy wrote: > Paul Howarth wrote: > > >> > >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. > > > 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. > > I can (sort of) see the argument for noexec on /var , > but why on /tmp ? Why one and not the other? > This seems to me a bit like locking the loo > in case someone breaks into the house. I really don't see the difference. The second most common exploit attack I see on my server after the ssh password-guessing attack is an attempted awstats exploit where the attacker tries to download a rootkit into /tmp and run it from there. If I was running a vulnerable awstats installation (i.e. all of them until recently - I hope this bug is actually fixed in the current release but I don't know as I don't use it), mounting /tmp noexec would have saved me. > Actually, that is something I have never really understood about selinux. > It has always seemed to me that if someone broke into my system > they could do so much damage anyway it is hardly worth while > trying to minimise the damage. SELinux blocks many of the attack vectors an attacker can use. For instance, if httpd cannot write anywhere because of SELInux policy, no vulnerability in httpd is going to allow an intruder to get into your system via that route in the first place. > I'd feel I had to re-install the system anyway, > as I could never be sure something evil had not been left behind. > But that is probably just a reflection of my ignorance? If an intruder did actually get in, a reinstall is exactly what you should do. SELinux is helping you to keep them out by attempting to limit what everything on the system has access to, so that just-discovered vulnerabilities in the software you use can't be used to attack your system successfully. Paul. -- Paul Howarth <paul@xxxxxxxxxxxx>
