Re: [Xen-users] patch for vanilla kernel

["Valter Douglas LisbÃa Jr." <douglas@xxxxxxxxxxxxx>]

On Tuesday 26 February 2008 16:54:42 Tom Brown wrote:
> On Tue, 26 Feb 2008, Tom Brown wrote:
> > On Tue, 26 Feb 2008, Pasi KÃrkkÃinen wrote:
> >
> > I can not agree with that. If you're messing around on your desktop
> > machine, ok... you've already got root and you are the only user...
> > security patches aren't important in that scenario ... but if you're
> > providing real services to real users, and you don't want some script
> > kiddie wiping out your box starting from a PHP or SQL injection exploit,
> > then you need to be using kernels that aren't 18 months out of date.
Humm... SQL Injections don't has any issue with kernels and the PHP fails 
normally runs with low level privileges on system, it could... but it's not 
likely to hit the kernel without huge efforts.

But I think the worst thing here is not a security problem, even 2.6.18 had 
security patches for the recent fails (all locals like you said bellow). I 
believe the linux kernel is very solid in security.

The most complex thing in stay in a too old version is lack of some usefull 
(or necessary) resource only present in a more new version like the new 
wireless drivers, new netfilter capabilities, etc. I have a issue with a 
driver for Marvell IDE with the 2.6.18. Luck me a workaround with the generic 
IDE save my life, but remember that not always we have this stuffs on hand. 
even in a desktop you will find this issues.

Another problem is patch the kernel with more than one "no offcial" 
modification like RSBAC, GRSecurity, maybe ReiseFS4 or other stuffs like, 
because them conflicts for alter the same files. The PaX patch for example 
give me so headaches with Xen and I abandon the ideia. To many *RE*code for 
me yet. If the Xen is part of vanilla, the other unofficials will do patchs 
considering it by default. This is more likely to happen in a server.

The older nVidia proprietary driver hangs the X.org up because it wasn't "xen 
aware" (i believe that there is others issues actually). Of course this is 
not a kernel bug, it's a nVidia driver problem. But if the official kernel 
could had the Xen, this things won't occour anymore, because problably, the 
nVidia driver makers will test it in a vanilla kernel at best, but with 
native Xen inside it. ;-)

I dislikes the patches for OpenSuse, fedora and others because its not very 
tested like the official 2.6.18, and I use Xen in production! The lack of a 
complete and centralized documentation turn it very hard to undestand the Xen 
without some deep hacking, even "only do it function" can be trickery. So I 
don't need a less tested, no official patch that come in newer versions to 
complicate it more. 

Last, if you have hvm (Have you more cash to expend? :-) ) you can export some 
PCI bus to the VM and use a very recent kernel there to deal with the 
hardware, or try the 2.6.2[34].x with domU in Para VIrtualization. This could 
bring some useful things in hand to manipulate some of the issues I talked, 
but not all. 

In the dom0, I suggest to stay in 2.6.18.x for now.

> Sorry, even that isn't very well written... Most linux security patches
> are for local exploits (priveledge escalation), and these aren't very
> relevent if you are the only user and you already have root :)
>
> I'm not aware of any recent remote exploits against the linux kernel. If
> there were then the above generalization is out to lunch.
>
> -Tom
Very old times, I remembered of tear drops, and some floods TCP techniques 
capable to hangs the kernel :-). If my memory is not wrong some netfilter 
code has failed to manipulate some TCP/IP headers and could be exploited. 

And again, recently the most recent remote exploits targets user space high 
level protocols or exploiting bad writed web application not the kernel.

Douglas

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users