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
[EMAIL PROTECTED]
http://list.linux-vserver.org/mailman/listinfo/vserver
