Subject: Re: [vserver] Vserver + grsec thoughts
From: "Rik Bobbaers" <rik@enzoverder.be>
Date: Mon, 8 Nov 2010 10:24:28 +0100 (CET)

> Hi
>
>> except on 1 thing: pax integrates nicely, but iirc (don't have the
>> time/tools here to check) the refcounter issues are in pax, but that's
>> just a small not very invasive patch and fairly constant across the
>> versions.
>
> Do you think you could share that patch please?  I'm keen to play with
> the latest 2.6.36 pax patches?
>
>> There isn't all that much to do when you leave out the grsecurity part
>> of
>> the patch. I already suggested in the past to drop that. But there were
>> (at that moment) people who didn't want to give up on the grsecurity
>> things.
>
> I was one of those...  :-)
>
> However, at that point I *thought* wanted the option of an RBAC and
> further I hadn't given enough thought to what bits of grsec were adding
> value to *that* setup.
>
> Certainly there are some bits I will miss such as the Kernel Auditing
> (unless I miss that this can be done some other way?) and the larger
> entropy pools is something I would probably patch manually (hidden
> kernel symbols? is this done already in vserver patches?) I think the
> rest I can live without given that the vserver containers appear to
> offer a large proportion of those same features?
>
>> But some time ago, I asked if
>> everyone was OK if i remove the option (grkernsec_chroot) completely in
>> the patch, and there were people that didn't want that, because their
>> point of view (at that moment) was: if you don't want it, don't use it.
>> If
>> you want it, you can still play with it.
>
> Again I was one of those.  However, I was approaching it more from the
> point of view that it did no harm and actually added extra protection.
> It would appear that it probably doesn't add substantial extra
> protection and in fact the "cost" of integrating the patches outweighs
> the benefits?
>
>> But as i don't have the time nor possibilities to work on the patches (I
>> work in a bank now, so it's a windows system and everything is properly
>> locked down... well... not really, but when i bypass security, the ids
>> alarms start to ring etc etc... :)).
>
> I'm not sure how ironic you are being here...  Off topic, but I for one
> am always interested to hear about good secure installs, so please share
> any interesting features of your Windows setup that does actually seem
> extra secure over a typical linux setup?
>
>> Or, maybe if someone says: no waaaaay... he can take over? ;)
>
> I'm still in the "asking" stage, but if the grsec patches *do* turn out
> to be valuable I would be interested to help maintain them.
>
> Certainly if pax alone works then I have partially offered to maintain
> some gentoo docs and a kernel tree for vserver+pax...
>
>> So yeah... it is an interesting question, but i think it's up to the
>> community to speak now ;)
>
> Come on all - speak up?  I have slightly rudely CC'd several folks who
> offered opinions on the chroot stuff in the past.  Care to comment?
>
>
>
> I think the next step is to prepare a vs+pax patch and lets kick it
> around some?  Lets see what we actually miss?  I think we will likely
> see that vs+pax is the easiest to maintain going forward?
>
> I just patched 2.6.36 with latest VS and Pax - it merges without
> conflicts and looks like it compiles - untested, but can you please mail
> over those fixes that you suspected were required?
>
> Cheers
>
> Ed W
>

Very true what you're saying all! What i was saying about being at work. I
really do work in a bank now. I HAVE to use the windows box they provide
me, so I can't install a linux (which is easier to do dev on). The network
inside the bank is very "secured", so i can't even connect to my dev box
in germany to do patch work (without triggering the intrusion detection
alarms).

But... You will run into problems with a vs+pax patch when your
refcounters overflow (iirc that's a pax feature). So there is some
patching that needs to be done on some vserver related things. I'll try to
upload a patch for that (on top of the linux + pax + vserver) patch. This
way, you can easily "make new patches" if new versions of pax or vserver
come out. (it's definately not much... but check the refcount bugs in the
mailinglist archives and you'll know what i'm talking about).

Anyway, today i have no time, maybe tomorrow, and if not: Wednesday!! :)

Grtzzz...

Rik Bobbaers

-- http://harry.enzoverder.be
linux/unix/system/network/security/hardware admin
infrastructure architect