« I see security as being more of a nuisance for the upstream kernel
developers. It's understandable, if someone makes a mistake, it can be
embarrassing, particularly when it gets into the news or has some
important impact. It also lessens the image of Linux as being an
enterprise-ready OS if someone can write up an exploit to take over the
entire system in a matter of hours in some cases. »
Lire aussi :
Grsecurity Developer Spender's Feelings on the State of Linux Security
https://news.ycombinator.com/item?id=10518480
Kernel Self Protection Project
http://openwall.com/lists/kernel-hardening/2015/11/05/1
« I'm organizing a community of people to work on the various kernel
self-protection technologies (most of which are found in PaX and
Grsecurity). I'm building on the presentation I gave at Kernel Summit
where I sought to convince the other upstream Linux kernel developers
that security is more than fixing bugs, and that we need to bring in
proactive defenses:
http://lwn.net/Articles/662219/
This is especially highlighted by the Washington Post article today:
The kernel of the argument
Fast, flexible and free, Linux is taking over the online world. But there is growing unease about security weaknesses.
http://www.washingtonpost.com/sf/business/2015/11/05/net-of-insecurity-the-kernel-of-the-argument/
Between the companies that recognize the critical nature of this work,
and with Linux Foundation's Core Infrastructure Initiative happy to
start funding specific work in this area, I think we can really make a
dent.
Let's start the work. I've built some wiki pages around my slides,
where we can take notes, list examples, and coordinate:
http://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project
http://kernsec.org/files/lss2015/giant-bags-of-mostly-water.pdf
Pull live patching infrastructure from Jiri Kosina: "Let me provide a bit of history first, before describing what is in this pile.
https://lkml.org/lkml/2014/4/30/477
https://lkml.org/lkml/2014/7/14/857
https://lkml.org/lkml/2014/11/7/354
http://linuxplumbersconf.org/2014/wp-content/uploads/2014/10/LPC2014_LivePatching.txt
Suggest possible kernel-level Linux exploits based on the Operating System release number.
So, there was a lot of fuzz about a recent talk by Karsten Nohl et al. at BlackHat about the the unsecurity of current USB implementations (on the computer side) which happily load drivers for all kinds of devices as soon as a (potentially malicious) USB stick is connected.
https://www.kernel.org/doc/Documentation/usb/authorization.txt
https://www.kernel.org/doc/Documentation/ABI/stable/sysfs-bus-usb
System calls are the primary mechanism by which user-space programs interact with the Linux kernel. Given their importance, it's not surprising to discover that the kernel includes a wide variety of mechanisms to ensure that system calls can be implemented generically across architectures, and can be made available to user space in an efficient and consistent way.
The getrandom(2) system call was requested by the LibreSSL Portable developers. It is analoguous to the getentropy(2) system call in OpenBSD.
The rationale of this system call is to provide resiliance against file descriptor exhaustion attacks, where the attacker consumes all available file descriptors, forcing the use of the fallback code where /dev/[u]random is not available. Since the fallback code is often not well-tested, it is better to eliminate this potential failure mode entirely.
I implemented a new feature for LUKS in order to allow for emergency deletion of all LUKS key material. I've finished the implementation and submitted it to Clemens Fruhwirth for merging it into the next version of LUKS.
Zram has lived in staging for a LONG LONG time and have been fixed/improved by many contributors so code is clean and stable now. Of
course, there are lots of product using zram in real practice.
Knock is a kernel patch that implements a new NAT-compatible, TCP option for stealthy port knocking with a few new twists for improved security.
Background
Today, port scanners can scan all IPv4 addresses in less than one hour. Port knocking is a method for making TCP servers less visible on the Internet. The basic idea is to make a TCP server not respond (positively) to a TCP SYN request unless a particular "knock" packet has been sent first. This can be helpful for security, as an attacker that cannot establish a TCP connection also cannot really attack the TCP server. There are a bunch of existing user-space tools, such as Knock Knock and knockd. Most of these implementations send some other traffic (such as a UDP packet) to the target host to have it (briefly) open the server port. A particularly noteworthy recent idea in this domain is the SilentKnock, which adds the idea of integrating the knock secret in the initial TCP SYN packet in the SQN field, which is a technique borrowed from network steganography.
Multipath TCP is a solution that allows to simultaneously use multiple interfaces/IP-addresses for a single data-stream, while still presenting a standard TCP socket API to the application. Multipath TCP thus allows to increase the download-speed by aggregating the bandwidth of each interface. Additionally, MPTCP allows mobile hosts to handover traffic from WiFi to 3G, without disrupting the application. Various other use case exist for Multipath TCP in datacenters, for IPv6/IPv4 coexistence, ...