Re: systmd-analyze security as a release goal
On Thu, Jul 13, 2023 at 08:03:39PM +0200, Timo Röhling wrote: > qemu is basically an interpreter for foreign machine code. If your > threat model allows access to qemu-user-static for an attacker, they > can run pretty much any binary is if it were native, and the whole > SystemCallArchitectures hardening becomes meaningless. My understanding of the threat is that compatibility syscalls (eg, x32 on amd64) are less well-tested than the local architecture syscalls, and so allowing apps to call them increases the risk - a compromised app that can make compatibility syscalls stands a higher probability of being able to elevate privileges, either in userland or to the kernel itself. Allowing qemu to translate syscalls from other architectures to the local syscall ABI doesn't increase that risk, so isn't a concern. The goal isn't to prevent code form other architectures from running, it's to reduce the attack surface by preventing calls to the compatbility syscalls.
Re: systmd-analyze security as a release goal
On Fri, Jul 14, 2023 at 08:08:39AM +0100, Matthew Garrett wrote: > On Thu, Jul 13, 2023 at 08:03:39PM +0200, Timo Röhling wrote: > > qemu is basically an interpreter for foreign machine code. If your > > threat model allows access to qemu-user-static for an attacker, they > > can run pretty much any binary is if it were native, and the whole > > SystemCallArchitectures hardening becomes meaningless. > > My understanding of the threat is that compatibility syscalls (eg, x32 > on amd64) are less well-tested than the local architecture syscalls, and > so allowing apps to call them increases the risk - a compromised app > that can make compatibility syscalls stands a higher probability of > being able to elevate privileges, either in userland or to the kernel > itself. Allowing qemu to translate syscalls from other architectures to > the local syscall ABI doesn't increase that risk, so isn't a concern. > The goal isn't to prevent code form other architectures from running, > it's to reduce the attack surface by preventing calls to the > compatbility syscalls. Not just that, but also using compatibility syscalls allows circumventing other systemd hardening that filters syscalls (RestrictAddressFamilies=, MemoryDenyWriteExecute=, SystemCallFilter=). Allowing qemu also doesn't make much difference either way to that though - if your process can't make a syscall directly, it can't make it via qemu either. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: /usr-merge: continuous archive analysis
Hi Helmut, thanks for your continuious work on this! On Wed, Jul 12, 2023 at 03:34:38PM +0200, Helmut Grohne wrote: > To make matters worse, an upload to bookworm-backports > is immediately available to users and there is no migration that some > check (such as dumat) could hook into. there is NEW processing however and every package going into bookworm-backports needs to go through it... and granted, once it's in there no more NEW processing (unless $conditions), so this not perfect but it's more than nothing. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ I’ve said it once, and I’ll say it a thousand times: If the penalty for breaking a law is a fine, then that law only exists for the poor. signature.asc Description: PGP signature
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Wed, Jul 12, 2023 at 8:32 AM Lukas Märdian wrote: > (We're also working on a bidirectional Netplan-NetworkManager integration, > that allows NM to feed back it's configuration into Netplan YAML format. It is > a small patch for NetworkManager and is purely optional.) Does that already exist in Ubuntu 23.10 "Mantic"? Thank you, Jeremy Bícha
Re: Future of GNU/kFreeBSD in the debian-ports archive
Dear all, On 2023-05-29 18:11, Aurelien Jarno wrote: > Dear GNU/kFreeBSD porters, > > Over the past year, GNU/kFreeBSD hasn't seen any significant > development. After reaching out to various individuals involved, it > seems unlikely that the situation will change in the foreseeable future. > Here are some statistics that support this observation: > > - The last buildd upload for kfreebsd-amd64 and kfreebsd-i386 was over a > year ago. > - There have been no porter uploads for kfreebsd-i386 in the past year. > - In the last year, only 11 porter uploads for kfreebsd-amd64 have been > recorded, with the most recent one occurring over two months ago. > - Only approximately 30% of the packages on these architectures are > up-to-date. > > With my ports-master hat, I think it is time to consider the removal of > both the kfreebsd-amd64 and kfreebsd-i386 architectures from the > debian-ports archive. I would like to emphasize that packages will still > be available on snapshot.d.o for anyone interested in reviving the port. > > In any case, I am waiting for feedback, and I will wait for at least a > month before taking any action. This has now happened, the kfreebsd-amd64 and kfreebsd-i386 ports have been removed from the debian-ports archive. Technically only the indexes are gone for now, but the packages will gradually disappear over the next days to avoid triggering the maximum deletion protection on the mirrors. The packages will still be available on snapshot.debian.org for instance on: http://snapshot.debian.org/archive/debian-ports/20230705/ Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net signature.asc Description: PGP signature
Re: Fwd: Wayland and NVidia driver conflict
debian-user and debian-desktop are both good lists for this question. It is off-topic for debian-devel. Anyone who answers, please remove debian-devel from the replies. (Sorry, I don't have an answer for you.) Thanks...Marvin
Bug#1041093: ITP: golang-github-go-zookeeper-zk -- native ZooKeeper client for Go
Package: wnpp Severity: wishlist Owner: Daniel Swarbrick X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: golang-github-go-zookeeper-zk Version : 1.0.3-1 Upstream Contact: The Go-ZooKeeper Developers * URL : https://github.com/go-zookeeper/zk * License : BSD-3-clause Programming Lang: Go Description : native ZooKeeper client for Go Native Go ZooKeeper Client Library. This is (yet another) fork of the original g/samuel/go-zookeeper package, and is a build-dep of Prometheus (which currently uses a patch to build against the original g/samuel/go-zookeeper). Since the original g/samuel/go-zookeeper is now abandoned / archived, g-g-samuel-go-zookeeper-dev could eventually become a dummy transitional package for g-g-go-zookeeper-zk-dev, with symlinks. I will co-maintain this package as a member of the Debian Go Packaging Team.
Empty Contents files for bookworm-updates
Hi, it’s Markus, …snip Index of /debian/dists/bookworm-updates/main [ICO] NameLast modified Size [PARENTDIR] Parent Directory- [DIR] Contents-all.diff/ 2023-07-14 20:38- [ ] Contents-all.gz 2021-08-14 10:4920 [DIR] Contents-amd64.diff/2023-07-14 20:38- [ ] Contents-amd64.gz 2021-08-14 10:4920 [DIR] Contents-arm64.diff/2023-07-14 20:38- [ ] Contents-arm64.gz 2021-08-14 10:4920 ... snap... The size of the gz files is 20, i.e. the unzipped files are empty. Is this by purpose? Best Regards, Markus
Re: Empty Contents files for bookworm-updates
On 2023-07-15 Markus Falb wrote: > Hi, it’s Markus, > …snip > Index of /debian/dists/bookworm-updates/main [...] > The size of the gz files is 20, i.e. the unzipped files are empty. > Is this by purpose? Afaict (from looking at the Packages files) there are no Packagages yet in bookworm-updates/main. So yes. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
