that's one of the reasons i patch the vserver kernel with grsec too.
also you get PAX (aslr, mprotect stuff,...) features (www.grsecurity.net)
which makes it extremely hard to write to /dev/kmem, /dev/mem, it hides
"dangerous" addresses to make exploitation harder, etc...
if you want enhanced security and you know something about grsecurity
(which means, you know how to secure a box):
http://people.linux-vserver.org/~harry
there you'll find the info you need. since this is ... well... personal
choice in what to enable/disable, you're not gonna find this together
with some distro. nevertheless, i include example configs (for dell and
HP servers at work)
good luck with it :)
Martin wrote:
At the risk of sounding ungreatful for all of the hard work done on
vserver - what is the 'use case' for this feature? As I understand it
there is nothing to keep the host from playing with /dev/kmem or
otherwise tampering with the kernel, so I can't see how a feature like
this will provide any strong guarentees; unless heirarchies of contexts
(which would be extreemly cool) are planned. Or is it just intended as
a 'speed bump' / politeness feature?
--
harry
aka Rik Bobbaers
K.U.Leuven - LUDIT -=- Tel: +32 485 52 71 50
[EMAIL PROTECTED] -=- http://people.linux-vserver.org/~harry
Nobody notices when things go right.
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
_______________________________________________
Vserver mailing list
[email protected]
http://list.linux-vserver.org/mailman/listinfo/vserver
