On Thu, 27 Jan 2011, Yves-Alexis Perez wrote: > 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.
"Removing the security bugfixes", that doesn't sound like a good roead to go. > > 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. That is a wrong look at the problem, once it's upstream everybody profits. So this looks more like a dead end road. > > 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. Hmm Openvz was once scheduled to be merged mainline and back then people were actively workin on it. We are dropping it as mainline has a very interesting alternative. Considering that SELinux is inside the kernel it be much better time investment to polish that. What makes you think that a Debian Hardened with proper SELinux wouldn't be really appreciated!? > > Third beside "security" theatre what is gained by it? > > I think the whole point of the “Grsecurity” patchset is “security”. I like the way you put it under brackets and think that security is gained by just applying this patchset. > > 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. Be more precise in what SELinux can't do for you? (Emulating NX for bad hardware doesn't count these days). > > 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. Been there and we are leaving both. Happy hacking -- maks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
