On mer., 2011-02-09 at 18:51 +0100, maximilian attems wrote: > > 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. Well, I'm only removing them from the Grsecurity patch because they're already included in the Debian packaging... > > > > > 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 agree that upstreaming is better but I still think it's useful to have a featureset in the meantime (and I think people are interested in that). > 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. Again, I'm all in favor of dropping it when mainline has a viable alternative. But it's not currently the case. > > 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!? I'm sure a Debian Hardened with SELinux would be really appreciated. > > Be more precise in what SELinux can't do for you? > (Emulating NX for bad hardware doesn't count these days). Again, SELinux is about access control policies, in order to reduce propagation when a process is compromised. It's not about hardening the kernel and userland to prevent this compromission. At most you could compare it with the RBAC part of Grsecurity, but there's also the chroot protection one, the PaX memory protections, auditing and the various hardening features which you can find on the website. Thanks for your comments. -- Yves-Alexis Perez ANSSI/ACE/LAM
Attachment:
signature.asc
Description: This is a digitally signed message part