User NS usage and attack surface mitigation on debian
I stumbled upon this answer from three years ago (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898446) "User namespaces *are* enabled - but by default, they can only be created by root". I need clarifications on that, cause I didn't quite know how namespace management works. I experimented a bit, from what I got it creates a namespace originating from the user asking it, and using it as normal user was disabled by default because it clearly adds lots of attack surface by exposing code that would normally be used by just root. Also in this little space there is a mapping between namespace users and originating user What I didn't quite got is, does this patch allow creating namespaces belonging to an user from root, thus avoiding the possibility of privilege escalation, or having user namespaces running from unprivileged users is a threat by itself? I ask this because I'm particularly concerned about unprivileged containers support. While it is certainly good not having access to critical pieces of the linux kernel to regular UIDs it may be counterproductive in cases of a single user deputated just for running unprivileged containers, if there is no other way of creating such unprivileged namespaces If there are some infos I'm missing please explain them or link resources, I searched what I could but apparently it wasn't enough
Bug#986822: BUG#986822 Broadwell SST CATPT Sound module
Hi Vincent I'll kill the pipewire server, i would uninstall the packages but they are hard deps for gnome now. Is the fw file catpt is trying to load the correct one? Is there new fw files that come with catpt that have been forgotten? Is there a listiing for the error codes -110 and -2, are they missing files or read permission issues? Regards. On Sun, 13 Jun 2021 at 18:08, Vincent Blut wrote: > Hi, > > Le 2021-06-05 08:31, Dekks Herton a écrit : > > Hi > > > > Additional alsa-info script output > > From a quick look, alsa-info reports that you're running both PipeWire and > PulseAudio sound servers. While it may not be the root cause of your issue, > if you want to stick with the former, please disable the latter: > $ sudo systemctl --user disable --now pulseaudio.service pulseaudio.socket > > Note though that using PipeWire as a substitute to PulseAudio/JACK/ALSA in > Debian 11 is considered experimental. > > Cheers, > Vincent >
Re: "tweewide: Fix most Shebang lines" in stable updates
Hi Ben, On Tue, Jun 15, 2021 at 12:52:31AM +0200, Ben Hutchings wrote: > Commit c25ce589dca10d64dde139ae093abc258a32869c "tweewide: Fix most > Shebang lines" was backported to stable branches including 4.9 and > 4.19. This changes scripts interpreted by bash, perl, and python to > use /usr/bin/env instead of an absolute path to the interpreter. > > I think that this carries some risk of regression for users building > custom kernels or out-of-tree module. So perhaps we should revert it > for stretch and buster? When this was asked for backporting and then queued for stable series I was indeed worried this might cause issues. Other have raised as well concern, but it was then appied. https://lore.kernel.org/stable/yjvc2w9qtpc9j...@kroah.com/ and then https://lore.kernel.org/stable/20210520203625.GA6187@amd/ How about the following: keep it as close to upstream, in case we get reports, try again to convince upstream to revert the changes as unsuitable for a stable series. Otherwise we would have to diverge. But personally I would prefer to remain as close as possible to upstream. Regards, Salvatore
Bug#989551: linux-image-5.10.0-7-amd64: linux-image-5.10.0.7-amd64 hang on boot. Shows symbols: '^@^@^@' and nothing else. Debian testing.
Hi, On Tue, Jun 15, 2021 at 10:05:29AM +0300, Михаил Осипов wrote: > Sorry, missed this message. Here are the logs. Several boots with and > without recovery mode. Last one with old kernel. Thanks for provinding those, much appreciated and it helps. So from the boot logs this might be amdgpu related. Am I correct, you can reach the host after bootup via a SSH login? Would you be able to: - Test directly upstream both 5.10.28, 5.10.40 (and 5.10.44 to be relased tomorrow)? - If triggerable between 5.10.28 and 5.10.44: bisect to find the introducing upstream commit? Some indication on how to build: https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html and https://wiki.debian.org/DebianKernel/GitBisect Regards, Salvatore
Re: release notes mentioning dropped support?
wOn Mon, 2021-06-14 at 06:25 +0100, Justin B Rye wrote: > Paul Gevers wrote: > > + > > + Hardware that's no longer supported > > The contraction "that's" seems out of place in a title - probably we > should just use: > > No longer supported hardware > That would correctly be spelt with hyphens: No-longer-supported hardware > > + > > + Due to hardware limitations, it's no longer viable for Debian > > + to build the Linux kernel supporting a > > + number of armel based devices that were supported in > > + buster. The unsupported devices are: > > This sounds as if it's talking about one kernel supporting multiple > armel-based devices; if it means one kernel per device, that's plural. We've used only a single kernel flavour (marvell) for these devices since before the stretch release. [...] > > + Users of those platforms that wish to upgrade to bullseye > > + nevertheless should keep the buster APT sources enabled and, > > + before upgrading, add an APT preferences file containing > > + something like: > > Users of these platforms who wish to upgrade to bullseye > nevertheless should keep the buster APT sources enabled, and > before upgrading should add an APT preferences file containing > something like: > > (Or maybe as two sentences, "Before upgrading they should...") Also we should not say "something like" since that suggests that some system-specific adjustment is needed. I originally included those words because I hadn't tested this configuration, but Paul said he will. > > > + > > +Package: linux-image-marvell > > +Pin: release a=buster > > +Pin-Priority: 900 > > + > > + Obviously, the security support for this configuration will > > + end with the End Of Life of buster. > > Obviously, the security support for this configuration will > only last until buster's End Of Life. We (generally) shouldn't say "obviously" in documentation - if we bothered to document it, it must not be that obvious. Ben. -- Ben Hutchings Kids! Bringing about Armageddon can be dangerous. Do not attempt it in your own home. - Terry Pratchett and Neil Gaiman, `Good Omens' signature.asc Description: This is a digitally signed message part
