Dirty Cow, Ubuntu @ 12, Save a Penguin
Dirty Cow is a local privilege vulnerability that can allow one to gain root access. Specifically, "race condition was found in the way the Linux kernel's memory subsystem handled the copy-on-write (COW) breakage of private read-only memory mappings. An unprivileged local user could use this flaw to gain write access to otherwise read-only memory mappings and thus increase their privileges on the system." Linus signed off and pushed the patch to git a few days ago and distributions are currently updating their products. This is considered a critical bug and users are encouraged to update as soon as possible because researchers have found code in the wild to exploit it. Worse still, the exploit leaves little or no trace of being compromised. So, keep an eye on your update applets or security advisories over the next few days. Since this bug has been in existence for so long, Kees Cook had to revise his critical bug lifetime average from 3.3 to 5.2 years, while the overall average for all bugs increased only slightly.
Today, October 20, 2016, Linux kernel maintainer Greg Kroah-Hartman announced three new maintenance updates for the Linux 4.8, 4.7, and 4.4 LTS kernel series, patching a major security vulnerability.
Known as "Dirty COW," the Linux kernel vulnerability documented at CVE-2016-5195 is, in fact, a nasty bug that could have allowed local users to write to any file they can read. The worst part is that the security flaw was present in various Linux kernel builds since at least the Linux 2.6.x series, which reached end of life in February this year.
As reported earlier, three new Linux kernel maintenance releases arrived for various Linux-based operating systems, patching a critical and ancient bug popularly known as "Dirty COW."
We already told you that the kernel vulnerability could be used by a local attacker to run programs as an administrator, and it looks like it also affects all supported Ubuntu releases, including Ubuntu 16.10 (Yakkety Yak), Ubuntu 16.04 LTS (Xenial Xerus), Ubuntu 14.04 LTS (Trusty Tahr), and Ubuntu 12.04 LTS (Precise Pangolin), as well as all of their official or unofficial derivatives running the same kernel builds.
Mad Max Now on GNU/Linux
After teasing us earlier this month, today, October 20, 2016, Feral Interactive had the great pleasure of announcing the release of the Mad Max open world action-adventure video game for the SteamOS, Linux, and Mac platforms.
Feral Interactive is well known for bringing AAA titles to the Linux and Mac gaming world, and after porting the Tomb Raider 2013 reboot last year to our beloved platforms, which continue to get more fans by the day, now the UK-based video games publisher delights us with the superb Mad Max title developed by Avalanche Studios and published by Warner Bros.
Feral Interactive's port of Mad Max to Linux (and macOS) is now officially out and can be found on Steam.
Feral announced their Mad Max port at the beginning of October while today it's ready to ship. As mentioned in that original article, the Linux system requirements are fairly stiff with only listing NVIDIA hardware under Linux and the minimum being a GTX 660 while the recommendation is at least a GTX 970.
This morning's release of the Mad Max game for Linux lists only NVIDIA graphics as supported, but it does turn out at least for newer AMD GPUs using the RadeonSI Gallium3D driver things should work -- well, assuming you are using the latest open-source driver code.
Mad Max is the latest Linux port from Feral Interactive, probably one of the titles I have been most excited about so hopefully it lives up to the promise.
It has only been a few weeks since Feral Interactive released Dawn of War II, Chaos Rising and Retribution on Linux, and now we have a real whopper with Mad Max.
Something Linux lacks is a reasonable amount of high quality open-world story-based games. We started getting a few with Borderlands 2 and Shadow of Mordor, but another top quality game like this is a must for us to keep the interest up.
Red Hat and Fedora
As successful companies grow, they accumulate products; new ones are developed and additional ones are acquired. Managing diverse portfolios is a challenge, not least when it comes to putting it all together on a single presentation slide to make it appear there is an overall coherent product strategy.
Ericsson and Red Hat today announced a broad alliance to work together on network functions virtualization (NFV) products. And the telco infrastructure provider will now support the Red Hat OpenStack Platform.
Ericsson already has a longstanding distribution partnership with Red Hat that includes Red Hat Enterprise Linux and Red Hat JBoss Middleware. The existing distribution partnerships define not only commercial terms, but also joint support models, co-engineering and certification testing, and joint go-to-market collaboration.
Open-source software firm Red Hat (NYSE: RHT) has teamed up with Ericsson (Nasdaq: ERIC) on what the companies are calling a “broad alliance” aimed at transforming the information and communications technology market.
Red Hat, headquartered at downtown Raleigh’s Red Hat Tower, announced that its new partnership with Ericsson would allow the duo to deliver fully open-source and production-ready cloud infrastructure, spanning OpenStack, software-defined networking and software-defined infrastructure.
The job is like many other roles called “Community Manager” or “Community Lead.” That means there is a focus on metrics and experiences. One role is to try ensure smooth forward movement of the project towards its goals. Another role is to serve as a source of information and motivation. Another role is as a liaison between the project and significant downstream and sponsoring organizations.
In Fedora, this means I help the Fedora Project Leader. I try to be the yen to his yang, the zig to his zag, or the right hand to his right elbow. In all seriousness, it means that I work on a lot of the non-engineering focused areas of the Fedora Project. While Matthew has responsibility for the project as a whole I try to think about users and contributors and be mechanics of keeping the project running smoothly.
We have been using keepalived in Fedora Infrastructure for a while now. It’s a pretty easy to use and simple way to do some basic HA. Keepalived can keep track of which machine is “master” for a IP address and quickly fail over and back when moving that IP address around. You can also run scripts on state change. Keepalived uses VRRP and handles updating arp tables when IP addresses move around. It also supports weighting so you can prefer one or another server to “normally” have the master IP/scripts.
This blog now has a drop-down category called Modularity. But, many arteries of Modularity lead into a project called Factory 2.0. These two are, in fact, pretty much inseparable. In this post, we’ll talk about the 5 problems that need to be solved before Modularity can really live.
The origins of Factory 2.0 go back a few years, when Matthew Miller started the conversation at Flock. The first suggested names were “Fedora Rings”, “Envs and Stacks”, and Alephs.
The Varnish Cache project recently released varnish-5.0, and Varnish Software released hitch-1.4.1. I have wrapped packages for Fedora and EPEL.
varnish-5.0 has configuration changes, so the updated package has been pushed to rawhide, but will not replace the ones currently in EPEL nor in Fedora stable. Those who need varnish-5.0 for EPEL may use my COPR repos at https://copr.fedorainfracloud.org/coprs/ingvar/varnish50/. They include the varnish-5.0 and matching varnish-modules packages, and are compatible with EPEL 5, 6, and 7.