Ubuntu OTA-14, the latest over the air update to Ubuntu phone and tablet, has begun to roll out to supported devices. “This time not so many changes released in overall but with the goal of introducing less regressions,” says Canonical’s Lukasz Zemczak in the release announcement mailing list post.
The MacBook Pro introduction in October caused unusually negative reactions among professional users due to the realization that Apple no longer caters equally to casual and professional customers as it had in the past [YouTube video]. Instead, the company appears to be following an iOS-focused, margin-driven strategy that essentially relegates professionals to a fringe group. This has well-known developers such as Salvatore Sanfilippo (of the Redis project) consider a move back to Linux. Perhaps that's a good moment to look at the current state of Mac hardware support in the kernel. While Macs are x86 systems, they possess various custom chips and undocumented quirks that the community needs to painstakingly reverse-engineer.
There is an interesting subset of Linux users that prefer to run it on a Mac. Yes, a Mac. That might seem odd given how Apple is known for its closed ecosystems and high cost hardware, but the Linux on Mac folks really do exist out there.
But how well does the Linux kernel support Mac hardware? LWN.net has a “state of the union” article for Linux on the Mac that could be quite helpful if you are thinking about installing Linux on your Mac.
There is yet another new Linux kernel vulnerability being disclosed today that allows for unprivileged processes to gain kernel code execution abilities.
This new vulnerability is CVE-2016-8655 but it doesn't seem to be getting too much attention yet. CVE-2016-8655 comes down to a race condition within the af_packet.c code for gaining local root access. The researcher that found it was able to write an exploit to gain root shell on an Ubuntu 16.04 LTS system and defeats SMEP/SMAP protection too.
Just a quick note: on recent versions of systemd it is relatively easy to block the vulnerability described in CVE-2016-8655 for individual services.
Since systemd release v211 there's an option RestrictAddressFamilies= for service unit files which takes away the right to create sockets of specific address families for processes of the service. In your unit file, add RestrictAddressFamilies=~AF_PACKET to the [Service] section to make AF_PACKET unavailable to it (i.e. a blacklist), which is sufficient to close the attack path. Safer of course is a whitelist of address families whch you can define by dropping the ~ character from the assignment. Here's a trivial example: