Bug#605090: Updated patch
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
Reply to: