grsecurity can be used together with the linux-vserver patches and it's a welcome addition in a production environment. We don't currently have an ebuild to install vserver+grsec sources, it would be good to have one. I don't know if it would be better to have a new ebuild or add a USE flag to sys-kernel/vserver-sources. The latest unified patch with vserver+grsec is always available at the linux-vserver homepage. I'm currently running 2.6.22.19-grsec2.1.11-vs2.2.0.7 on hppa.
hardened, please un-cc youself if you aren't interested.
the vserver herd (that means me) is not interested in maintaining a grsec+vserver ebuild, since i have no use for the hardened crap
in a real nice way... FU get me off this damn CC: list. Insulting another mans hard work for no reason is pretty god damn fucking rude.
hu? IMO hardened is useless, that doesn't stop you from maintaining a grsec+vserver ebuild
(In reply to comment #4) > hu? IMO hardened is useless, that doesn't stop you from maintaining a > grsec+vserver ebuild I respectfully disagree. When everyone without a Hardened kernel was running around going "zOMG!" over the vmsplice() issue, I just laughed as grSecurity+PaX killed any such attempts to escalate privileges on my system. @ Luca: If you come up with an ebuild it'll have a better chance of living, through something like Sunrise you can upload/maintain it yourself? Seeing as Benedikt is taking a "Not in my sandbox" attitude I think it's fairly safe to close this one as WONTFIX.
(In reply to comment #5) > @ Luca: If you come up with an ebuild it'll have a better chance of living, > through something like Sunrise you can upload/maintain it yourself? > > Seeing as Benedikt is taking a "Not in my sandbox" attitude I think it's fairly > safe to close this one as WONTFIX. Well yeah I will try to make an ebuild myself since there seem to be some, uh, problems between current herd and the proposed piece of software. Speaking of the 'crap', I'm not such an expert by afaik vserver is based on chroots and there already are a lot of known methods to break out of them - I don't really know if this is applicable to vserver chroots, though. AFAIK it shouldn't be that difficult (the patch is already made & maintained by the vserver-linux.org people). You other people think it would be best a new ebuild or a 'hardened' flag to the current one? I would choose the former since the version name would change, but just asking...
(In reply to comment #6) > AFAIK it shouldn't be that difficult (the patch is already made & maintained by > the vserver-linux.org people). You other people think it would be best a new > ebuild or a 'hardened' flag to the current one? I would choose the former since > the version name would change, but just asking... Better create new ebuild. After you do it, try to commit it to sunrise, bug in any case reopen this bug after that with a link to that ebuild. This bug should not be closed but assigned to maintainer-wanted IMO.
well, i'm not much of an grsec expert, but it has failed on me and other hardened stuff (ssp & friends) too, so i have given up on hardened stuff for quite a while ... it may be better these days, and i'm aware that a grsec rediff is actively maintained, but i'm simply not interested in maintaining any hardened related ebuild
(In reply to comment #8) > well, i'm not much of an grsec expert, but it has failed on me and other > hardened stuff (ssp & friends) too, so i have given up on hardened stuff for > quite a while ... it may be better these days, and i'm aware that a grsec > rediff is actively maintained, but i'm simply not interested in maintaining any > hardened related ebuild The key point to note here is that we're not talking about an ebuild for a grsec *kernel*, but for the *kernel source*. Getting a working kernel from that source is not a portage problem, we just need to get the source correctly installed in /usr/src/linux-$VERSION.
just a fresh report. I'm still running 2.6.22.19-grsec2.1.11-vs2.2.0.7 with uninterrupted uptime since May 2008, with grsec enabled and vservers running (various other patches needed in userland components, start from #221951 and follow links) I do not have an ebuild for it since I still hadn't time to look into learning how to correctly manage version numbers (can't copy from another ebuild since we have a more complex versioning here). Still any help from someone able to write the ebuild would be appreciated, I would take care of submitting it and testing as far as I can.
dont mess with "how to grsec works" just add "hardened" to IUSE and apply vserver patch depending on it
I'm another gentoo user with manually installed vServer+grsec. Is there any reason we can't automatically include arch-masked releases from harry's site (vserver+grsec rediff maintainer)? I'm happy to write a script to generate the ebuilds if they will actually be added to portage, in the past most ebuilds seem to have sat on the tracker forever and I am now discouraged from bothering.
(In reply to comment #12) > I'm another gentoo user with manually installed vServer+grsec. > > Is there any reason we can't automatically include arch-masked releases from > harry's site (vserver+grsec rediff maintainer)? > > I'm happy to write a script to generate the ebuilds if they will actually be > added to portage, in the past most ebuilds seem to have sat on the tracker > forever and I am now discouraged from bothering. Okay, I must be crazy but ... I'll consider maintaining this since I do hardened-sources. I will need help from the community with the vserver side. Send me any material that already exists. I will test/stage it on my overlay and then put it on the tree.
The material basically consists of the patch sets released by the linux-vserver.org people - they already take care of integrating both linux-vserver and grsecurity. New releases get published in the table on the homepage ( http://linux-vserver.org/ ) and consists of a single diff file against a vanilla kernel tree.
removed
