On Tue, Sep 27, 2011 at 07:17:15PM +0100, Ed W wrote:
> Hi
> On 15/09/2011 08:11, ccx@webprojekty.cz wrote:
>
>> Grsec is much more than RBAC, features I'd highlight are:
>> * Kernel auditing: reporting of all segfaults, limit
>> oversteps, etc.
> This is definitely something worth trying to keep, I agree. I
> mentioned this additional in my prev email actually.
> Perhaps this feature is actually something that Herbert would
> consider maintaining in vserver if the changes were pulled out
> of grsec, since it's fairly intimitely related?
a broken out patch or even better patches similar to the
deltas and/or stable release breakdowns would allow to
discuss this in more detail ...
> Or perhaps Herbert has some suggestion on how to achieve a
> similar effect? Note there are some subtle merge conflicts in
> this section of the code - see Rik's previous emails on merging
>> * Adress space protection: remove all the userspace access to
>> low-level stuff that could compromise the system.
> You are probably right, but could you define which things you
> feel are missing from the vserver patch?
yep, let's hear what is missing, if possible, attach
a patch or description what grsec checks there ...
> Probably Herbert would chime in as to whether they are
> covered or not by the additional protections due to the vserver
> patches? ie some stuff is already covered here
>> * Proc restrictions: users only able to inspect their own
>> processes, this is really handy for a shell server.
> I see your point.
> I wonder if these could be achieved some other way, or again
> whether the changes are small enough that they could be pulled
> out and maintained separately?
basically we have the "hide process" framework already
for the guest isolation, so an additional, configureable
(i.e. can be disabled with zero cost) kernel option
doesn't sound like a big deal to me ... could even be
on a per guest basis :)
> There is some noise recently on the kernel mailing list about
> being able to set more restrictions here?
>> * /tmp race protection for symlinks and fifo.
> Again you might be right, but can you highlight which feature
> you mean here? I think this might already be covered by the
> vserver patches?
unlikely, but let's hear what the change/patch/feature
is in more detail first ...
best,
Herbert
> Regards
> Ed W
Received on Wed Sep 28 00:04:04 2011