Quoting Bill Broadley ([EMAIL PROTECTED]): > Yup, /dev/kmem, /dev/mem and friends need protected, I think that's default > these days, might need a tweak or two, it's been implemented with selinux, > seclvl, er, I think grsecurity and a few others.
I've in the past had very good experience with grsecurity on 2.4 kernels. There was a while when it was unclear what exactly would happen in the 2.6 series, but that's been resolved: Now, you get a kernel patch with the buffer-protecting PaX scheme (enforcement of non-executable pages protection of /dev/kmem / /dev/mem / /dev/port, etc.), improved /tmp handling (anticipating race-condition attacks), control over who's allowed what process information, a number of filesystem protections, improved PID and TCP/IP source port randomisation, and an optional RBAC framework. I really think it should be routinely preferred for default systems (although as usual RBAC complicates one's life and is best approached with caution if at all). Maybe I'm shiftless, but I've seldom more than kicked the tires of any RBAC -- and, in that, I think I have a great deal of company. Most real-world RBAC on Linux amounts to "I installed {Fedora|RHEL|CentOS}, and it came with something called an 'SELinux targeted policy', which I left alone until {a Web app|a CGI|syslog-ng|cacti|a proprietary video driver} didn't work, and I couldn't figure out the required SELinux policy tweak, so I turned it off." _______________________________________________ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech