Brief items
Security
Aleksandersen: Limit the impact of a security intrusion with systemd security directives
Daniel Aleksandersen shows how to sandbox a daemon process using a set of systemd features. "These directives combined would have stopped the specific remote code execution vulnerability that afflicted OpenSMTPD. However, the key takeaway is that you should strive to sandbox long-running and internet-exposed services. There’s no need for your webserver to be able to load a kernel module, your email server to change the hostname, or your DNS server to launch wget and schedule reoccurring tasks with cron."
Horn: Mitigations are attack surface, too
On the Google Project Zero blog, Jann Horn looks at a number of vulnerabilities in a Samsung Android kernel, some of which are caused by the addition of out-of-tree "security" features. "The Samsung kernel on the A50 contains an extra security subsystem (named 'PROCA', short for 'Process Authenticator', with code in security/proca/) to track process identities. By combining several logic issues in this subsystem (which, on their own, can already cause a mismatch between the tracking state and the actual process state) with a brittle code pattern, it is possible to cause memory unsafety by winning a race condition."
Security quotes of the week
The key point -- and one that many of us have made for years is that the
framing by [FBI Director Christopher] Wray/[US Attorney General William]
Barr (and, for what it's worth, James
Comey before them) is
that there's some sort of conflict here between "security" and "privacy."
But that's always been bullshit. The issue has always been between having
both security and privacy vs. giving law enforcement easier access to data
and information they can almost always get elsewhere with a little more
effort. In short, it's a debate between having security and privacy widely
available against a bit of convenience for law enforcement. As such, this
should be no debate at all.
— Mike
Masnick
Last month, engineers at Google published a very curious privacy bug in
Apple's Safari web browser. Apple's Intelligent Tracking Prevention, a
feature designed to reduce user tracking, has vulnerabilities that
themselves allow user tracking. [...]
— Bruce
Schneier
If there's any lesson here, it's that privacy is hard -- and that privacy engineering is even harder. It's not that we shouldn't try, but we should recognize that it's easy to get it wrong.
Kernel development
Kernel release status
The current development kernel is 5.6-rc1, released on February 9. "This was actually a slightly smaller merge window than usual, but I think that what happened is simply that the holiday season impacted new development. It impacted the 5.5 rc series less than I had expected, but seems to instead have caused 5.6 to have slightly less development than normal."
Stable updates: 5.5.3, 5.4.19, and 4.19.103 were released on February 11.
Quotes of the week
If Greg KH ever writes a book about his work as the stable kernel
maintainer, it should be titled “Everyone must upgrade” (or it
could be a Dr. Who fanfic about Cybermen, I guess). Today, I'm
going to borrow a leaf out of that non-existent book to loudly
proclaim that all patch submissions must include base-commit info.
— Konstantin
Ryabitsev
In the past we would find Windowsisms in the BIOSes and get really
annoyed that we had to work around them. Now there are Linuxisms
in the BIOS, that's not any better.
— Linus
Walleij
gpio devices, sigh.
It's like wrapping a scarf around your head and crawling under a porch or deck.
You never know what surprises you'll put your hands onto.
— Theo de Raadt
Distributions
Distribution quotes of the week
Nothing is worse for the debian project than for every single suggestion
that something change be met with opposition that boils down to
opposition to change. Things have changed before, they will change
again, and honestly the impact of most of those changes is very small
(for either better or worse) and certainly they are not things that
should be met with the level of emotional response that they are. If
anything has changed for the worse in the project it's this sense we
aren't allowed to change things anymore.
— Michael
Stone (Thanks to Luke Faraone)
In software as complicated as a Linux distribution, quite often, the right way to make a change requires a significant amount of changes across the entire codebase.
Or in other words "in order to be able to change any ONE thing, you must be able to change EVERYTHING".
— Richard Brown
There was a big-tech-site review of Fedora a while ago when Workstation made
it easier to install the Nvidia driver, which was generally positive in the
details but had an overall negative tone and headline along the lines of:
"I'm sad to see Fedora losing its purism" -- and then casually noted that of
course, he uses a different distro that includes all of the things Fedora
doesn't. I find this quite frustrating: yes, Fedora should set a positive
example, but we want to be an actually popular example that people use, not
a theoretical ideal that people cluck at from a distance as they recommend
everything else to their friends and family.
— Matthew Miller
Development
Davis: Is Open Source a diversion from what users really want?
Over on the Ardour forum, Paul Davis wonders whether access to the source code is truly what users these days want or need. There are other closed-source digital audio workstations that are far more customizable than Ardour via a scripting language without needing any access to the source. "But perhaps for applications like Ardour, ones that do not yet exist, there ought to be a different development pathway. I remember once wondering if we should have implemented the entire GUI in PyGTK (i.e. Python). We didn't, and most of my curiosity was about whether it would have helped or hindered our development process. However, had we done so, one of the consequences would have been that many changes to the program would have been made simpler, easier to access and would require no 'rebuild'. I wonder if going forward, large-scale apps like Ardour ought to (as Reaper did relatively early in its life) consider the 'script extension system' to be a vital and critical part of the application infrastructure. This would mean, for example, writing large parts of 'core functionality' using this system, rather than dropping back into C++ to get things done. There are precedents for this: GNU Emacs, for example, is at some level written in C, but almost everything about the program is actually constructed in Emacs Lisp, its own 'scripting extension'. The C core of Emacs is so small and so irrelevant that it almost doesn't matter that it is there: if you want to modify or extend Emacs, you (almost always) write Lisp, not C."
Firefox 73.0
Firefox 73.0 has been released. This version includes two features that help users view and read website content more easily; a new global default zoom level setting and a "readability backplate" solution to make websites in High Contrast Mode more readable without disabling background images. See the release notes for details.GDB 9.1 released
Version 9.1 of the GNU debugger is out. There are many improvements; see the announcement and the changelog for details.Hutterer: User-specific XKB configuration - part 1
On his blog, Peter Hutterer writes about some changes that will allow users to start deploying their own rules to modify keyboard layouts without driving themselves crazy.
Many many moons ago before the Y2K bug was even in its larvae stage, the idea was that you could configure all of those because every UNIX tool had to be more flexible than your yoga teacher. I'm unsure to what extent this was actually ever the case but around 2007-ish the old keyboard driver got deprecated and the evdev driver made it's grand entrance. And one side-effect of that was that things broke. evdev uses different keycodes, so all those users that copy-pasted unnecessary XKB configuration into their xorg.conf now had broken keys because they were applying the wrong rules. After whacking enough moles that we got in trouble with the RSPCA [Royal Society for the Prevention of Cruelty to Animals] we started hardcoding the "evdev" ruleset everywhere. The xorg.conf option "XKBRules" became a noop and thus stopped breaking users' setups.
Except that it also stopped users from deploying their own rules files - something that probably didn't really matter anyway. This had some unintended side-effects though. First, to have a working custom XKB layout you basically had to get it merged upstream. Yes, you could edit the files locally but they'd just be overwritten next time you update the packages. Second, getting rid of hardcoded things is hard so we're stuck with the evdev ruleset for the forseeable future. This was the situation until, well, now.
Development quote of the week
Compare what happened with our shell windows with what happened with our
"smart" phones in the last 20 years and you'll get some inkling of what I
think we're missing. It's not that we should program the way we use
iPhones, but that there are fields where user interface work has made a
real [difference] recently. Not so in programming, though. We're missing out.
— Rob Pike
Page editor: Jake Edge
Next page:
Announcements>>