You are here

Bits from Debian

Subscribe to Feed Bits from Debian
Planet Debian -
Përditësimi: 1 ditë 20 orë më parë

Jonathan McDowell: Upgrading my home server

Pre, 19/07/2019 - 10:06pd

At the end of last year I decided it was time to upgrade my home server. I built it back in 2013 as an all-in-one device to be my only always-on machine, with some attempt towards low power consumption. It was starting to creak a bit - the motherboard is limited to 16G RAM and the i3-3220T is somewhat ancient (though has served me well). So it was time to think about something more up to date. Additionally since then my needs have changed; my internet connection is VDSL2 (BT Fibre-to-the-Cabinet) so I have an BT HomeHub 5 running OpenWRT to drive that and provide core routing/firewalling. My wifi is provided by a pair of UniFi APs at opposite ends of the house. I also decided I could use something low power to run Kodi and access my ripped DVD collection, rather than having the main machine in the living room. That meant what I wanted was much closer to just a standard server rather than having any special needs.

The first thing to consider was a case. My ADSL terminates in what I call the “comms room” - it has the electricity meter / distribution board and gas boiler, as well as being where one of the UniFi’s lives and where the downstairs ethernet terminates. In short it’s the right room for a server to live in. I don’t want a full rack, however, and ideally wanted something that could sit alongside the meter cabinet without protruding from the wall any further. A tower case would have worked, but only if turned sideways, which would have made it a bit awkward to access. I tried in vain to find a wall mount case with side access that was shallow enough, but failed. However in the process I discovered a 4U vertical wall mount. This was about the same depth as the meter cabinet, so an ideal choice. I paired it with a basic 2U case from X-Case, giving me a couple of spare U should I decide I want another rack-mount machine or two.

My old machine has 2 3.5” hotswap drive bays; this has been useful in the past when a drive failed even just to avoid having to take the machine apart. I still wanted to aim for low power consumption, so 2 drives is enough. I started with a pair of cheap 5.25” drive bay to dual 2.5” + 3.5” hotswap bay devices, but the rear SATA connectors ended up being very fragile and breaking off, so I bit the bullet and bought a SilverStone FS303. This takes up 2 5.25” bays and provides 3 x 3.5” hotswap bays. It’s well constructed and the extra bay has already turned out useful when a drive started to fail and I was able to put the replacement in and resync the RAID set before having to remove the old drive.

Now I had the externals sorted I needed to think about what to put inside. The only thing coming from the old machine were the hard disks (a 4T Seagate and a 6T WD RED, 4T of software RAID1 and 2T of unRAIDed backup space), so everything else was up for discussion. I toyed with an Intel i7-8700T - 6 cores in 35W. AMD have a stronger offering these days though and the AMD Ryzen 2700E with 8 cores in 45W seemed like a good option for an extra 10W. Plus on top there are several of the recent speculative execution exploits that don’t seem to affect AMD chips (or more recent Intel CPUs, but they weren’t out at the time in a low power format). Sadly the 2700E proved to be made of unobtanium; I sat with it on backorder for nearly 3 months before giving up and ordering a AMD Ryzen 2700 that was on offer. This is rated at up to 65W, but I considered trying to underclock if necessary or tweak the cpufreq settings at least.

Next up was a motherboard. The 2U case is short, but allows for MicroATX, an improvement over the MiniITX my last case needs. One of the things constraining me with the old machine was that it maxed out at 16G RAM, so I wanted something that would take more. It turns out there are a number of Socket AM4 MicroATX boards that will take 64G over 4 DIMMs. I chose an ASRock B450M Pro4, which had a couple of good reviews and seemed to have all the bits I wanted. It’s been decent so far - including having some interactions with ASRock support when I initially put an AMD 240GE (while waiting for the 2700E that was never coming) in it. I like to think of BIOS 3.10 as mine ;).

For RAM I went with a Corsair CMK32GX4M2A2400C14 Vengeance LPX 32GB (2 x 16GB) set. I’m sure I should care more about RAM but it was decently priced from a vendor I trust. At some point I’ll buy another set to bring the board up to the full 64GB, but for now this is twice what the old machine had.

Finally I decided to splash out on some SSD. The spinning rust is primarily for media (music + video shared out to Kodi etc) and backups, but I wanted to move my containers (home automation, UniFi controller, various others) over to SSD. I talked myself into a pair of Corsair MP510 960GB NVMe M.2 drives. One went on the motherboard slot and I had to buy a low profile PCIe adaptor for the other (of course they’re RAID1ed). They fly; initially I clocked them in at about 1.5GB/s until I realised the one in the add-in card was only using 2 PCIe lanes. Once I rejigged things so it had all 4 it can use I was up to 2.3GB/s. Impressive.

You’ll note I haven’t mentioned a graphic card here. I ended up with a cheap NVidia off eBay to get things going, but this is a server in a comms room and removing the graphics card saves me at least 10W of power (it was also the reason the NVMe drive only had 2 lanes). I couldn’t find an AM4 motherboard that did serial console, but the 450M Pro is happy to boot without a graphics card present, and I have GRUB onward configured to do serial console just in case.

And the power consumption? The previous machine idled at around 50W, getting to maybe 60-65W under load. I’ve cheated with the new machine; because the spinning rust is not generally in use it’s configured to spin down after 20 minutes idle. As a result the machine idles at around 36W. It hits 50W when the drives spin up, so for 8 cores compared to 2 we’re still sitting in the same ballpark. That’s good, because that’s the general case - idle here means Home Assistant operational, the UniFi controller going, the syslog container logging and so on. However the new server peaks considerably higher; if the drives are spun up and I compile a kernel I can hit 120W. However the compilation takes less than a quarter of the time - the machine is significantly faster than the old one, and even without taking advantage of the SSDs idles at roughly the same power level. I’d call that an overall win.

Holger Levsen: 20190718-social-media

Pre, 19/07/2019 - 3:34pd
joining social media at DebConf19

Two days ago I joined telegram (installed via F-Droid). It was an interesting experience, immediatly I was contacted by people who had shared their addressbook with "the cloud" and thus were notified by the "heavily encrypted" telegram servers.

To quote a friend: "If you upload your address book to 'the cloud', I don't want to be in it." (And while I think so, I'm not angry for past actions. But if would like you to be considerate in the future.)

As an SMS user from 1997 until today it's very interesting to taste some of the same survailance as the rest of the the whole planet. And I have to admit, it's tasty, but consciously I know it's tasty in a bitter-sweet way. What also puzzled me that Telegram chats are unecrypted by default. In 2019.

And now let's do something about it. Or sing this karaoke version of the yellow submarine: we all live in global world surveillance, global world surveillance, global world surveillance! Cheers!

John Goerzen: The Desktop Security Nightmare

Pre, 19/07/2019 - 12:23pd

Back in 1995 or so, pretty much everyone with a PC did all their work as root. We ran graphics editors, word processors, everything as root. Well, not literally an account named “root”, but the most common DOS, Windows, and Mac operating systems of the day had no effective reduced privilege account.

It was that year that I tried my first Unix. “Wow!” A virus can’t take over my system. My programs are safe!

That turned out to be a little short-sighted.

The fundamental problem we have is that we’d like to give users of a computer more access than we would like to give the computer itself.

Many of us have extremely sensitive data on our systems. Emails to family, medical or bank records, Bitcoin wallets, browsing history, the list goes on. Although we have isolation between our user account and root, we have no isolation between applications that run as our user account. We still, in effect, have to be careful about what attachments we open in email.

Only now it’s worse. You might “npm install hello-world”, and audit hello-world itself, but get some totally malicious code as well. How many times do we see instructions to gem install this, pip install that, go get the other, and even curl | sh? Nowadays our risky click isn’t an email attachment. It’s hosted on Github with a

Not only that, but my /usr/bin has over 4000 binaries. Have every one been carefully audited? Certainly not, and this is from a distro with some of the highest quality control around. What about the PPAs that people add? The debs or rpms that are installed from the Internet? Are you sure that the postinst scripts — which run as root — aren’t doing anything malicious when you install Oracle Virtualbox?

Wouldn’t it be nice if we could, say, deny access to everything in ~/.ssh or ~/bankstatements except for trusted programs when we want it? On mobile, this happens, to an extent. But we have both a legacy of a different API on desktop, and a much more demanding set of requirements.

It feels like our ecosystem is on the cusp of being able to do this, but none of the options I’ve looked at quite get us there. Let’s take a look at some.


AppArmor falls into the “first line of defense — better than nothing” category. It works by imposing mandatory access controls on a per-executable basis. This starts out as a pretty good idea: we can go after some high-risk targets (Firefox, Chromium, etc) and lock them down. Great! Although it’s not exactly intuitive, with a little configuration, you can prevent them from accessing sensitive areas on disk.

But there’s a problem. Actually, several. To start with, AppArmor does nothing by default. On my system, aa-unconfined --paranoid lists 171 processes that have no policies on them. Among them are Firefox, Apache, ssh, a ton of Pythons, and some stuff I don’t even recognize (/usr/lib/geoclue-2.0/demos/agent? What’s this craziness?)

Worse, since AppArmor matches on executable, all shell scripts would match the /bin/bash profile, all Python programs the Python profile, etc. It’s not so useful for them. While AppArmor does technically have a way to set a default profile, it’s not as useful as you might think.

Then you’re still left with problems like: a PDF viewer should not ordinarily have access to my sensitive files — except when I want to see an old bank statement. This can’t really be expressed in AppArmor.


From its documentation, it sounds like SELinux might fit the bill well. It allows transitions into different roles after logging in, which is nice. The problem is complexity. The “notebook” for SELinux is 395 pages. The SELinux homepage has a wiki, which says it’s outdated and replaced by a github link with substantially less information. The Debian wiki page on it is enough to be scary in itself: you need to have various filesystem support, even backups are complicated. Ted T’so had a famous comment about never getting some of his life back, and the Debian wiki also warns that it’s not really tested on desktop systems.

We have certainly learned that complexity is an enemy of good security, leading users to just bypass it. I’m not sure we can rely on it.

Mount Tricks

One thing a person could do would be to keep the sensitive data on a separate, ideally encrypted, filesystem. (Maybe even a fuse one such as gocryptfs.) Then, at least, it could be unavailable for most of the time the system is on.

Of course, the downside here is that it’s still going to be available to everything when it is mounted, and there’s the hassle of mounting, remembering to unmount, password typing, etc. Not exactly transparent.

I wondered if mount namespaces might be an answer here. A filesystem could be mounted but left pretty much unavailable to processes unless a proper mount namespace is joined. Indeed that might be a solution. It is somewhat complicated, though, since nsenter requires root to work. Enter sudo, and dropping privileges back to a particular user — a not particularly ideal situation, and complex as well.

Still, it might well have some promise for some of these things.


Firejail is a great idea, but suffers from a lot of the problems that AppArmor does: things must explicitly be selected to run within it.

AppImage and related tools

So now there’s your host distro and your bundled distro, each with libraries that may or may not be secure, both with general access to your home directory. I think this is a recipe for worse security, not better. Add to that the difficulty of making those things work; I know that the Digikam people have been working for months to get sound to work reliably in their AppImage.


What other ideas are out there? I’ve occasionally created a separate user on the system for running suspicious-ish code, or even a VM or container. That’s a fair bit of work, and provides incomplete protection, but has some benefits. Still, it’s again not going to work for everything.

I hope to play around with many of these tools, especially SELinux, before too long and report back how I’ve found them to be.

Finally, I would like to be really clear that I don’t believe this issue is limited to Debian, or even to Linux. It impacts every desktop platform in wide use today. Actually, I think we’re in a better position to address it than some, but it won’t be easy for anyone.

Raphaël Hertzog: Freexian’s report about Debian Long Term Support, June 2019

Enj, 18/07/2019 - 2:08md

Like each month, here comes a report about the work of paid contributors to Debian LTS.

Individual reports

In June, 201 work hours have been dispatched among 14 paid contributors. Their reports are available:

  • Abhijith PA did 7 hours (out of 14 hours allocated plus 7 extra hours from May, thus carrying over 14h to July).
  • Adrian Bunk did 6 hours (out of 8 hours allocated plus 8 extra hours from May, thus carrying over 10h to July).
  • Ben Hutchings did 17 hours (out of 17 hours allocated).
  • Brian May did 10 hours (out of 10 hours allocated).
  • Chris Lamb did 17 hours (out of 17 hours allocated plus 0.25 extra hours from May, thus carrying over 0.25h to July).
  • Emilio Pozuelo Monfort did not provide his June report yet. (He got 17 hours allocated and carried over 0.25h from May).
  • Hugo Lefeuvre did 4.25 hours (out of 17 hours allocated and he gave back 12.75 hours to the pool, thus he’s not carrying over any hours to July).
  • Jonas Meurer did 16.75 hours (out of 17 hours allocated plus 1.75h extra hours from May, thus he is carrying over 2h to July).
  • Markus Koschany did 17 hours (out of 17 hours allocated).
  • Mike Gabriel did 9.75 hours (out of 17 hours allocated, thus carrying over 7.25h to July).
  • Ola Lundqvist did 4.5 hours (out of 8 hours allocated plus 6h from June, then he gave back 1.5h to the pool, thus he is carrying over 8h to July).
  • Roberto C. Sanchez did 8 hours (out of 8 hours allocated).
  • Sylvain Beucler did 17 hours (out of 17 hours allocated).
  • Thorsten Alteholz did 17 hours (out of 17 hours allocated).
DebConf sponsorship

Thanks to the Extended LTS service, Freexian has been able to invest some money in DebConf sponsorship. This year, Debconf attendees should have Debian LTS stickers and flyer in their welcome bag. And while we were thinking of marketing, we also opted to create a promotional video explaining LTS and Freexian’s offer. This video will be premiered at Debconf 19!

Evolution of the situation

We continue to be looking for new contributors. Please contact Holger if you are interested to become a paid LTS contributor.

The security tracker (now for oldoldstable as Buster has been released and thus Stretch became oldoldstable) currently lists 41 packages with a known CVE and the dla-needed.txt file has 43 packages needing an update.

Thanks to our sponsors

New sponsors are in bold.

No comment | Liked this article? Click here. | My blog is Flattr-enabled.

Kees Cook: security things in Linux v5.2

Enj, 18/07/2019 - 2:07pd

Previously: v5.1.

Linux kernel v5.2 was released last week! Here are some security-related things I found interesting:

page allocator freelist randomization
While the SLUB and SLAB allocator freelists have been randomized for a while now, the overarching page allocator itself wasn’t. This meant that anything doing allocation outside of the kmem_cache/kmalloc() would have deterministic placement in memory. This is bad both for security and for some cache management cases. Dan Williams implemented this randomization under CONFIG_SHUFFLE_PAGE_ALLOCATOR now, which provides additional uncertainty to memory layouts, though at a rather low granularity of 4MB (see SHUFFLE_ORDER). Also note that this feature needs to be enabled at boot time with page_alloc.shuffle=1 unless you have direct-mapped memory-side-cache (you can check the state at /sys/module/page_alloc/parameters/shuffle).

stack variable initialization with Clang
Alexander Potapenko added support via CONFIG_INIT_STACK_ALL for Clang’s -ftrivial-auto-var-init=pattern option that enables automatic initialization of stack variables. This provides even greater coverage than the prior GCC plugin for stack variable initialization, as Clang’s implementation also covers variables not passed by reference. (In theory, the kernel build should still warn about these instances, but even if they exist, Clang will initialize them.) Another notable difference between the GCC plugins and Clang’s implementation is that Clang initializes with a repeating 0xAA byte pattern, rather than zero. (Though this changes under certain situations, like for 32-bit pointers which are initialized with 0x000000AA.) As with the GCC plugin, the benefit is that the entire class of uninitialized stack variable flaws goes away.

Kernel Userspace Access Prevention on powerpc
Like SMAP on x86 and PAN on ARM, Michael Ellerman and Russell Currey have landed support for disallowing access to userspace without explicit markings in the kernel (KUAP) on Power9 and later PPC CPUs under CONFIG_PPC_RADIX_MMU=y (which is the default). This is the continuation of the execute protection (KUEP) in v4.10. Now if an attacker tries to trick the kernel into any kind of unexpected access from userspace (not just executing code), the kernel will fault.

Microarchitectural Data Sampling mitigations on x86
Another set of cache memory side-channel attacks came to light, and were consolidated together under the name Microarchitectural Data Sampling (MDS). MDS is weaker than other cache side-channels (less control over target address), but memory contents can still be exposed. Much like L1TF, when one’s threat model includes untrusted code running under Symmetric Multi Threading (SMT: more logical cores than physical cores), the only full mitigation is to disable hyperthreading (boot with “nosmt“). For all the other variations of the MDS family, Andi Kleen (and others) implemented various flushing mechanisms to avoid cache leakage.

unprivileged userfaultfd sysctl knob
Both FUSE and userfaultfd provide attackers with a way to stall a kernel thread in the middle of memory accesses from userspace by initiating an access on an unmapped page. While FUSE is usually behind some kind of access controls, userfaultfd hadn’t been. To avoid things like Use-After-Free heap grooming, Peter Xu added the new “vm.unprivileged_userfaultfd” sysctl knob to disallow unprivileged access to the userfaultfd syscall.

temporary mm for text poking on x86
The kernel regularly performs self-modification with things like text_poke() (during stuff like alternatives, ftrace, etc). Before, this was done with fixed mappings (“fixmap”) where a specific fixed address at the high end of memory was used to map physical pages as needed. However, this resulted in some temporal risks: other CPUs could write to the fixmap, or there might be stale TLB entries on removal that other CPUs might still be able to write through to change the target contents. Instead, Nadav Amit has created a separate memory map for kernel text writes, as if the kernel is trying to make writes to userspace. This mapping ends up staying local to the current CPU, and the poking address is randomized, unlike the old fixmap.

ongoing: implicit fall-through removal
Gustavo A. R. Silva is nearly done with marking (and fixing) all the implicit fall-through cases in the kernel. Based on the pull request from Gustavo, it looks very much like v5.3 will see -Wimplicit-fallthrough added to the global build flags and then this class of bug should stay extinct in the kernel.

That’s it for now; let me know if you think I should add anything here. We’re almost to -rc1 for v5.3!

© 2019, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.

Steve Kemp: Building a computer - part 2

Mër, 17/07/2019 - 8:45md

My previous post on the subject of building a Z80-based computer briefly explained my motivation, and the approach I was going to take.

This post describes my progress so far:

  • On the hardware side, zero progress.
  • On the software-side, lots of fun.

To recap I expect to wire a Z80 microprocessor to an Arduino (mega). The arduino will generate a clock-signal which will make the processor "tick". It will also react to read/write attempts that the processor makes to access RAM, and I/O devices.

The Z80 has a neat system for requesting I/O, via the use of the IN and OUT instructions which allow the processor to read/write a single byte to one of 255 connected devices.

To experiment, and for a memory recap I found a Z80 assembler, and a Z80 disassembler, both packaged for Debian. I also found a Z80 emulator, which I forked and lightly-modified.

With the appropriate tools available I could write some simple code. I implemented two I/O routines in the emulator, one to read a character from STDIN, and one to write to STDOUT:

IN A, (1) ; Read a character from STDIN, store in A-register. OUT (1), A ; Write the character in A-register to STDOUT

With those primitives implemented I wrote a simple script:

; ; Simple program to upper-case a string ; org 0 ; show a prompt. ld a, '>' out (1), a start: ; read a character in a,(1) ; eof? cp -1 jp z, quit ; is it lower-case? If not just output it cp 'a' jp c,output cp 'z' jp nc, output ; convert from lower-case to upper-case. yeah. math. sub a, 32 output: ; output the character out (1), a ; repeat forever. jr start quit: ; terminate halt

With that written it could be compiled:

$ z80asm ./sample.z80 -o ./sample.bin

Then I could execute it:

$ echo "Hello, world" | ./z80emulator ./sample.bin Testing "./sample.bin"... >HELLO, WORLD 1150 cycle(s) emulated.

And that's where I'll leave it for now. When I have the real hardware I'll hookup some fake-RAM containing this program, and code a similar I/O handler to allow reading/writing to the arduino's serial-console. That will allow the same code to run, unchanged. That'd be nice.

I've got a simple Z80-manager written, but since I don't have the chips yet I can only compile-test it. We'll see how well I did soon enough.

John Goerzen: Tips for Upgrading to, And Securing, Debian Buster

Mër, 17/07/2019 - 7:41md

Wow.  Once again, a Debian release impresses me — a guy that’s been using Debian for more than 20 years.  For the first time I can ever recall, buster not only supported suspend-to-disk out of the box on my laptop, but it did so on an encrypted volume atop LVM.  Very impressive!

For those upgrading from previous releases, I have a few tips to enhance the experience with buster.


AppArmor is a new line of defense against malicious software.  The release notes indicate it’s now enabled by default in buster.  For desktops, I recommend installing apparmor-profiles-extra apparmor-notify.  The latter will provide an immediate GUI indication when something is blocked by AppArmor, so you can diagnose strange behavior.  You may also need to add userself to the adm group with adduser username adm.


I recommend installing these packages and taking note of these items, some of which are different in buster:

  • unattended-upgrades will automatically install security updates for you.  New in buster, the default config file will also apply stable updates in addition to security updates.
  • needrestart will detect what processes need a restart after a library update and, optionally, restart them. Beginning in buster, it will not automatically restart them when in noninteractive (unattended-upgrades) mode. This can be changed by editing /etc/needrestart/needrestart.conf (or, better, putting a .conf file in /etc/needrestart/conf.d) and setting $nrconf{restart} = 'a'. Edit: If you have an Intel CPU, installing iucode-tool intel-microcode will let needrestart also check on your CPU microcode.
  • debian-security-support will warn you of gaps in security support for packages you are installing or running.
  • package-update-indicator is useful for desktops that won’t be running unattended-upgrades. I believe Gnome 3 has this built in, but for other desktops, this adds an icon when updates are available.
  • You can harden apt with seccomp.
  • You can enable UEFI secure boot.


If you hadn’t noticed, many of these items are links into the buster release notes. It’s a good document to read over, even for a new buster install.

Jonathan Dowland: Nadine Shah

Mër, 17/07/2019 - 5:45md

ticket and cuttings from gig

On July 8 I went to see Nadine Shah perform at the Whitley Bay Playhouse as part of the Mouth Of The Tyne Festival. It was a fantastic gig!

I first saw Nadine Shah — as a solo artist — supporting the Futureheads in the same venue, back in 2013. At that point, she had either just released her debut album, Love Your Dum and Mad, or was just about to (It came out sometime in the same month), but this was the first we heard of her. If memory serves, she played with a small backing band (possibly just drummer, likely co-writer Ben Hillier) and she handled keyboards. It's a pretty small venue. My friends and I loved that show, and as we talked about how good it was, what it reminded us of, (I think we said stuff like "that was nice and gothy, I haven't heard stuff like that for ages"), we hadn't realised that she was sat right behind us, with a grin on her face!

Since then shes put out two more albums, Fast Food which got a huge amount of airplay on 6 Music (and was the point at which I bought into her) and the Mercury-nominated Holiday Destination, a really compelling evolution of her art and a strong political statement.

Kinevil 7 inch

It turns out, though, that I think we saw her before that, too: A local band called Kinevil (now disbanded) supported Ladytron at Digital in Newcastle in 2008. I happen to have their single "Everything's Gone Black" on vinyl (here it is on bandcamp) and noticed years later that the singer is credited as Nadine Shar.

This year's gig was my first gig of 2019, and it was a real blast. The sound mix was fantastic, and loud. The performance was very confident: Nadine now exclusively sings, all the instrument work is done by her band which is now five-strong. The saxophonist made some incredible noises that reminded me of some synth stuff from mid-90s Nine Inch Nails records. I've never heard a saxaphone played that way before. Apparently Shah has been on hiatus for a while for personal reasons and this was her comeback gig. Under those circumstances, it was very impressive. I hope the reception was what she hoped for.

Holger Levsen: 20190716-wanna-work-on-lts

Mar, 16/07/2019 - 5:56md
Wanna work on Debian LTS (and get funded)?

If you are in Curitiba and are interested to work on Debian LTS (and get paid for that work), please come and talk to me, Debian LTS is still looking for more contributors! Also, if you want a bigger challenge, extended LTS also needs more contributors, though I'd suggest you start with regular LTS

On Thursday, July 25th, there will also be a talk titled "Debian LTS, the good, the bad and the better" where we plan to present what we think works nicely and what doesn't work so nicely yet and where we also want to gather your wishes and requests.

If cannot make it to Curitiba, there will be a video stream (and the possibility to ask questions via IRC) and you can always send me an email or ping on IRC if you want to work on LTS.