Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.os.linux > #39269 > unrolled thread

"Linux kernel security needs a rethink" ?

Back to article view | Back to alt.os.linux

Contents

  "Linux kernel security needs a rethink" ? Yrrah <Yrrah-aol@aol.invalid> - 2016-09-27 16:28 +0200
    Re: "Linux kernel security needs a rethink" ? jrg <connyank@cox.net> - 2016-09-27 08:25 -0700
    Re: "Linux kernel security needs a rethink" ? Mike Easter <MikeE@ster.invalid> - 2016-09-27 08:43 -0700
      Re: "Linux kernel security needs a rethink" ? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-09-27 15:51 +0000
        Re: "Linux kernel security needs a rethink" ? Mike Easter <MikeE@ster.invalid> - 2016-09-27 09:03 -0700
          Re: "Linux kernel security needs a rethink" ? "J.O. Aho" <user@example.net> - 2016-09-27 18:26 +0200
          Re: "Linux kernel security needs a rethink" ? Mike Easter <MikeE@ster.invalid> - 2016-09-27 09:35 -0700
            Re: "Linux kernel security needs a rethink" ? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-09-27 16:43 +0000
              Re: "Linux kernel security needs a rethink" ? Bud Frede <frede@mouse-potato.com> - 2016-09-28 06:59 -0400
          Re: "Linux kernel security needs a rethink" ? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-09-27 16:42 +0000
            Re: "Linux kernel security needs a rethink" ? Peter Köhlmann <peter-koehlmann@t-online.de> - 2016-09-27 18:53 +0200
              Re: "Linux kernel security needs a rethink" ? stepore <linshine@here.now> - 2016-09-27 21:07 -0700
                Re: "Linux kernel security needs a rethink" ? Bud Frede <frede@mouse-potato.com> - 2016-09-28 07:36 -0400
              Re: "Linux kernel security needs a rethink" ? William Unruh <unruh@invalid.ca> - 2016-09-28 10:28 +0000
          Re: "Linux kernel security needs a rethink" ? Dan Purgert <dan@djph.net> - 2016-09-28 10:55 +0000
      Re: "Linux kernel security needs a rethink" ? Mike Easter <MikeE@ster.invalid> - 2016-09-27 08:53 -0700
        Re: "Linux kernel security needs a rethink" ? Chris Ahlstrom <OFeem1987@teleworm.us> - 2016-09-27 12:39 -0400
      Re: "Linux kernel security needs a rethink" ? Bud Frede <frede@mouse-potato.com> - 2016-09-28 06:56 -0400

#39269 — "Linux kernel security needs a rethink" ?

"The Linux kernel today faces an unprecedented safety crisis. Much
like when Ralph Nader famously told the American public that their
cars were 'unsafe at any speed' back in 1965, numerous security
developers told the 2016 Linux Security Summit in Toronto that the
operating system needs a total rethink to keep it fit for purpose.
No longer the niche concern of years past, Linux today underpins the
server farms that run the cloud, more than a billion Android phones,
and not to mention the coming tsunami of grossly insecure devices that
will be hitched to the Internet of Things. Today's world runs on
Linux, and the security of its kernel is a single point of failure
that will affect the safety and well-being of almost every human being
on the planet in one way or another.(...)
Article: 
<http://arstechnica.com/security/2016/09/linux-kernel-security-needs-fixing/>

And now explained to the unitiated? ;-)

Yrrah

[toc] | [next] | [standalone]

#39271

On 09/27/2016 07:28 AM, Yrrah wrote:

> And now explained to the unitiated?

While it is good to discuss these things out in the open, nothing has 
really changed - the model is the same.  Security breeches have happened 
and will happen in the future.  Open source support can crank out 
patches fairly quickly and can patch things no one knew were vulnerable. 
  Ars Technica is doing its due diligence making the world aware but it 
is really waving a bloody shirt , sorta like the windoze trolls do 
around here all the time.

http://www.linuxsecurity.com/content/view/117268/

[toc] | [prev] | [next] | [standalone]

#39272

Yrrah wrote:
> And now explained to the unitiated? ;-)

Drivers in the kernel is a HUGE problem.

Where is the Tanenbaum crowd when we need them?

http://www.cs.vu.nl/~ast/reliable-os/  Tanenbaum-Torvalds Debate: Part 
II - (2006 May)

-- 
Mike Easter

[toc] | [prev] | [next] | [standalone]

#39274

On 2016-09-27, Mike Easter <MikeE@ster.invalid> wrote:
> Yrrah wrote:
>> And now explained to the unitiated? ;-)
>
> Drivers in the kernel is a HUGE problem.

What does this means?

>
> Where is the Tanenbaum crowd when we need them?
>
> http://www.cs.vu.nl/~ast/reliable-os/  Tanenbaum-Torvalds Debate: Part 
> II - (2006 May)
>
Microkernel lost it's attraction as it is slow. What we have today are
actually hybrids...

-- 
press any key to continue or any other to quit

[toc] | [prev] | [next] | [standalone]

#39276

Melzzzzz wrote:
> Mike Easter wrote:
>> Yrrah wrote:
>>> And now explained to the unitiated? ;-)
>>
>> Drivers in the kernel is a HUGE problem.
>
> What does this means?

The presentation covered by Ars doesn't provide any direction to a solution.

>> Where is the Tanenbaum crowd when we need them?
>>
>> http://www.cs.vu.nl/~ast/reliable-os/  Tanenbaum-Torvalds Debate: Part
>> II - (2006 May)
>>
> Microkernel lost it's attraction as it is slow. What we have today are
> actually hybrids...

Dangerous LKM modules.

Even with all of the loadable modules unloaded, the monolithic kernel is 
'vast', not really resembling anything like a 'self-healing' micro or 
nano kernel used for some secure purposes.

The DoD sez; "The TCB shall [implement] complete, conceptually simple 
protection mechanisms with precisely defined semantics. Significant 
system engineering shall be directed toward minimizing the complexity of 
the TCB, as well as excluding from the TCB those modules that are not 
protection-critical."

... where TCB = trusted computing base which of course includes/is the 
kernel and whatever danger is hidden inside.



-- 
Mike Easter

[toc] | [prev] | [next] | [standalone]

#39278

On 09/27/2016 06:03 PM, Mike Easter wrote:
> Melzzzzz wrote:
>> Mike Easter wrote:

>> Microkernel lost it's attraction as it is slow. What we have today are
>> actually hybrids...
> 
> Dangerous LKM modules.
> 
> Even with all of the loadable modules unloaded, the monolithic kernel is
> 'vast', not really resembling anything like a 'self-healing' micro or
> nano kernel used for some secure purposes.

There is GNU/Hurd, just extremely slow progress on the kernel development.

-- 

 //Aho

[toc] | [prev] | [next] | [standalone]

#39280

Mike Easter wrote:
> The presentation covered by Ars doesn't provide any direction to a
> solution.

Maybe google's microkernel Fuchsia can be evolved into a 
security-oriented OS.

Little Kernel > Magenta > Fuchsia > ?

http://www.tomshardware.com/news/google-fuchsia-new-operating-system,32475.html 
  Google Is Building A New Operating System From Scratch: 'Fuchsia'

-- 
Mike Easter

[toc] | [prev] | [next] | [standalone]

#39282

On 2016-09-27, Mike Easter <MikeE@ster.invalid> wrote:
> Mike Easter wrote:
>> The presentation covered by Ars doesn't provide any direction to a
>> solution.
>
> Maybe google's microkernel Fuchsia can be evolved into a 
> security-oriented OS.
>
> Little Kernel > Magenta > Fuchsia > ?
>
> http://www.tomshardware.com/news/google-fuchsia-new-operating-system,32475.html 
>   Google Is Building A New Operating System From Scratch: 'Fuchsia'
>
I looked at that ;)
It's just toy project as it seems.

-- 
press any key to continue or any other to quit

[toc] | [prev] | [next] | [standalone]

#39309

Melzzzzz <Melzzzzz@zzzzz.com> writes:

> On 2016-09-27, Mike Easter <MikeE@ster.invalid> wrote:
>> Mike Easter wrote:
>>> The presentation covered by Ars doesn't provide any direction to a
>>> solution.
>>
>> Maybe google's microkernel Fuchsia can be evolved into a 
>> security-oriented OS.
>>
>> Little Kernel > Magenta > Fuchsia > ?
>>
>> http://www.tomshardware.com/news/google-fuchsia-new-operating-system,32475.html 
>>   Google Is Building A New Operating System From Scratch: 'Fuchsia'
>>
> I looked at that ;)
> It's just toy project as it seems.

The Linux kernel was just a toy at one time too. :-)

Actually, if you want a security-oriented OS, Qubes OS incorporates some
really good ideas. https://www.qubes-os.org/

I saw an article not too long ago that said one company is working on a
similar concept. I'm thinking it was VMWare, but I won't swear to it.

[toc] | [prev] | [next] | [standalone]

#39281

On 2016-09-27, Mike Easter <MikeE@ster.invalid> wrote:
>>>
>>> http://www.cs.vu.nl/~ast/reliable-os/  Tanenbaum-Torvalds Debate: Part
>>> II - (2006 May)
>>>
>> Microkernel lost it's attraction as it is slow. What we have today are
>> actually hybrids...
>
> Dangerous LKM modules.

What is dangerous about them?

>
> Even with all of the loadable modules unloaded, the monolithic kernel is 
> 'vast', not really resembling anything like a 'self-healing' micro or 
> nano kernel used for some secure purposes.

As long as there is no software on Linux that requires reboot after
installation we are in good shape ;)


-- 
press any key to continue or any other to quit

[toc] | [prev] | [next] | [standalone]

#39284

Melzzzzz wrote:

> On 2016-09-27, Mike Easter <MikeE@ster.invalid> wrote:
>>>>
>>>> http://www.cs.vu.nl/~ast/reliable-os/  Tanenbaum-Torvalds Debate: Part
>>>> II - (2006 May)
>>>>
>>> Microkernel lost it's attraction as it is slow. What we have today are
>>> actually hybrids...
>>
>> Dangerous LKM modules.
> 
> What is dangerous about them?
 
Nothing. Kernel modules can access kernel structures. Call the press!

>> Even with all of the loadable modules unloaded, the monolithic kernel is
>> 'vast', not really resembling anything like a 'self-healing' micro or
>> nano kernel used for some secure purposes.

There are no µ-kernels around which have anywhere near the functionality of 
the linux kernel

And what is this bullshit about 'self-healing'?
Any kernel, be it µ-kernel or a monolithic one have about the same lines of 
code if they have the same functionality. And that includes the same number 
of possibilities to screw up

> As long as there is no software on Linux that requires reboot after
> installation we are in good shape ;)
> 

Well, the other "choices" to linux are foremost windows and OSX.

Windows is inherently insecure, and OSX is shitty beyond belief. Both are 
also slow, OSX even extremely slow compared to linux

[toc] | [prev] | [next] | [standalone]

#39302

On 09/27/2016 09:53 AM, Peter Köhlmann wrote:
> Windows is inherently insecure, and OSX is shitty beyond belief.

Nope; I _believe_ it!
;)

[toc] | [prev] | [next] | [standalone]

#39311

stepore <linshine@here.now> writes:

> On 09/27/2016 09:53 AM, Peter Köhlmann wrote:
>> Windows is inherently insecure, and OSX is shitty beyond belief.
>
> Nope; I _believe_ it!
> ;)

I suspect that the original Windows kernel was secure, but then Cutler
and his team turned it over to the Microsofties and they screwed the
pooch.

NeXTSTEP was a pretty decent OS in many ways. Apple screwed some things
up, but OS X is still better than Windows. At this point, if I couldn't
run Linux or one of the *BSDs, I'd buy a Mac.

[toc] | [prev] | [next] | [standalone]

#39304

On 2016-09-27, Peter K??hlmann <peter-koehlmann@t-online.de> wrote:
> Melzzzzz wrote:
>
>> On 2016-09-27, Mike Easter <MikeE@ster.invalid> wrote:
>>>>>
>>>>> http://www.cs.vu.nl/~ast/reliable-os/  Tanenbaum-Torvalds Debate: Part
>>>>> II - (2006 May)
>>>>>
>>>> Microkernel lost it's attraction as it is slow. What we have today are
>>>> actually hybrids...
>>>
>>> Dangerous LKM modules.
>> 
>> What is dangerous about them?
>  
> Nothing. Kernel modules can access kernel structures. Call the press!

And that in the wrong or incompetent hands can be very dangerous. You
have some 2 bit company writing a driver for their toaster but having a
huge bug which allows someone to write to any location in the kernel. 
>
>>> Even with all of the loadable modules unloaded, the monolithic kernel is
>>> 'vast', not really resembling anything like a 'self-healing' micro or
>>> nano kernel used for some secure purposes.
>
> There are no ??-kernels around which have anywhere near the functionality of 
> the linux kernel

And functionality is often the enemy of security. 

>
> And what is this bullshit about 'self-healing'?
> Any kernel, be it ??-kernel or a monolithic one have about the same lines of 
> code if they have the same functionality. And that includes the same number 
> of possibilities to screw up

Well, no. If you KISS, you can actually debug it and understand the
corner cases. In a huge kernel you cannot-- far too much interaction.


>
>> As long as there is no software on Linux that requires reboot after
>> installation we are in good shape ;)
>> 
>
> Well, the other "choices" to linux are foremost windows and OSX.
>
> Windows is inherently insecure, and OSX is shitty beyond belief. Both are 
> also slow, OSX even extremely slow compared to linux

The article is about security not speed not functionality, not sexiness
of the name or mascot, and not Friday's dinner. 
Now, it is probably true that OSx say is also insecure, and both slow
and insecure is not an advantage.
But the question is not " is linux more secure than Windows" That is
setting the bar far far too low. It is "HOw secure is Linux in a world
of the Internet of things" and how can it be made more secure. You do
not want your toaster letting someone know about your taxes, or being
able to be switched on forever, and burning down your house, because
some kid in Afghanistan thinks it would be fun.

[toc] | [prev] | [next] | [standalone]

#39307

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Mike Easter wrote:
> Melzzzzz wrote:
>>> Yrrah wrote:
>>>> And now explained to the unitiated? ;-)
>>>
>>> Drivers in the kernel is a HUGE problem.
>>
>> What does this means?
>
> Dangerous LKM modules.
>
> Even with all of the loadable modules unloaded, the monolithic kernel is 
> 'vast', not really resembling anything like a 'self-healing' micro or 
> nano kernel used for some secure purposes.
>
> The DoD sez; "The TCB shall [implement] complete, conceptually simple 
> protection mechanisms with precisely defined semantics. [...]
> ... where TCB = trusted computing base which of course includes/is the 
> kernel and whatever danger is hidden inside.

(Hopefully I get the quoting right)

This is all well and good, but also kind of relies on using known
hardware / being able to compile for one specific CPU / SoC.  Out here
in the real world (i.e. general business), we don't have that luxury,
and, in the most part "have to" use the generic kernels.

Sure, there's nothing stopping one from compiling the kernel for their
specific server ... but that would fall over as soon as you needed to
change / upgrade the hardware (e.g. replace a faulty NIC).

What I think we'll start seeing, at least for this type of "secured
computing" in the general populace is probably something more along the
lines of a hardened hypervisor OS (e.g. it'll only run on [insert mfg
here] blades, and incorporates these TCB ideals), but then presents
"generic" hardware that a "less secure" / generic kernel can deal with,
for the sake of usability / simplicity[*].


* In other words, so "Dave" in Bangalore can support it, after Steve in
  Texas has been "downsized" because 
  | "fuck you, we can get 15 people from this outsourcing company for your
  |  salary."
  |        - Beancounters 
  

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJX66E+AAoJEI4R3fMSeaKBahAH/ROVlJh+0TB79RtOdofgK9EU
xbNvqokCiu+87YmU4A7uVaGbJcL7g1XPhK2pdhE6pZwMM/CLRVzZgw2Q4Y2dVQnR
vTU/gtCyI34y4/0cnt2xn2uIXeWWNV6eZbmoMjc/5dEBys2wwBQ6rCMVKWiBpTyx
4wZoHjxTYCcE4jV/F9MlzDTxQhkTK/U7d6LZt7HWTLuQgOH8hZRQP0FKpkAIznhD
h75+eBn863Y4g76jtg7OxFo0buRwXS0nAl14HLXPfaTk71JNt7yaNjkXsnJfKCUh
vb24Au/iZlYUyMR3BPp5q51p2wWl37579k12rjDQPwD9K5j1Uln0Ga4RdRQoeWc=
=FHVG
-----END PGP SIGNATURE-----

-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

[toc] | [prev] | [next] | [standalone]

#39275

Mike Easter wrote:
> Yrrah wrote:
>> And now explained to the unitiated? ;-)
>
> Drivers in the kernel is a HUGE problem.

So far, for quick reading, I recommend the wp articles on microkernels 
and loadable kernel modules.

"LKMs effectively become part of the running kernel, so can corrupt 
kernel data structures and produce bugs that may not be able to be 
investigated if the module is indeed proprietary."


-- 
Mike Easter

[toc] | [prev] | [next] | [standalone]

#39283

Mike Easter wrote this copyrighted missive and expects royalties:

> Mike Easter wrote:
>> Yrrah wrote:
>>> And now explained to the unitiated? ;-)
>>
>> Drivers in the kernel is a HUGE problem.
>
> So far, for quick reading, I recommend the wp articles on microkernels 
> and loadable kernel modules.
>
> "LKMs effectively become part of the running kernel, so can corrupt 
> kernel data structures and produce bugs that may not be able to be 
> investigated if the module is indeed proprietary."

You mean a *tainted* module can be loaded!?!?!

  :-)

-- 
In India, "cold weather" is merely a conventional phrase and has come into
use through the necessity of having some way to distinguish between weather
which will melt a brass door-knob and weather which will only make it mushy.
		-- Mark Twain

[toc] | [prev] | [next] | [standalone]

#39308

Mike Easter <MikeE@ster.invalid> writes:

> Yrrah wrote:
>> And now explained to the unitiated? ;-)
>
> Drivers in the kernel is a HUGE problem.

Only if they're binary blobs, like Windows is chock full of.

>
> Where is the Tanenbaum crowd when we need them?
>
> http://www.cs.vu.nl/~ast/reliable-os/  Tanenbaum-Torvalds Debate: Part
> II - (2006 May)

Why do we need them? This smells like you're trolling again.

[toc] | [prev] | [standalone]

Back to top | Article view | alt.os.linux

csiph-web