[vox-tech] Linux file/module security proposal.

[Rick Moen]

Quoting Bill Broadley (bill at cse.ucdavis.edu):

> 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."