On jeu., 2011-01-27 at 00:29 +0100, maximilian attems wrote: > On Tue, 18 Jan 2011, Yves-Alexis Perez wrote: > > > > > Kernel team, what do you think? Could the patches be merged against > > trunk? Config might still need some reviewing but that can be done once > > people start testing the packages. > > What follows is my personal view, in short what I miss most is an > assessement of the involved cost of this specific "feature" branch.
I follow both 2.6.32 (“stable”) and 2.6.36 then 2.6.37 (“test”) releases since few weeks, integrating them to the linux-2.6 (sid and trunk) source packages. There's an rss feed with a changelog which I use to see what changed and apply the debian diff (which is about removing the “localpart” in 2.6.37 and removing the security bugfixes in 2.6.32). Right now I'm doing it manually (applying against a tree after debian/rules source and fixing the rej) and intend to switch to git when the migration is done. For 2.6.37 it's immediate, for 2.6.32 it's a bit longer since I need to do the removal part. Then there is the testing. Nothing really specific there. > > first of all merging a patch that deviates from mainline for an > eternety and shows zero interest of upstream merging is not a > good candidate. You get longterm plenty of cost versus allmost > no benefit. There's no interest in upstreaming from grsec/pax teams but some other people are indeed interested in upstreaming those kind of features. In the meantime, having a featureset is a nice way to move along. > I'm quite unsure that this patch benefits Debian. A lot of Debian users build their own kernels for integrating grsecurity patch and I really think they would be interested in having it directly in the distribution. Though it's not exactly the same situation (especially wrt. the config) I think Gentoo Hardened kernel is really appreciated. Professional as well a personal people do use it daily because it's critical in their work. If we can provide them a package I think they'll be grateful. > From a distant past look it was in fact quite untastefull. > > The second trouble is that I question your understanding of this patch. > (viewing the way you answered waldi's questions). Indeed there are parts in that patch I wouldn't be able to explain precisely, especially very low-level stuff, linker, sparc64 assembly... > > Third beside "security" theatre what is gained by it? I think the whole point of the “Grsecurity” patchset is “security”. > > Fourth why not invest the time for Wheezy and have finally the mainline > and security backed SELinux ready. This seems like a much better time > investment. Trying to push some bits upstream is indeed a good time investment (though it takes time and I really think moving forward now is a good idea). But Grsecurity isn't a drop-in replacement for SELinux. Some features like RBAC and auditing have some similarities, but all the hardening and memory protection really have nothing to do with that. > > Fifth the ninties are over, an upstream that still doesn't use an VSC > seems very untrustworthy. I didn't say anything about upstream VCS usage. Indeed it'd be nice to have a repository available for users and I'm sure openvz and vserver patchsets maintainers would agree. Thank you for your comments anyway. Regards, -- Yves-Alexis Perez ANSSI/ACE/LAM
signature.asc
Description: This is a digitally signed message part
