About this list Date view Thread view Subject view Author view Attachment view

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
>not trivial.
>
>
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
don't overlap.

>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
else.

> 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
some time.

> ...
> ...
> 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
>thingy.
>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


About this list Date view Thread view Subject view Author view Attachment view
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Thu 10 Jun 2004 - 08:55:49 BST by hypermail 2.1.3