On 18/05/11 12:10, Ed W wrote:
> On 14/05/2011 09:01, Sandino Araico Sánchez wrote:
>> After the refcount fix (thanks Rik for your advice) I have the new
>> kernel running for more than 23 hours with no visible failure.
>>
>> The vserver patch against a grsec-patched kernel:
>> http://sandino.araico.net/parches/vserver/patch-2.6.38.4-vs2.3.0.37-rc15-against-grsec-2.2.2-201104232142-KB2-unstable.diff
>>
>> The combined patch against 2.6.38.4 vanilla:
>> http://sandino.araico.net/parches/vserver/patch-2.6.38.4-vs2.3.0.37-rc15-grsec-2.2.2-201104232142-KB2-unstable.diff
> Superb
>
> Do also consider if you need the extra stuff in grsec or just the pax
> part? I'm moving quickly to the opinion that pax is the main useful
> thing on a vserver based server (assuming little/nothing running the
> host). Herbert suggests that most of the chroot restrictions are
> already taken care of by vserver code?
>
> Cheers
>
> Ed W
>
Redundant chroot restrictions is something might be worth looking at
deeper, but It doesn't cost too much restricting the same thing twice.
Disabling redundant grsec restrictions from the config should be enough
to avoid redundant code to be compiled in.
There are some other useful restrictions I have been using like TPE, and
network access and some host administrators might like to have some
other restrictions disabled like chroot_deny_mount or chroot_deny_mknod
to be combined with cgroup_devices.
The first restriction I need to fix is the missing file /proc/self/io in
context 1 because it breaks vcontext --migrate --xid 1 -- iotop.
I don't have much time but Rik's refcount patches have been working fine
(and stable) and the rest of the patch-combining is easy so I might be
sending the combined patch as often as I can.
-- Sandino Araico Sánchez http://sandino.netReceived on Wed May 18 23:15:48 2011