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
|
Home