Re: making Debian secure by default

[DdB]

Am 27.03.2024 um 22:30 schrieb Lee:
> oof.  Are there instructions somewhere on how to make Debian secure by 
> default?

To be honest: I did not read this thread, as my spidey senses got
tingling. IMHO Even the idea/concept, that such a thing would be
possible, is broken.

Sounds like: Get me a car, that never kills anybody, no matter how
stupid the driver is... (impossible).

But to slow it down a bit:
As a former software engeneer, i learned quite a few things, among the
important ones were the lessons around "Cleanliness" (donno, if this
word even exists).

>From time to time, even experienced devs come across a choice:
Either, they work on very clean contracts between software parts, which
in an ideal world lead to good interfaces, but this makes some difficult
tasks impossible, as it may be impossible to agree upon such a contract
with everyone involved (or the whole world).
Or, they lean more towards what is feasible, preferring tricking or
evading from contracts, like what most hackers do.
My own recipe in such cases, was to feel my inner work ethic and to
trust it more than anything. But i do understand, that such a solution
is bound to be changing and thus is not really a good solution in general.

But that leaves us with:
There is no way, a secure system will ever come to be. We need to take
responsability for what we are doing, as even a hammer can be used to
kill. Sorry, that means we have to use our brains, learn from mistakes
and do the best we can without falling asleep.

Just my 2 cents
DdB

Re: making Debian secure by default

[tomas]

On Mon, Apr 01, 2024 at 03:19:18PM -0500, Nate Bargmann wrote:
> * On 2024 01 Apr 14:01 -0500, Andy Smith wrote:

[...]

> Until now, who anticipated this?  I'm sure there are security
> researchers who have and it's likely that I'm not well-read enough on
> this topic to have seen it discussed.  How many people did it occur to
> that when A links to B and B links to C that C can create a
> vulnerability in A?  That is what I understand happened here.

This pattern has been seen in other contexts. Here [1] is a good review
of "supply chain attacks", which unsurprisingly happen most often in
decentrally managed package distributions which at the same time have
"production environments" where time-to-deploy is the main mover: npm,
PyPi and RubyGems. If you don't have the time to even consider what the
hundreds of packages you're ploughing into your app actually do, this
is no surprise.

So yes, the pattern was known. It was, up to now, pretty unusual in
this context. But the deeper "the stack" becomes... (so I think Nate
had a point. That Andy read that as a "systemd insult" is IMHO
infortunate, because it clogs a potentially useful discussion. But
there you are).

The next level is using a package phantasized by your trusty "AI" [2]
counsellor (and whose name was predicted by a malicious actor, because 
"AI" tends to phantasize names consistently). Note that this one was
just (yet?) a proof of concept.

Cheers

[1] https://arxiv.org/abs/2005.09535
[2] 
https://www.theregister.com/2024/03/28/ai_bots_hallucinate_software_packages/
-- 
tomás


signature.asc
Description: PGP signature

Re: making Debian secure by default

[tomas]

On Mon, Apr 01, 2024 at 07:00:29PM +, Andy Smith wrote:
> Hi,
> 
> On Mon, Apr 01, 2024 at 03:33:37AM -0500, Nate Bargmann wrote:
> > From what I have read, lzma is not a direct dependency of openssh.  It
> > turns out that it lzma is a dependency of libsystemd and that
> > relationship affected openssh.
> > 
> > Jacob Bachmeyer in analysis
> > (https://lists.gnu.org/archive/html/automake/2024-04/msg0.html)
> > says:
> > 
> > Lastly on this topic, some of the blame for this needs to fall on the
> > systemd maintainers [...]

> In my view a great example of the "people other than me just need to
> get good" fallacy merged with the group of people predisposed to
> hate systemd.

[...]

Please, don't make this into a systemd flamefest. W've had our share
of this already.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Bookworm: Where are the ImageMagick binaries other than `convert`?

[Bruno Kleinert]

Am Dienstag, dem 02.04.2024 um 13:35 +1030 schrieb Christian Gelinek:
> Thank you all for your responses.
> 
> On 2/4/24 12:41, Greg Wooledge wrote:
>  > On Mon, Apr 01, 2024 at 10:06:40PM -0400, e...@gmx.us wrote:
>  >
>  > The command-line equivalent is "dpkg -L", to list the files that belong
>  > to an installed package.
> 
> I should note that down somewhere... I'm sure I've come across it before.

I recommend the 'Debian Reference Card' which is in package debian-
refcard. It lists the 'apt-file list' command as an alternative to dpkg
-L, and that works even on packages that are not installed.


signature.asc
Description: This is a digitally signed message part

Re: Bookworm: Where are the ImageMagick binaries other than `convert`?

[Christian Gelinek]

Thank you all for your responses.

On 2/4/24 12:41, Greg Wooledge wrote:
> On Mon, Apr 01, 2024 at 10:06:40PM -0400, e...@gmx.us wrote:
>
> The command-line equivalent is "dpkg -L", to list the files that belong
> to an installed package.

I should note that down somewhere... I'm sure I've come across it before.

> In any case, there is no command named "magick".

Thanks, I was interested in the `magick identify` command referred to 
[here][0] which becomes just `identify` in this case.


[0]: https://stackoverflow.com/a/73406928/897968

Re: Bookworm: Where are the ImageMagick binaries other than `convert`?

[Charles Curley]

On Tue, 2 Apr 2024 12:07:47 +1030
Christian Gelinek  wrote:

> I have ImageMagick installed, but only the `convert` binary is in my
> path.
> 
> Other binaries like `magick` are not. Where can I find them, why
> aren't they installed?

man imagemagick

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: Bookworm: Where are the ImageMagick binaries other than `convert`?

[Greg Wooledge]

On Mon, Apr 01, 2024 at 10:06:40PM -0400, e...@gmx.us wrote:
> On 4/1/24 21:37, Christian Gelinek wrote:
> > Hi,
> > 
> > I have ImageMagick installed, but only the `convert` binary is in my path.
> > 
> > Other binaries like `magick` are not. Where can I find them,
> 
> In Synaptic, if you get the properties of an installed package one of the
> tabs is "installed files".  You can find out where (or whether) those things
> are actually installed.

The command-line equivalent is "dpkg -L", to list the files that belong
to an installed package.

In the specific case of imagemagick, things get a little bit weird:

hobbit:~$ dpkg -L imagemagick-6.q16 | grep bin/
/usr/bin/animate-im6.q16
/usr/bin/compare-im6.q16
/usr/bin/composite-im6.q16
/usr/bin/conjure-im6.q16
/usr/bin/convert-im6.q16
/usr/bin/display-im6.q16
/usr/bin/identify-im6.q16
/usr/bin/import-im6.q16
/usr/bin/mogrify-im6.q16
/usr/bin/montage-im6.q16
/usr/bin/stream-im6.q16

And these are pointed to by symlinks in the "alternatives" system:

hobbit:~$ ls -l /usr/bin/convert
lrwxrwxrwx 1 root root 25 Feb 12 15:15 /usr/bin/convert -> 
/etc/alternatives/convert*
hobbit:~$ ls -l /etc/alternatives/convert
lrwxrwxrwx 1 root root 24 Feb 12 15:15 /etc/alternatives/convert -> 
/usr/bin/convert-im6.q16*

In any case, there is no command named "magick".

Re: Bookworm: Where are the ImageMagick binaries other than `convert`?

[eben]

On 4/1/24 21:37, Christian Gelinek wrote:

Hi,

I have ImageMagick installed, but only the `convert` binary is in my path.

Other binaries like `magick` are not. Where can I find them,


In Synaptic, if you get the properties of an installed package one of the
tabs is "installed files".  You can find out where (or whether) those things
are actually installed.

> why aren't they
> installed?

Maybe they are.

--
CAPRICORN:  The stars say you're an exciting and wonderful person... but
you know they're lying.  If I were you, I'd lock my doors and windows
and never never never never never leave my house again.  -- Weird Al

Bookworm: Where are the ImageMagick binaries other than `convert`?

[Christian Gelinek]

Hi,

I have ImageMagick installed, but only the `convert` binary is in my path.

Other binaries like `magick` are not. Where can I find them, why aren't 
they installed?


Thanks,
Christian

Re: making Debian secure by default

[Nate Bargmann]

* On 2024 01 Apr 16:55 -0500, Charles Curley wrote:
> On Mon, 1 Apr 2024 19:00:29 +
> Andy Smith  wrote:
> 
> > In my view a great example of the "people other than me just need to
> > get good" fallacy merged with the group of people predisposed to
> > hate systemd.
> > 
> > It could have been any direct or indirect dependency of sshd here.
> > I'm quite sure almost none of them have the required resources and
> > processes to detect something like this.
> 
> Easy, now. No-one is attacking systemd, and I don't think anyone wanted
> to start a systemd war. This could also have happened under System V
> initialization.

AIUI (please correct me if I am in error), any dependency chain that
then depends on something else could create a vulnerability.  I am
rather surprised to see that openssh-server has so many dependencies:

Depends: adduser, libpam-modules, libpam-runtime, lsb-base,
openssh-client (= 1:9.2p1-2+deb12u2), openssh-sftp-server, procps, ucf,
debconf (>= 0.5) | debconf-2.0, runit-helper (>= 2.14.0~), libaudit1 (>=
1:2.2.1), libc6 (>= 2.36), libcom-err2 (>= 1.43.9), libcrypt1 (>=
1:4.1.0), libgssapi-krb5-2 (>= 1.17), libkrb5-3 (>= 1.13~alpha1+dfsg),
libpam0g (>= 0.99.7.1), libselinux1 (>= 3.1~), libssl3 (>= 3.0.11),
libsystemd0, libwrap0 (>= 7.6-4~), zlib1g (>= 1:1.1.4)

Not all are libraries, but if IUC, libc6 shows to depend on libgcc-s1,
so if that library could be compromised, then openssh-server could be
vulnerable.  It's quite possible that I am wrong (hopefully) or we have
an even more massive problem.

> I have no doubt that this sort of thing has happened in the past, and I
> fully expect it will happen again in the future. However, the defect
> has been caught and repaired. The system for dealing with
> vulnerabilities is working, if not perfectly. The question now is: what
> lessons can we learn from it.

From what I am seeing right now discussions are centering around
comparing the file list associated with a VCS tag and a release tarball,
and somehow verifying the identity of contributors/committers.  I'm sure
other ideas are being discussed that I've not read.  Suffice it to say,
at the moment this is not being swept under the proverbial rug.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: making Debian secure by default

[Jeffrey Walton]

On Mon, Apr 1, 2024 at 5:55 PM Charles Curley
 wrote:
>
> On Mon, 1 Apr 2024 19:00:29 +
> Andy Smith  wrote:
>
> > In my view a great example of the "people other than me just need to
> > get good" fallacy merged with the group of people predisposed to
> > hate systemd.
> >
> > It could have been any direct or indirect dependency of sshd here.
> > I'm quite sure almost none of them have the required resources and
> > processes to detect something like this.
>
> Easy, now. No-one is attacking systemd, and I don't think anyone wanted
> to start a systemd war. This could also have happened under System V
> initialization.
>
> I have no doubt that this sort of thing has happened in the past, and I
> fully expect it will happen again in the future. However, the defect
> has been caught and repaired. The system for dealing with
> vulnerabilities is working, if not perfectly. The question now is: what
> lessons can we learn from it.

++.

Right now, Linux does not have a classification system to identify
critical projects, or help with resources for those projects. I don't
like using the word "Linux", but I don't know how to describe the
ecosystem.

For critical projects, I'm talking about the cURL, OpenSSL's OpenSSH,
Wget's and Xz's of the world. These are critical to a base Linux
system. When they have a memory bug or a CVE, action needs to be
taken. The free software world does not even know what the list is.
(And I'm not talking about the other useless fodder that shows up in
repos).

Other vulnerable projects include ncurses and libnettle. Ncurses is
run by Thomas Dickey (https://invisible-island.net/). libnettle is run
by Niels Möller (https://www.lysator.liu.se/~nisse/nettle/). Both are
one-man shows with no continuity plans. Dickey does not even run a
public version control system. You have to download his release
tarballs. There's nothing to make pull requests against. If DIckey or
Möller got hit by a bus crossing the street, there would be problems
for years.

Selling support for critical projects does not seem to work. I seem to
recall Werner Koch of GnuPG roughing it when relying on support
contracts to fund a project.

So one of the first steps would be to identify critical projects,
shore up their governance, and then help the project with additional
resources, like a grant and trusted eyeballs.

Jeff

Re: making Debian secure by default

[Charles Curley]

On Mon, 1 Apr 2024 19:00:29 +
Andy Smith  wrote:

> In my view a great example of the "people other than me just need to
> get good" fallacy merged with the group of people predisposed to
> hate systemd.
> 
> It could have been any direct or indirect dependency of sshd here.
> I'm quite sure almost none of them have the required resources and
> processes to detect something like this.

Easy, now. No-one is attacking systemd, and I don't think anyone wanted
to start a systemd war. This could also have happened under System V
initialization.

I have no doubt that this sort of thing has happened in the past, and I
fully expect it will happen again in the future. However, the defect
has been caught and repaired. The system for dealing with
vulnerabilities is working, if not perfectly. The question now is: what
lessons can we learn from it.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: making Debian secure by default

[Andy Smith]

Hi,

On Mon, Apr 01, 2024 at 03:19:18PM -0500, Nate Bargmann wrote:
> I've no idea of Jacob Bachmeyer's bias toward systemd, if any,
> other than "katamari" apparently refers to a Japanese video game I
> know absolutely nothing about.

I also don't know anything of Bachmeyer and very little of Katamari
Damacy, but I know enough to see that it was a pejorative
description: Katamari Damacy is a game about a huge ball that
agglomerates everything in the environment that it touches.

I think the point about the industry needing to find ways to strip
down, audit and sandbox dependencies could have been made without
attacking systemd, because there is a whole group of people whose
mental processes will stop at that point, having found an agreeable
bandwagon to jump on. The nuance that the systemd project started
doing that, and before this even was a wider known issue, is totally
lost.

Thanks,
Andy


-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: making Debian secure by default

[Nate Bargmann]

* On 2024 01 Apr 14:01 -0500, Andy Smith wrote:
> Hi,
> 
> On Mon, Apr 01, 2024 at 03:33:37AM -0500, Nate Bargmann wrote:
> > From what I have read, lzma is not a direct dependency of openssh.  It
> > turns out that it lzma is a dependency of libsystemd and that
> > relationship affected openssh.
> > 
> > Jacob Bachmeyer in analysis
> > (https://lists.gnu.org/archive/html/automake/2024-04/msg0.html)
> > says:
> > 
> > Lastly on this topic, some of the blame for this needs to fall on the
> > systemd maintainers and their "katamari" architecture. There is no good
> > reason for notifications of daemon startup to pull in liblzma, but using
> > libsystemd for that purpose does exactly that, and ended up getting
> > xz-utils targeted as a means of getting to sshd without the OpenSSH
> > maintainers noticing.
> > 
> > End quote.
> 
> In my view a great example of the "people other than me just need to
> get good" fallacy merged with the group of people predisposed to
> hate systemd.

AIUI, systemd already has patches to limit the use of lzma to only
dlopen when needed: https://lwn.net/Articles/967399/

This action apparently predates this incident and was made for other
considerations.  More than anything, I think this shows in the future
some hard decisions will need to made to prevent unrelated code
affecting other code through linked intermediate code.  AIUI, that would
be a fundamental change to our systems that would likely break
(assuming) a lot of software.

> It could have been any direct or indirect dependency of sshd here.

Or any other daemon but openssh is a very attractive target and systemd
as a service manager is a defacto standard.

> I'm quite sure almost none of them have the required resources and
> processes to detect something like this.

Until now, who anticipated this?  I'm sure there are security
researchers who have and it's likely that I'm not well-read enough on
this topic to have seen it discussed.  How many people did it occur to
that when A links to B and B links to C that C can create a
vulnerability in A?  That is what I understand happened here.

The social part where Jia Tan (individual, group, state actor?) gains
commit privileges, which in a small project are seldom reviewed as some
level of trust has been established before granting such privileges, and
over time begins the process of introducing compromising code bit by
bit.  It is curious that any of the compromise was committed when other
parts were added at the creation of the release tarball.  Perhaps it was
determined that a two-prong approach would garner less suspicion.  I
have also read that this entity began a campaign to get the latest lzma
release into distributions quickly.  That kind of behavior will now
raise suspicions due to this event.  When a developer believes that
distributions should update ASAP they likely better have a CVE issue at
hand or expect their work to be more carefully audited.

> I think anyone buying into systemd-blaming here needs to have a good
> hard look at their biases. Which is another part of this massive
> social problem. It's such a distraction. And here we are in a thread
> that started with a bug in a 30+ year old setgid binary.

We all carry biases.  I've no idea of Jacob Bachmeyer's bias toward
systemd, if any, other than "katamari" apparently refers to a Japanese
video game I know absolutely nothing about. How that relates, good or
bad, I have no idea.  I will say that I have been satisfied with its
implementation over several Debian releases but that is because I trust
Debian more than upstream.

Upstream systemd has not done itself many favors over the years WRT
community interaction.  I think that developers would be wise not to
follow the systemd project's path with their own endeavors.  I do find
systemd useful and even enable some of the optional features on my
Debian systems.  It works well enough and the commonality of
configuration style between the optional components is helpful.

Unavoidably, systemd is going to get a bit of bad press here simply
because of its service manager role that enabled the C creating a
vulnerability in A scenario.  The upshot is that patches to
openssh-portable applied by Debian might move away from linking in
libsystemd if I read that LWN thread correctly.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: making Debian secure by default

[John Hasler]

Joe writes:
> Which didn't happen, at least not for two years.

It happened eventually, which is my point.

> I would suggest that for any software as critical as OpenSSL, more
> than one pair of eyes would have been appropriate *before* release.

I would suggest that critical projects such as OpenSSL need to practice
a form of "dependecy management" analogous to "supply chain management":
track dependency chains and periodically re-qualify each level.  A full
audit might not be possible but at least look closely enough to notice
when a library is being supported by one overworked guy who is taking
patches from random strangers.

NOTE: this is just a suggestion.  I don't claim to be any sort of
security expert  nor am I trying to tell anyone what to do.
-- 
John Hasler 
j...@sugarbit.com
Elmwood, WI USA

Re: making Debian secure by default

[Joe]

On Mon, 01 Apr 2024 13:50:22 -0500
John Hasler  wrote:

> Joe writes:
> > I think this was amply demonstrated by Heartbleed, where the
> > offending code was examined by *one* other pair of eyes, before
> > approval was granted for inclusion in OpenSSL.  
> 
> The "many eyes" phase comes after release.

Which didn't happen, at least not for two years.

I would suggest that for any software as critical as OpenSSL, more than
one pair of eyes would have been appropriate *before* release.

-- 
Joe

Re: making Debian secure by default

[Andy Smith]

Hi,

On Mon, Apr 01, 2024 at 03:33:37AM -0500, Nate Bargmann wrote:
> From what I have read, lzma is not a direct dependency of openssh.  It
> turns out that it lzma is a dependency of libsystemd and that
> relationship affected openssh.
> 
> Jacob Bachmeyer in analysis
> (https://lists.gnu.org/archive/html/automake/2024-04/msg0.html)
> says:
> 
> Lastly on this topic, some of the blame for this needs to fall on the
> systemd maintainers and their "katamari" architecture. There is no good
> reason for notifications of daemon startup to pull in liblzma, but using
> libsystemd for that purpose does exactly that, and ended up getting
> xz-utils targeted as a means of getting to sshd without the OpenSSH
> maintainers noticing.
> 
> End quote.

In my view a great example of the "people other than me just need to
get good" fallacy merged with the group of people predisposed to
hate systemd.

It could have been any direct or indirect dependency of sshd here.
I'm quite sure almost none of them have the required resources and
processes to detect something like this.

I think anyone buying into systemd-blaming here needs to have a good
hard look at their biases. Which is another part of this massive
social problem. It's such a distraction. And here we are in a thread
that started with a bug in a 30+ year old setgid binary.

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: making Debian secure by default

[John Hasler]

Joe writes:
> I think this was amply demonstrated by Heartbleed, where the offending
> code was examined by *one* other pair of eyes, before approval was
> granted for inclusion in OpenSSL.

The "many eyes" phase comes after release.
-- 
John Hasler 
j...@sugarbit.com
Elmwood, WI USA

SOLVED (was: Re: help needed to get a bookworm install to succeed)

[DdB]

Am 01.04.2024 um 18:52 schrieb David Christensen:
> A bad USB flash drive would explain why you cannot boot the Debian
> installer.  Please buy a good quality USB 3.0+ flash drive and try again.

A friend of mine just let me use an external CD-Drive with the netboot
image. This is already the third time, i am restarting the installation
process, due to my false assumptions about the intelligence within the
installer.

The last time, i was quite happy until i came to notice, that partitions
were not aligned with physical sector boundaries, which i assumed would
be elementary best practice.

But apart from losing some of my illusions the hard way, all is well.
A big thank you to all the crowd offering suggestions and encouragement.

so long, DdB

Re: help needed to get a bookworm install to succeed

[David Christensen]

On 4/1/24 03:10, DdB wrote:

Am 01.04.2024 um 07:44 schrieb David Christensen:

Please post a console session that identifies the ISO you are using,
verifies the checksum, burns the ISO to a USB flash drive, and compares
the ISO against the flash drive.


Ok, in the meantime, i came to similar conclusions and found that the
USB-stick i was using, had consistent read errors at the first 2
gigabytes after having been used for years as memory extension in my
router. Fixed that and will replace the stick.



A bad USB flash drive would explain why you cannot boot the Debian 
installer.  Please buy a good quality USB 3.0+ flash drive and try again.



David

Re: autofs for /home: exclude admin users

[Felix Natter]

hallo Darac,

Darac Marjal  writes:
> On 01/04/2024 07:55, Felix Natter wrote:
>
>  hello debian-users,
>
> I configured autofs for /home:
>
> * -fstype=nfs,rw,soft,bg,intr SERVER:/share/&
>
> Just to point out that this is "/share", not "/home". You might have set 
> user's home directories to be /share/, but you've not mentioned that
> explicitly.

you interpreted this wrongly: The whole config is for /home (defined in
/etc/auto.home and /etc/auto.misc or similar). The * means "any
username", and the right hand side is saying "mount SERVER:/share/$1 as
/home/$1" using NFS.

> But now the login as "admin" does not work any more, since
> it tries to mount SERVER:/share/admin -> Is it possible to exclude
> a user from automounting? 
>
> Probably the simplest method is to ensure that "admin"'s home directory isn't 
> below /share. You could keep that under /home, or make a new folder, as you
> prefer.

Ok, that is an idea: Change /etc/passwd so that "admin" gets the home
from /export/admins/admin. The (small) downside is that I potentially need
to do this for every admin around (In my "workaround" I can make
/etc/auto.home executable and use bash's wildcard matching).

> The workaround [1] I use is this:
>
> admin -fstype=nfs,rw,soft,bg,intr localhost:/export/admin_homes/&
> * -fstype=nfs,rw,soft,bg,intr SERVER:/share/&
>
> where /export/admin_homes/admin is just a normal directory.
>
> [1]
> https://serverfault.com/questions/245121/how-to-prevent-autofs-from-mounting-over-specific-directories
>
> Is this a valid solution? Will it work on Debian/Ubuntu/... also in the
> future?

Since I already did it that way: Can somebody please tell me whether my
"workaround" is valid?

> I use FreeIPA to manage my NFS home directories, and I've set my users there 
> to have home directories under /home/ipa/. This means that
> non-FreeIPA users (i.e. if I need a machine-only user) have their homes under 
> /home/ which isn't NFS-mounted.

Yes, thanks (this is similar to your suggestion above). I would have do
it the other way around, i.e. keep the homes in /home, as users' Homes
depend on it.

Many Thanks and Best Regards,
Felix
-- 
Felix Natter
debian/rules!

Re: help needed to get a bookworm install to succeed

[Michel Verdier]

On 2024-04-01, DdB wrote:

>> A computer with a 6-core processor, 64 GB memory, and 9 drive bays/
>> ports that cannot boot USB?  That does not make sense.
>
> Why not?

Perhaps because usb boot is available since a very long time

> *should* is the correct word. The board being over 10 years old, it does
> not offer USB booting, no way.

I have one 20+ old which can usb boot but need to switch it in the
bios. The usb choice appears in the bios only after having plugged the
usb device. And of course detecting a valid usb device. You should check
that.

Re: making Debian secure by default

[Joe]

On Mon, 1 Apr 2024 01:45:07 +
Andy Smith  wrote:


>  "enough eyes make all bugs shallow"
> doesn't hold true unless the process is actually providing those
> eyes.
> 

I think this was amply demonstrated by Heartbleed, where the offending
code was examined by *one* other pair of eyes, before approval was
granted for inclusion in OpenSSL.

-- 
Joe

Re: making Debian secure by default

[Jeffrey Walton]

On Mon, Apr 1, 2024 at 4:34 AM Nate Bargmann  wrote:
>
> * On 2024 31 Mar 20:46 -0500, Andy Smith wrote:
> > In the xz case the further you go looking for a root cause the wider
> > the implications are:
> >
> > Q: Why was there a back door in sshd?
> > A: Because some malicious code was linked to it.
> >
> > Q: How did malicious code get linked to it?
> > A: Its lzma dependency was compromised.
>
> From what I have read, lzma is not a direct dependency of openssh.  It
> turns out that it lzma is a dependency of libsystemd and that
> relationship affected openssh.
>
> Jacob Bachmeyer in analysis
> (https://lists.gnu.org/archive/html/automake/2024-04/msg0.html)
> says:
>
> Lastly on this topic, some of the blame for this needs to fall on the
> systemd maintainers and their "katamari" architecture. There is no good
> reason for notifications of daemon startup to pull in liblzma, but using
> libsystemd for that purpose does exactly that, and ended up getting
> xz-utils targeted as a means of getting to sshd without the OpenSSH
> maintainers noticing.
>
> End quote.

It looks like SELinux is a larger problem than Systemd:
. Systemd
already dropped the liblzma dependency, but they did it for a smaller
initram image, and not to reduce attack surface.

Jeff

Re: help needed to get a bookworm install to succeed

[DdB]

Am 01.04.2024 um 07:44 schrieb David Christensen:
> 
> 
> A computer with a 6-core processor, 64 GB memory, and 9 drive bays/
> ports that cannot boot USB?  That does not make sense.

Why not?

> 
> 
> Please post a console session that identifies the ISO you are using,
> verifies the checksum, burns the ISO to a USB flash drive, and compares
> the ISO against the flash drive.

Ok, in the meantime, i came to similar conclusions and found that the
USB-stick i was using, had consistent read errors at the first 2
gigabytes after having been used for years as memory extension in my
router. Fixed that and will replace the stick.

> 
> 
> Then insert the USB flash drive into a USB port on the the target
> computer, power up and enter Setup, reset the settings to factory
> defaults, enable USB booting, set the USB flash drive as the first boot
> device, save, and exit.  The Debian installer should then boot.

*should* is the correct word. The board being over 10 years old, it does
not offer USB booting, no way. It is an early server board that supports
that much ECC, which is great for zfs.
> 
> 
> David

But i received many hints and ideas and just have to wait for a friend
of mine to overcome my physical handicap to see some progress. :-)

Tx 2 everyone
DdB

Re: autofs for /home: exclude admin users

[Darac Marjal]

On 01/04/2024 07:55, Felix Natter wrote:

hello debian-users,

I configured autofs for /home:

* -fstype=nfs,rw,soft,bg,intr SERVER:/share/&
Just to point out that this is "/share", not "/home". You might have set 
user's home directories to be /share/, but you've not 
mentioned that explicitly.


But now the login as "admin" does not work any more, since
it tries to mount SERVER:/share/admin -> Is it possible to exclude
a user from automounting?
Probably the simplest method is to ensure that "admin"'s home directory 
isn't below /share. You could keep that under /home, or make a new 
folder, as you prefer.


The workaround [1] I use is this:

admin -fstype=nfs,rw,soft,bg,intr localhost:/export/admin_homes/&
* -fstype=nfs,rw,soft,bg,intr SERVER:/share/&

where /export/admin_homes/admin is just a normal directory.

[1]
https://serverfault.com/questions/245121/how-to-prevent-autofs-from-mounting-over-specific-directories

Is this a valid solution? Will it work on Debian/Ubuntu/... also in the
future?

Many Thanks and Best Regards,
Felix
I use FreeIPA to manage my NFS home directories, and I've set my users 
there to have home directories under /home/ipa/. This means 
that non-FreeIPA users (i.e. if I need a machine-only user) have their 
homes under /home/ which isn't NFS-mounted.




OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: making Debian secure by default

[Nate Bargmann]

* On 2024 31 Mar 20:46 -0500, Andy Smith wrote:
> In the xz case the further you go looking for a root cause the wider
> the implications are:
> 
> Q: Why was there a back door in sshd?
> A: Because some malicious code was linked to it.
> 
> Q: How did malicious code get linked to it?
> A: Its lzma dependency was compromised.

From what I have read, lzma is not a direct dependency of openssh.  It
turns out that it lzma is a dependency of libsystemd and that
relationship affected openssh.

Jacob Bachmeyer in analysis
(https://lists.gnu.org/archive/html/automake/2024-04/msg0.html)
says:

Lastly on this topic, some of the blame for this needs to fall on the
systemd maintainers and their "katamari" architecture. There is no good
reason for notifications of daemon startup to pull in liblzma, but using
libsystemd for that purpose does exactly that, and ended up getting
xz-utils targeted as a means of getting to sshd without the OpenSSH
maintainers noticing.

End quote.

> Q: Who compromised the lzma dependency?
> A: One of the developers of that project who had full rights to
> commit code to it.
> 
> Q: Why did a persona that no one knows anything about get full
> access rights to a code repository that is linked to openssh?
> A: Because they did some work over a period of years that looked
> genuine and the single other developer who was overwhelmed with work
> decided to give them access based on that
> 
> Q: Why did lzma, a dependency of openssh, have a single overwhelmed
> developer?
> A: Because no one felt the need to pay a team of developers to work
> on it or audit work on it.

As Jacob notes, lzma is apparently not a direct dependency of openssh
which makes this story even more incredible.  Now we have to consider
the implications of patches to software that are related in non-obvious
ways.  Our systems are currently very complex and that complexity leads
to vulnerabilities in software that is not obviously linked.  Pretty
scary stuff, actually.

> Society demands that open source developers work, often for free,
> and that they merge contributions. If they push back and say they
> are unable to due to workload then they are encouraged to seek help
> by adding more committers. That's what apparently happened here: the
> attacker(s) seemingly counting on the pressure that would exist to
> give them rights within the project. It is hammered in to open
> source developers over and over:
> 
> Allow others to contribute, or even to take over, if you are too
> busy. It's the right thing to do.
> 
> We have now seen proof of what has long been theorised: that the
> above way of working is very vulnerable to attackers who are willing
> to put in some effort, and that "enough eyes make all bugs shallow"
> doesn't hold true unless the process is actually providing those
> eyes.

"Jai Tan" was somewhat patient at playing the long game it would appear.
The developer spent a lot of time and effort twisting the Autotools
build system into something that could hide the needed code.

You're absolutely correct, Andy, working its way deep into the project
while simultaneously planning to compromise it enabled the developer to
build a near disastrous back door.  It was also a very clever effort as
apparently the interaction of openssh, systemd and lzma were studied
carefully and understood to the level that choosing lzma as an attack
vector would likely go unnoticed as the relationship is apparently
non-obvious (though I've skimmed through the analysis my hobbyist coding
skills aren't up to the challenge of understanding this in its
entirety).

> I have no answers on how to fix such a deep-rooted societal problem
> but I am not going to start yelling obscenities at people on public
> mailing lists because they are wanting to discuss a CVE or whatever.

At the end of the day this is about trust.  The compromising developer
apparently set out from the start to exploit the trust of the main
maintainer and the overall community.  The sad part is, to me at least,
that the effort to analyze and understand the non-obvious relationship
of openssh, systemd, and lzma and then use that to create a back door
into openssh could have been used to improve security and create better
software.

Another hard lesson is that contributions are not always based on the
ideal of altruism that we in the "western world" hold dear.

BTW, I don't want to start a systemd bashing subthread, but I think it
bears some scrutiny give this latest event (disclaimer, yes I use
systemd as PID 1 on Debian Stable).

Finally, I am still involved with a project (hamlib) that is packaged in
many distributions.  I had to pull back several years ago and turn over
the day to day operations to a developer I came to trust.  For my own
part I became the administrator of the project after the original
developers had moved on and I was almost the most senior active
developer left.  Patches were backing up and someone needed to take
action so I did.

Your 

Old control sums for packages.

[Kamil Jońca]

At http://deb.debian.org/debian/dists/sid/main/binary-amd64/ we can find
files with SHA256 sums of packages. Unfortunately they are only 2 weeks
old. Is this possible to have little older files? (For example month or
2)?
KJ

-- 
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html

autofs for /home: exclude admin users

[Felix Natter]

hello debian-users,

I configured autofs for /home:

* -fstype=nfs,rw,soft,bg,intr SERVER:/share/&

But now the login as "admin" does not work any more, since
it tries to mount SERVER:/share/admin -> Is it possible to exclude
a user from automounting? 

The workaround [1] I use is this:

admin -fstype=nfs,rw,soft,bg,intr localhost:/export/admin_homes/&
* -fstype=nfs,rw,soft,bg,intr SERVER:/share/&

where /export/admin_homes/admin is just a normal directory.

[1]
https://serverfault.com/questions/245121/how-to-prevent-autofs-from-mounting-over-specific-directories

Is this a valid solution? Will it work on Debian/Ubuntu/... also in the
future?

Many Thanks and Best Regards,
Felix

-- 
Felix Natter
debian/rules!

Monthly FAQ for Debian-user mailing list [Modified 20240401]

[Andrew M.A. Cater]

Debian-user is a mailing list provided for support for Debian users,
and to facilitate discussion on relevant topics.

Codes of Conduct


* The list is a Debian communication forum. As such, it is subject to both
  the Debian mailing list Code of Conduct and the main Debian Code of Conduct
  https://www.debian.org/MailingLists/#codeofconduct
  https://www.debian.org/code_of_conduct
  
Guidelines for this list

Some guidelines which may help explain how the list should work:

Language


* The language on this mailing list is English. There may be other mailing
  lists that are language-specific, for example, debian-user-french or
  debian-user-catalan

* It is common for users to be redirected here from other lists, for example,
  from debian-project. It is also common for people to be posting here when
  English is not their primary language. Please be considerate.

Answering questions and contributing to discussions constructively
==

* This is a fairly busy mailing list but even so you may have to wait some
  time for an answer - please be patient.

* Help and advice on this list is provided by volunteers in their own time.
  It is common for there to be different opinions or answers provided.
  
* It is not necessary to answer every post on the mailing list.
  
* Be constructive in your responses. It may be that somebody else answers
  a question before you - if so, you should not reply simply in order to get
  the last word in, only reply if you can add useful information.

Off-topic posts
===

* Please try to stay on topic.

* Off-topic posts will happen occasionally as threads wander.
  Don't reply to them to make them carry on.

* If you wish to introduce an off-topic subject that might be
  of interest to the wider list, start a new thread and preface
  the title with [OT].

* There is no debian-offtopic mailing list: please don't try
  to start one.

Partisan topics and political arguments
* Arguments for the sake of it are not
  welcome here. 

* Partisan political / religious / cultural arguments do not belong here
  either.

  Debian's community is world wide; do not assume others will agree with your
  views or need to read them on a Debian list.
  
Editing and answering mailing list posts


* It is helpful to write meaningful subject lines. If you change subject
  or emphasis in mid-thread, please change the subject line on your email
  accordingly so that this can be clearly seen. 

  For example: New question [WAS Old topic]

* It may also be useful for someone to post a summary email from time to
  time to explain long threads.
  
* Before posting, it may be useful to check your post for spelling mistakes
  and scan it for redundancy, duplicate words and redundancy.

* Clear replies and a short mailing list thread are much easier to
  read and follow than long threads.

* If you are replying to a post, please reply in-line if possible and 
  cut out extra text that is not relevant to your point.

Private replies and responding to posts off-list


* Please post answers back to the list so others can benefit: private
  conversations don't benefit people who may only be following
  along on the list or reading the archives later.

* We're only human: you may want to respond to someone off-list
  to make a point (or to wish them Happy Birthday / comment that you
  haven't seen them for a long time). We're also a community and the
  people you find on the list may become familiar friends
  
  BUT

* Posting outside the list can be unhelpful: bad behaviour outside the lists 
  can't easily be dealt with and will be invisible. You may inadvertently leak
  personal information by posting a private reply back to the list.

  If you *do* want to post outside the list - make it clear that you have done
  so at the top of the message. If someone replies to you privately and you
  think that this should go back to the list - ask them to post it to the list
  - do not just do so on their behalf without checking.

I can't see what I want here - help me!
===

* It is often useful to look through the archives to see whether the issue
  you wish to raise or a similar issue has been raised before by someone
  else. The top level link to the archives of this list is at
  https://lists.debian.org/debian-user/ organised by year, then month.

* Although there are only 20 or 30 regular contributors, there may
  be a couple of thousand readers in the background. Nobody is
  a mind reader, nobody can sit beside you. Please help by providing
  useful details if asked, especially which version of Debian you are
  running.
  
I'm not using Debian but ...


* Strictly, discussions of other distributions are off-topic here.
  Please note: advice on