Brief items [LWN.net]

Security

Security quotes of the week

It can be reasonably argued that anyone publicly posting the kinds of specific planning materials that have been discovered in the wake of recent attacks has effectively surrendered various “rights” to privacy that might ordinarily be in force.

The fact that we keep discovering these kinds of directly related discussions and threats publicly online in the wake of these terrorist attacks, suggests that we are not effectively using the public information that is already available toward stopping these attacks before they actually occur.

To the extent that AI/machine learning technologies — in concert with human analysis and decision-making — may possibly provide a means to improve this situation, we should certainly at least be exploring the practical possibilities and associated issues.

— Lauren Weinstein

In this paper, we present an approach to generate adversarial patches to targets with lots of intra-class variety, namely persons. The goal is to generate a patch that is able successfully hide a person from a person detector. An attack that could for instance be used maliciously to circumvent surveillance systems, intruders can sneak around undetected by holding a small cardboard plate in front of their body aimed towards the surveillance camera.

— Simen Thys, Wiebe Van Ranst, and Toon Goedeme

Cyberattacks don't magically happen; they involve a series of steps. And far from being helpless, defenders can disrupt the attack at any of those steps. This framing has led to something called the "cybersecurity kill chain": a way of thinking about cyber defense in terms of disrupting the attacker's process.

On a similar note, it's time to conceptualize the "information operations kill chain." Information attacks against democracies, whether they're attempts to polarize political processes or to increase mistrust in social institutions, also involve a series of steps. And enumerating those steps will clarify possibilities for defense.

— Bruce Schneier

Comments (1 posted)

Kernel development

Kernel release status

The current development kernel is 5.1-rc7, released on April 28. Linus said: "But it's all pretty tiny. Plus about 30% of the patches are marked for stable, so on the whole it really does feel like 5.1 is on target for a regular release next weekend."

Stable updates: 5.0.10, 4.19.37, 4.14.114, 4.9.171, 4.4.179, and 3.18.139 were released on April 27. The 5.0.11, 4.19.38, 4.14.115, and 4.9.172 updates are in the review process; they are due on May 2.

Comments (none posted)

An eBPF overview, part 3: Walking up the software stack (Collabora blog)

Adrian Ratiu continues his series on eBPF with part 3, which looks at various ways to write and build eBPF programs. It starts by looking at using "restricted C" with the LLVM eBPF compiler, moves into looking at the BPF Compiler Collection (BCC), then bpftrace, and finally the IOVisor cloud-based eBPF tools. "Not everyone has kernel sources at hand, especially in production, and it's also a bad idea in general to tie eBPF-based tools to a specific kernel source revision. Designing and implementing the interactions between eBPF program's backends, frontends, loaders and data structures can be very complex, error-prone and time consuming, especially in C which is considered a dangerous low-level [language]. In addition to these risks developers are also in a constant danger of re-inventing the wheel for common problems, with endless design variations and implementations. To alleviate all these pains is why the BCC project exists: it provides an easy-to-use framework for writing, loading and running eBPF programs, by writing simple python or lua scripts in addition to the 'restricted C' as exemplified above."

Comments (2 posted)

Quotes of the week

Remember, maintainer/reviewer time is scarce, engineer time is prolific, we optimize for reviewers, not the people writing the patches.

— Greg Kroah-Hartman

To phrase the argument in a bit more controversial form:

If the price of Linux using an insecure C runtime is to slow down system calls with immense PTI-alike runtime costs, then wouldn't it be the right technical decision to write the kernel in a language runtime that doesn't allow stack overflows and such?

I.e. if having Linux in C ends up being slower than having it in Java, then what's the performance argument in favor of using C to begin with?

— Ingo Molnar

Comments (6 posted)

Distributions

Fedora 30 released

Fedora Magazine has announced the release of Fedora 30. "Fedora Editions are targeted outputs geared toward specific “showcase” uses. Since we first started using this concept in the Fedora 21 release, the needs of the community have continued to evolve. As part of Fedora 30, we’re combining cloud and server into the Fedora Server edition. We’re bringing in Fedora CoreOS to replace Fedora Atomic Host as our container-focused deliverable in the Fedora 30 timeframe — stay tuned for that. The Fedora Workstation edition continues to focus on delivering the latest in open source desktop tools. Of course, we produce more than just the editions. Fedora Spins and Labs target a variety of audiences and use cases, including the Internet of Things. And, we haven’t forgotten our alternate architectures, ARM AArch64, Power, and S390x."

Comments (3 posted)

Distribution quote of the week

If you're actively developing in a particular ecosystem, it's likely that following the latest code will have more value to you in your corner of the world than Debian's curation. However you probably don't want that everywhere across all technologies. You probably want a base set of things that is stable on which you can build. When you are unfamiliar with some application, you probably just want a version that works with security support than to have to track the latest thing.

Debian lets you mix and match across these requirements. The people I talked to found that answer compelling.

— Sam Hartman

Comments (none posted)

Development

Apache Software Foundation moves to GitHub

The Apache Software Foundation (ASF) and GitHub have announced [ASF, GitHub] that all ASF projects using Git have moved to GitHub and the ASF Git service has been decommissioned. (Thanks to Paul Wise)

Update: ASF has another announcement with more details. An older Git service was decommissioned, but ASF projects are still available on https://gitbox.apache.org/. "As stated above, our GitHub integration is an augmentation of our existing service. It is available to all committers on git-based projects to make use of, should they so wish. All new git repositories will automatically be available on both GitHub and Gitbox." (Thanks to Lars Francke)

Comments (59 posted)

The state of Linux graphic design tools in 2019 (Opensource.com)

Over at Opensource.com, Jason Brock tries out Linux graphics tools, with an eye toward their ability to replace the proprietary tools he uses on a day-to-day basis. Overall, the tools held their own for a variety of tasks (e.g. logo and ad design, publication layout), though the lack of a certain type of tool brought the overall grade down to a B+: "The lack of available wireframing and prototyping applications really brought down the average, but I'd still call it a successful exercise. As I mentioned at the beginning, design is a craft and it relies on collaboration. All of the tools I looked at—Inkscape, LibreDraw, GIMP, and Scribus—can run just as well on Windows or MacOS as they do on any Linux distribution. The ability to create robust artwork and share editable files with stakeholders and colleagues on the platform of their choice means that a serious argument could be made that these tools are even more versatile than their proprietary counterparts."

Comments (9 posted)

Page editor: Jake Edge
Next page: Announcements>>