Re: systemd-dev package in bookworm?
In days of yore (Wed, 15 May 2024), Sirius thus quoth: > Thank you. I will update later with results for kernel 6.9.0 and Xen > 4.18.2, how they work together. Quick feedback: it works, although I am seeing some weird log-spewing when I run things like aptitude and apt-get search. I will persist, but it is a bit temperamental. Quick feedback II: I am getting bitten by a kernel-bug akin to some of these: [1][2] - and from what I can tell, it is not resolved yet. I need to look into where and how those locks get triggered and if there is something I can switch off in the kernel to work around it until the issue is fixed. [1]: https://bugzilla.kernel.org/buglist.cgi?cmdtype=runnamed_id=1140725=folio_wait_bit_common [2]: https://patchwork.kernel.org/project/fstests/patch/20240418001356.95857-1-mcg...@kernel.org/ -- Kind regards, /S
Re: systemd-dev package in bookworm?
In days of yore (Wed, 15 May 2024), Simon Richter thus quoth: > Hi, Hello Simon, > On 5/15/24 10:31, Sirius wrote: > > >Where is the systemd-dev package for regular Bookworm? The only package > >that show up is systemd-dev/stable-backports 254.5-1~bpo12+3 all and if > >I try and install that, it seems like it wants to uninstall most of my > >system in the process. > > The version shipped in bookworm did not yet build a separate -dev package. Understood. After I cloned the Xen git repo and started looking in more detail, I did find that Bookworm has a libsystemd-dev package and that seems to satisfy the Xen build dependencies. So I have a compile running now of 4.18.2. > This package was introduced in > > systemd (253-2) experimental; urgency=medium > > * Add systemd-dev package for pkg-config files. Move systemd.pc and > udev.pc to systemd-dev, so that packages can build-depend on a small > package instead of the whole set of binaries. (Closes: #945922, > #917549) > > -- Luca Boccassi Mon, 12 Jun 2023 00:22:52 +0100 Okay, so for the next Stable, there will be a systemd-dev package. > For older versions, you can find systemd.pc and udev.pc in the main > systemd package; the other files like interface definitions are not > shipped at all in the packages in bookworm. > > If you just need the .pc files, just add the old systemd package as an > alternative to the build dependencies. > > Build-Depends: systemd-dev | systemd (<< 253-2) Thank you. I will update later with results for kernel 6.9.0 and Xen 4.18.2, how they work together. -- Kind regards, /S
systemd-dev package in bookworm?
Good morning/day/evening, TL;DR version Where is the systemd-dev package for regular Bookworm? The only package that show up is systemd-dev/stable-backports 254.5-1~bpo12+3 all and if I try and install that, it seems like it wants to uninstall most of my system in the process. Roundabout version I have to, for work, mess around a lot with OSTree, and most of that work I have punted out into VMs. For unknown reasons, iSCSI stopped working from my two NAS, so I ended up learning about Kerberos and eventually got KDC running and with that, krb5-NFS4 from the NAS' to my workstation and virt-hosts. VMs are qcow2 images in an NFS4 share mounted on my two Intel NUC virt-hosts and workstation so I can migrate VMs. Bookworm 6.1 kernel has major issues with that, giving hung task timeouts that render the VM unresponsive and leave the qemu process unkillable. Tried the 6.6 kernel for Bookworm and that has the same issue. Upstream 6.8.9 and 6.9.0 does not have that issue, but in the process of building that, I understood that Xen might now be another virt option open. However - the Xen shipped in Bookworm has *major* issues with kernel 6.8.9 or 6.9. As in 1.1TiB of system-logs in three hours and numerous reboots major. Sooo.. I am looking for the systemd-dev package for Bookworm so that I can build the latest upstream Xen that *hopefully* does not generate quite so much logs. KVM does work fine, but I like to tinker with things and it has been a while since I used Xen (employer reasons) so I want to reacquaint myself with it. This is why I am asking about systemd-dev. All the other Xen dependencies seems to be available, so this is the last piece of the puzzle. -- Kind regards, /S
Re: Debian 12 released with two RC bugs in Sylpheed
In days of yore (Sun, 07 Apr 2024), José Luis González thus quoth: > Hi, > > Debian 12 was released with two Release Critical bugs I filed on May > 20th 2023 (#1036424 and #1036388) on Sylpheed about issues that I > found on stable, and remain, with Debian 12 released later on June 10th > 2023. So, bug #1036424 is a problem that when you reply to an email, it does not set the From account properly, it uses the default account. That is perhaps a usability defect, but it is not a critical impact defect by any stretch of the imagination. Critical is usually reserved for things like remote exploit, data corruption, or otherwise, you know, critical issues. The other bug, #1036388, has a little more meat on it, but still does not meet the criteria of Critical. Looking at it on the scale of Critical, Important, Medium and Low, I think it warrants Important if I understand the problem description right. Which, correct me if I am wrong, is: - Configure Sylpheed with account A and sender u...@a.com - Configure Sylpheed with additional account B and sender u...@b.com - Account A is default, but we switch to account B for the session. - When a new mail for Account A is received, it is placed in Account B's folders. Okay, that would be an annoying issue. But the bug was addressed. The issue was resolved in Sylpheed 3.8.0~beta1-1. For all I know, the issue was complex and non-trivial to backport to version 3.7.0. I am not the package maintainer, nor the upstream developer, so I am not about to yell at them when they actually produced the fix. To put a perspective on this - I use mutt, with at least four separate email accounts, all receiving email and ultimately pooling into my mailserver. When I send email, I do need to check that I am actually sending as the correct persona as mutt does guess who to send as, but it does not always get it right. Has it led to me sending emails with the wrong sender? Yep. And I apologise when it happens and move on, re-rending with the correct sender. I do not consider this to be a defect in mutt as mutt has never advertised that it will get its guesses of who to send as 100% right when there are more than one account configured as I have it set up. Also - a question that is rhetorical and more food for thought: How much are you paying for your Debian subscription and support per year? -- Kind regards, /S
Re: xz backdoor
In days of yore (Fri, 05 Apr 2024), Daniel Leidert thus quoth: > Am Freitag, dem 29.03.2024 um 23:20 +0100 schrieb Moritz Mühlenhoff: > > Russ Allbery wrote: > > > I think this question can only be answered with reverse-engineering of the > > > backdoors, and I personally don't have the skills to do that. > > > > In the pre-disclosure discussion permission was asked to share the payload > > with a company specialising in such reverse engineering. If that went > > through, I'd expect results to be publicly available in the next days. > > If there is a final result, can we as a project share the results on a > prominent place? Or at least under d-devel-announce and/or d-security- > announce? I was also wondering about what could have been compromised, > what data might have been stolen, etc. And there is so many sources to > follow right now. So sharing the final results would be great. If you have followed the discussion on Openwall ML, there have been a couple of posts that points at both a general overview of what the code did, an analysis of how the data was hidden in the 'corrupt' xz archive under testing and some analysis of the actual .o which suggested this was not just a backdoor but a remote-code-execution portal almost. It has been interesting reading for sure, and the way they hid it, it does really not look like your average script-kiddie doing this. I have my own private suspicions about potential culprits being behind this but I figure it is wiser to keep that under my hat as it were. By the looks of things, both here and elsewhere, this was caught just in the nick of time, meaning it did not make it out into the wild (at least true for Debian and Fedora) so nothing was compromised. It it eerie the parallels to Clifford Stoll and The Cuckoo's Egg though. I second the request for sharing "final results" but I recognise that it may be weeks still before that may happen. -- Kind regards, /S
Re: Debian openssh option review: considering splitting out GSS-API key exchange
In days of yore (Tue, 02 Apr 2024), Colin Watson thus quoth:
> TCP wrappers
>
Not used hosts.{allow,deny} for the last 17 years (since I started my
current employment) so I am biased. Honest opinion is that firewall and
fail2ban have pretty much obsoleted TCP wrappers.
> SELinux
> ===
>
> For the time being my inclination is to leave this be, but I've seen the
> suggestion that pam_selinux is basically all you need
> (https://infosec.exchange/@alwayscurious/112192949171400643), so maybe
> it would be an option to drop --with-selinux in favour of that? I've
> never used SELinux, so I'd need an expert to weigh on here.
If you need an expert on SELinux, you need Dan Walsh.
I have used SELinux for the last 17 years, from when it was a monolithic
policy to what it is like today in RHEL. SELinux is - as far as I know -
not an issue and have a fail-close rather than fail-open approach. IMHO,
if it is not used and you have the time to spare to drop it, do, otherwise
it should be safe with the status-quo on this.
And should Debian pick SELinux up fully and enable a targeted policy,
well, you will want this anyway.
--
Kind regards,
/S
Re: xz backdoor
In days of yore (Sun, 31 Mar 2024), Colin Watson thus quoth: > On Sun, Mar 31, 2024 at 10:10:42AM +0200, Sirius wrote: > > Not worth boiling the ocean over, but is there an estimate of how many > > packaged projects have customisations to their autoconf that is not found > > in the upstream autoconf project? If that number is low single digit > > percent, it may motivate those projects to upstream their modifications. > > If it is double digits percent, it might not be possible to disallow > > vendoring the files. > > This is difficult to answer because it's comparing apples and oranges to > some extent: not all autoconf customizations are vendored or would make > any kind of sense to upstream. For example, > https://gitlab.com/man-db/man-db/-/blob/main/m4/man-arg-config-file.m4 > is obviously specific to that project; it's just in a separate file for > the same reasons that projects past a certain size don't typically put > all their code in a single file. > > I suspect the question you're aiming for is something like "how many > packaged projects have copied autoconf macros from elsewhere and > modified them but kept the same file names, so that a naïve attempt to > update them would drop those modifications". My guess is that the > number here is very low - IME it's much more common in such cases to > either rename the macro file to be obviously project-specific or to find > some workaround that doesn't require changing the upstream macro - but > I've never seen anything resembling a robust analysis of this and I may > well have a skewed view. I find this interesting, even if it is a question that simply does not have a reasonable answer unless one goes and does the audit. Your rephrasing is actually closer to what I was aiming at - but that opens another question that may not have a reasonable answer: Would throwing away these unmodified (?) macros packaged projects may be carrying for hysterical raisins in favour of just using the autoconf native macros reduce the attack-surface a potential malicious actor would have at their disposal, or would it simply be a "putting all eggs in one basket" and just make things worse? And by how much vis-a-vis the effort to do it? I think that what I am trying to get at is this: is there low-hanging fruit that for minimal effort would disproportionately improve things from a security perspective. (I have an inkling that this is a question that every distribution is wrestling with today.) My apologies if I am asking too many questions. It has been a long time since I was using Debian (2004), but I am standing up environments and looking at how I may be able to put some of my sparse spare time to good use. So I am looking to learn (by doing) how to package things. I am building my own .deb of mutt (because I want a few things that the official package does not have) but am looking for "the right way" to do it. Just because I built it and it is running does not mean I have done it right. :-) -- Kind regards, /S
Re: xz backdoor
In days of yore (Sun, 31 Mar 2024), Bastian Blank thus quoth: > On Sat, Mar 30, 2024 at 08:15:10PM +, Colin Watson wrote: > > On Sat, Mar 30, 2024 at 05:12:17PM +0100, Sirius wrote: > > > I have seen discussion about shifting away from the whole auto(re)conf > > > tooling to CMake or Meson with there being a reasonable drawback to CMake. > > > Is that something being discussed within Debian as well? > > It's not in general something that Debian can unilaterally change. And > > in a number of cases switching build system would be pretty non-trivial. > > What we can do unilaterally is to disallow vendoring those files. > > Does it help? At least in the case of autoconf it removes one common > source of hard to read files. Reduction of complexity is IMHO always worthwhile as it would open the door for more people being able to step up as maintainers (taking into account that volunteers right this minute might not be overly welcome and when they are, they should likely not be near authentication, crypto and compression at least initially). Not worth boiling the ocean over, but is there an estimate of how many packaged projects have customisations to their autoconf that is not found in the upstream autoconf project? If that number is low single digit percent, it may motivate those projects to upstream their modifications. If it is double digits percent, it might not be possible to disallow vendoring the files. -- Kind regards, /S
Re: xz backdoor
In days of yore (Fri, 29 Mar 2024), Russ Allbery thus quoth: > Russ Allbery writes: > > Sirius writes: > > >> This is quite actively discussed on Fedora lists. > >> https://www.openwall.com/lists/oss-security/2024/ > >> https://www.openwall.com/lists/oss-security/2024/03/29/4 > > >> Worth taking a look if action need to be taken on Debian. > > > The version of xz-utils was reverted to 5.4.5 in unstable yesterday by > > the security team and migrated to testing today. Anyone running an > > unstable or testing system should urgently upgrade. > > I think the big open question we need to ask now is what exactly the > backdoor (or, rather, backdoors; we know there were at least two versions > over time) did. If they only target sshd, that's one thing, and we have a > bound on systems possibly affected. But liblzma is linked directly or > indirectly into all sorts of things such as, to give an obvious example, > apt-get. A lot of Debian developers use unstable or testing systems. If > the exploit was also exfiltrating key material, backdooring systems that > didn't use sshd, etc., we have a lot more cleanup to do. > > I think this question can only be answered with reverse-engineering of the > backdoors, and I personally don't have the skills to do that. >From what I understand and have read, there is someone that will take a look at reverse-engineering the .o and figure out what it did. The fact the exploit looked for /usr/bin/sshd as argv[0] suggests it was targeted at providing a backdoor into systems via just sshd. To what end, I guess we will find out. Botnet would be the least worrisome IMHO. A striking aspect is that this exploit was slow and methodical. This was no ordinary script-kiddie doing things for giggles. I do wonder what will shake out of this, but this level of patience and planning does raise questions. As you point out, the compression libraries are a weak link. I would think the authentication and crypto libraries are as well. In this instance, maybe both Debian and Fedora can breathe a sigh of relief that things got caught when they did and that the remediation is not man-months or man-years worth of effort. That said, someone plowing this amount of time into planting just the one exploit may have other projects sized up where they can try again. I have seen discussion about shifting away from the whole auto(re)conf tooling to CMake or Meson with there being a reasonable drawback to CMake. Is that something being discussed within Debian as well? -- Kind regards, /S
xz backdoor
Hi there, This is quite actively discussed on Fedora lists. https://www.openwall.com/lists/oss-security/2024/ https://www.openwall.com/lists/oss-security/2024/03/29/4 Worth taking a look if action need to be taken on Debian. -- Kind regards, /S
