From: Sandino Araico Sánchez (sandino_at_sandino.net)
Date: Thu 10 Jun 2004 - 08:55:27 BST
Dariush Pietrzak wrote:
>>The current vserver+grsecurity is working perfectly well for me on my
>>systems. I've been using Sandino Araico Sanchez's vserver+grsec patch and
>>they've been stable as a rock.
> That's good for you.
>And if you believe this is ideal recommendation then I've got this
>wonderfully cheap bridge for sale, it's a real bargain...
> To reiterate what I and few other people already said - it's not enough to
>just integrate two conflicting patches and call it a day - vserver+grsec is
The only side-effect I have seen in merging both patches is the ACL
dropping CAP_SYSADMIN problem. Other than that there's no overlap and
features of both patches have worked as expected on production servers.
>Until someone comes up and commits to maintaining vrsec;) vserver+grsec
>does not exist.
Of course it does not exist, they are two different patches from two
different non-overlapping projects. It's just a cummulative patch set
like any other.
>All that exist is a bunch of amateur merges of
>vserver&grsec ... I made those.. few other people made those... but AFAIK
>noone with intimate understanding of both projects.
That's right, it takes me about 1 hour to merge the rejects of both
patches in the right places; there's no big science on it. I just upload
the combined patch in the case it may be useful for someone else.
> So there are two main challanges - 1) merging (with understanding and
>documenting what are you doing, for example, resolving chroot restrictions
>can be made in multitude of ways,
There are no chroot restrictions other than chroot inside chroot but
It's solved in GR Security 2. There's just the need of somebody taking 1
hour of his time for doing the merge of vserver and grsec 2 patches.
> grsec on top of vserver, vserver on top
>of grsec, grsec instead of vserver, vserver instead of grsec etc...etc...
>And this is probably the most trivial part)
This one on top of the other is a non-existent issue since both patches
>2) commiting to maintaining this product... accepting bugreports, updating,
>communicating with both vserver and grsec teams ( for example, securing
>chroot properly for vserver+grsec should result in modifications that could
>go to both those projects ).
I wish I had enough time for all that work but I don't. Perhaps somebody
> The way it is now it looks like this:
> "Hi, i downloaded grsec+vserver and now I've got this problem...
I've just added the ACL issue to the Wiki page. Hope that's enough for
> Oh wait, my kernel is oopsing like crazy".
>So, I think that the best way to resolve this whole mess goes like this:
>1) grsec sponsors get their acts together (probably fear of bad publicity
>may help here...),
>2) bunch of different developers gets interested in grsec, and one of those
>decides to take responsibility for maintaining this whole magical vrsec
>3) in the process of accomodating new developers grsec splits into modules
>(like in the early days of security enhancing patches) with different devs
>taking care of different modules.
-- Sandino Araico Sánchez -- ... there's no spoon ... _______________________________________________ Vserver mailing list Vserver_at_list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver