DaemonForums  

Go Back   DaemonForums > Miscellaneous > Off-Topic

Off-Topic Everything else.

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 8th October 2015
cynwulf's Avatar
cynwulf cynwulf is offline
Package Pilot
 
Join Date: Mar 2014
Posts: 149
Default LinuxCon 2015 - Linus says "I’m sure we could do better" on kernel security

Quote:
On kernel security:

I’m sure we could do better, but we have a fair amount of tools to do static checking for common patterns--and we haven’t had anyone say this is unfixable, rewrite it all. Don’t get me wrong, security people will always be unhappy. But the kernel poses special challenges, because any bug can be a security bug. We also have to keep in mind that most of the kernel is drivers, a big chunk of the rest is architecture specific, and there are 25 million lines of code. So it’s really hard to have people go over it; we have to rely on automated testing and on tools. There are too many lines in too many obscure places for humans to really check.
http://www.linux.com/news/software/l...linus-torvalds

Even with my very limited experience of this, it seems like this equates to proper code auditing not really being possible because there's 'too much code' to audit? With most of the Linux kernel being drivers, you have to wonder what percentage of those drivers are unmaintained and supporting long dead hardware which 99.999% are not using?
Reply With Quote
  #2   (View Single Post)  
Old 8th October 2015
e1-531g e1-531g is offline
Spam Deminer
 
Join Date: Mar 2014
Location: Country:Poland;Continent:Europe
Posts: 230
Default

You can manually configure Linux kernel before compiling it. I even have measured time of compiling kernel with default config (I don't remember if this config is from upstream or some distro) and configured by hand for my laptop.
First option compiled in 4033 seconds, second 337 seconds.
Of course maybe there still be some hooks in various places for drivers etc, which will be compiled in.
Reply With Quote
  #3   (View Single Post)  
Old 8th October 2015
cynwulf's Avatar
cynwulf cynwulf is offline
Package Pilot
 
Join Date: Mar 2014
Posts: 149
Default

Well you can build a kernel with modules only for the target system, which does cut down on build time yes, but in general terms that's pretty useless for someone maintaining a kernel for a distribution or administering more than one box - and the way Linux is developed, it's not that practical to maintain your own personal kernel build for a single machine either. So generally, distributions are providing kernels with the 'full' kernel build including all of the aforementioned cruft.
Reply With Quote
  #4   (View Single Post)  
Old 8th October 2015
sacerdos_daemonis's Avatar
sacerdos_daemonis sacerdos_daemonis is offline
Real Name: Will forever be a secret.
Package Pilot
 
Join Date: Sep 2014
Location: Currently residing in China.
Posts: 152
Default

25 million lines of code

I did not even imagine the kernel was so large.
Quote:
There are too many lines in too many obscure places for humans to really check.
I know very little about kernels, but I imagine as the kernel continues to evolve and older pieces become obsolete, there is a danger that it could become too unwieldy. Crushed by its own weight so to speak. Perhaps they should consider creating a new kernel and implementing it when it is ready, instead of continuing to patch the old one?
__________________
I am always right.
I thought I was wrong once, but I was mistaken.
Reply With Quote
  #5   (View Single Post)  
Old 13th October 2015
cynwulf's Avatar
cynwulf cynwulf is offline
Package Pilot
 
Join Date: Mar 2014
Posts: 149
Default

Well it's a viable assumption that the code base will simply continue to grow as, despite how many developers are involved and the amount of corporate money thrown at it, it's just too "hard" for people to do security audits, let alone remove redundant code, unsupported drivers, etc.

It's more like a case of it being too far gone and too complex and perhaps there are parts of the code which no one really understands any more on account of the open development model (e.g. there are people or groups of people who made commits, possibly over 10 years ago, who no longer work on the project)? From a security perspective that doesn't sound too good.
Reply With Quote
  #6   (View Single Post)  
Old 13th October 2015
e1-531g e1-531g is offline
Spam Deminer
 
Join Date: Mar 2014
Location: Country:Poland;Continent:Europe
Posts: 230
Default

For most use cases (Threat model) Gnu/Linux is reasonably secure if someone doesn't do stupid things and update it frequently. Every human action have associated probability of failure, operating systems are not exceptions.
Formal verification of an OS microkernel should be an ideal, but I don't know whether any operating system based on f.v. microkernel for desktop use-cases exists.
For me OpenBSD is good balance between ideally secure OS and functionality.
Reply With Quote
  #7   (View Single Post)  
Old 13th October 2015
cynwulf's Avatar
cynwulf cynwulf is offline
Package Pilot
 
Join Date: Mar 2014
Posts: 149
Default

Quote:
Originally Posted by e1-531g View Post
For most use cases (Threat model) Gnu/Linux is reasonably secure if someone doesn't do stupid things and update it frequently.
The same could be said for any OS. That's not actually the issue being discussed anyway and adds nothing meaningful.

In case you missed it:
Quote:
So it’s really hard to have people go over it; we have to rely on automated testing and on tools. There are too many lines in too many obscure places for humans to really check.
This is tantamount to saying - we can't audit it because there's too much of it. If it's not then what is it? If it can't be audited and it's ok to have code in "obscure corners", should it be running on stuff like cisco routers or whatever (especially considering the notoriety for poor support from such vendors)?

In my view this is just yet another "get out", as with:

http://www.cio.com/article/2434264/o...-monkeys-.html

(though perhaps a little more subtle this time around)

Opinion: Torvalds has pretty much chosen to do nothing at all with regards to kernel security and left it to third parties, i.e. a reactive approach rather than a proactive one. There wasn't really a security model in the first place, so retroactively implementing that is not easy - and of course discrediting "security people" is easier.
Reply With Quote
  #8   (View Single Post)  
Old 7th November 2015
cynwulf's Avatar
cynwulf cynwulf is offline
Package Pilot
 
Join Date: Mar 2014
Posts: 149
Default

A new, controversial*, Washington Post article on the same subject: http://www.washingtonpost.com/sf/bus...-the-argument/

The article is typical tech press and I'm not exactly a fan of this periodical or style of journalism, but it raises many points on Linus' dismissive arrogance towards "crazy" "security people" and reckless attitude towards security features.

*fanbois are up in arms
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Difference between"arp info overwritten" and " duplicate IP address " varag OpenBSD Security 1 6th April 2015 02:57 PM
"the OpenBSD kernel will only recognize 3.1 gig of RAM"? hanzer OpenBSD General 8 20th January 2015 06:48 PM
Blog article "Security: OpenBSD VS FreeBSD" gkbsd OpenBSD Security 11 13th January 2015 11:48 PM
Fixed "xinit" after _7 _8, "how" here in case anyones' "X" breaks... using "nvidia" jb_daefo Guides 0 5th October 2009 09:31 PM
New Kernel: "make depend" doesn't work nihonto NetBSD General 9 23rd January 2009 09:02 PM


All times are GMT. The time now is 06:34 PM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2016, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick