Web lists-archives.com

Re: Kernel for Spectre and Meltdown




On Tuesday 30 January 2018 08:22:18 Greg Wooledge wrote:

> On Tue, Jan 30, 2018 at 12:13:47PM +0100, Michael Lange wrote:
> > Michael Fothergill <michael.fothergill@xxxxxxxxx> wrote:
> > > The response from Greg was the following:
> > >
> > > On Thu, Jan 25, 2018 at 12:36:46PM +0000, Michael Fothergill wrote:
> > > > ​If I become sid and install the kernel correctly, could I go
> > > > back to
> > >
> > > being
> > >
> > > > just buster (sounds like an energy drink) and carry on using the
> > > > new
> > >
> > > kernel?
> > >
> > > No.
> > >
> > > *******************
> > >
> > > At that point I really did seem that:
> > >
> > > 1. I had no choice but to become sid/unstable here.
> >
> > I can only guess of course, I think probably they figured you would
> > upgrade your system to Sid, then compile a kernel and then
> > *downgrade* the system again to buster. The answer to that would
> > clearly be "no". But running a kernel compiled on a *different* Sid
> > system on buster or stretch is an entirely different thing of
> > course.
>
> Yes, that's correct.  If you actually "become sid" (upgrade your whole
> system to sid), there is no going back.
>
> But you can set up a *separate* system (either an entirely new box,
> or a chroot into which you debootstrap sid, or a virtual machine, or a
> container, or whatever other fancy thing the kids are using these
> days), build a kernel .deb package there, *copy* that package to your
> buster system, and install it.
>
> Or you can do what most of us are doing: wait for the Debian security
> team (and, really, for the entire *world*) to figure out how best to
> approach, mitigate, and/or solve the issues.
>
> Meanwhile, I would recommend not letting random people get shell
> access to your critical systems.  Near as I can tell, exploiting a
> Spectre-type CPU vulnerability requires the ability to install and
> execute a program of the attacker's creation on the target system.  If
> you don't have users logging in and running commands, then you
> probably don't have to worry so much about this.  Unless I'm
> completely missing something.
>
> (If you have users issuing commands on your system through some other
> vector, like a PHP web-app exploit, then that's a bigger issue you
> should address directly.)

Running apache2 to serve up my web page, see sig, apache2 doesn't have 
access to a lot of its plugins, file browsing and pulling is all thats 
allowed, and thats only done via a NAT rule in dd-wrt to direct that 
port number only to this machine, should I be worried?

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>