Ah ... wunnerful Winders :-)
It should be banned as a socioeconomic WMD ...
https://www.france24.com/en/technology/20240719-global-cyber-outage-linked-to-microsoft-slams-travel-media-financial-telecom-sectors
Global computer outage linked to security firm CrowdStrike
grounds flights, hits banks, media
. . .
Ah ... wunnerful Winders :-)
It should be banned as a socioeconomic WMD ...
This was supposed to be an "update" from a
FRIENDLY entity. What about all the UN-friendly
actors in the world these days ?
https://www.france24.com/en/technology/20240719-global-cyber-outage-linked-to-microsoft-slams-travel-media-financial-telecom-sectors<snip>
Global computer outage linked to security firm CrowdStrike
grounds flights, hits banks, media
"26yh.0712" <26yh.0713@e6t5y.net> writes:
Ah ... wunnerful Winders :-)
It should be banned as a socioeconomic WMD ...
Imagine systemd swallowing package management, doing automagic
security updates and such a "MSLinux" monoculture.
Wouldn't that be similarly vulnerable?
IMO "MSLinux" everywhere would have the same problem.
I think redundancy, diversity and reducing complexity is the right
answer.
On 7/19/24 12:03 PM, yeti wrote:
I think redundancy, diversity and reducing complexity is the right
answer.
But it's an answer apparently very difficult
to arrive at. Corps/managers don't WANT to
pay for "diversity" or "redundancy" and,
as with almost any kind of system "complexity"
(and thus 'opacity') always increases.
Big-Money Biz should stick to some kind of Unix
or Linux (pref WITHOUT systemd). Winders looks
pretty and seems friendly - but then so does
a tiger until ......
Imagine systemd swallowing package management, doing automagic security updates and such a "MSLinux" monoculture.
Wouldn't that be similarly vulnerable?
Linux/Unix is, or can be, "better" ... but even most Linux distros
now are quite large and complex and way too heavy on GUI bells and
whistles.
On 2024-07-19, 26yh.0712 <26yh.0713@e6t5y.net> wrote:
On 7/19/24 12:03 PM, yeti wrote:
I think redundancy, diversity and reducing complexity is the right
answer.
But it's an answer apparently very difficult
to arrive at. Corps/managers don't WANT to
pay for "diversity" or "redundancy" and,
as with almost any kind of system "complexity"
(and thus 'opacity') always increases.
This is often by design. Complexity is a weapon -
it ties your victims - and competitors - in knots,
and makes it easy to hide all sorts of nasty stuff.
This has been known by politicians and bureaucrats
for centuries.
Big-Money Biz should stick to some kind of Unix
or Linux (pref WITHOUT systemd). Winders looks
pretty and seems friendly - but then so does
a tiger until ......
Hmmm, reminds me of the ending of the movie "Don't Look Up"...
In comp.os.linux.misc 26yh.0712 <26yh.0713@e6t5y.net> wrote:
https://www.france24.com/en/technology/20240719-global-cyber-outage-linked-to-microsoft-slams-travel-media-financial-telecom-sectors<snip>
Global computer outage linked to security firm CrowdStrike
grounds flights, hits banks, media
You heard it here first :)
I guess here in the US, there will be Congressional
Inquiries into this and how to stop it from happening
again.
For people not in the US, "Congressional Inquiries"
in most cases is a fund raiser, or as non-US people
refer to them "Bribe Requests" :(
Nothing ever comes from these Inquiries.
On 7/19/24 10:47 AM, 26yh.0712 wrote:
https://www.france24.com/en/technology/20240719-global-cyber-outage-linked-to-microsoft-slams-travel-media-financial-telecom-sectors
Global computer outage linked to security firm CrowdStrike
grounds flights, hits banks, media
. . .
Ah ... wunnerful Winders :-)
It should be banned as a socioeconomic WMD ...
This was supposed to be an "update" from a
FRIENDLY entity. What about all the UN-friendly
actors in the world these days ?
Yeah I know several people who were told to just not come into work this morning. Can't imagine the chaos an actual happening would bring.
On Fri, 19 Jul 2024 21:53:05 -0400, 26yh.0712 wrote:
Linux/Unix is, or can be, "better" ... but even most Linux distros
now are quite large and complex and way too heavy on GUI bells and
whistles.
Old engineering adage: in any system, the complexity arises not so much
from the number of components, as from the number of potential
interactions between them.
This is why Linux is more robust than Windows.
Don’t like those “GUI bells and whistles”? Don’t install them. That’s not
a choice Windows gives you.
'Complexity' CAN be a sort of weapon ... but in the
whole computer universe - and I got in pre-PCs - we're mostly looking
at 'feature creep' ... with every developer thinking they're doing
good. I've writ enough complicated software - and then you get back
to it and it's "Oh ... wouldn't it be great if it could do *this* and
*that* and look nicer ?". Pretty soon you have spaghetti code even
you yourself can't follow nor find all the possible flaws within.
I've been using Manjaro on a couple of boxes of late since I went off
Deb. Try to install or update most ANYTHING and it totally re-loads
about 1.5gb worth of system. That's their sledgehammer "fix" for the
dependencies issue ...
On 7/19/24 10:12 PM, Lawrence D'Oliveiro wrote:
This is why Linux is more robust than Windows.
For NOW ... but Linux does seem to be drifting in the Winders
direction ...
I've been using Manjaro on a couple of boxes of late since I went off
Deb. Try to install or update most ANYTHING and it totally re-loads
about 1.5gb worth of system. That's their sledgehammer "fix" for the dependencies issue ...
On Fri, 19 Jul 2024 22:57:49 -0400, 26yh.0712 wrote:
I've been using Manjaro on a couple of boxes of late since I went off
Deb. Try to install or update most ANYTHING and it totally re-loads
about 1.5gb worth of system. That's their sledgehammer "fix" for the
dependencies issue ...
I knew what I was getting into but today's upgrades want to upgrade 246 packages and replace the kernel for a little under 1 GB of downloads. It's the KDE spin so a lot of it seems to be getting plasma, Qt, and kwhatever
to play nice. Almost every day is a new batch of upgrades.
As I've said before - SOMETHING needs to be done about the
Dependencies Issue in Linux.
On Fri, 19 Jul 2024 21:53:05 -0400, 26yh.0712 wrote:
'Complexity' CAN be a sort of weapon ... but in the
whole computer universe - and I got in pre-PCs - we're mostly looking
at 'feature creep' ... with every developer thinking they're doing
good. I've writ enough complicated software - and then you get back
to it and it's "Oh ... wouldn't it be great if it could do *this* and
*that* and look nicer ?". Pretty soon you have spaghetti code even
you yourself can't follow nor find all the possible flaws within.
Feature creep cna happen up front. We've has a couple of programmers that wrote very flexible, complicated code to cover every future possibility
they could think of. 20 years later the future stuff never happened and you're left with a maintenance nightmare.
On Fri, 19 Jul 2024 16:45:34 +0042, yeti wrote:
Imagine systemd swallowing package management, doing automagic security
updates and such a "MSLinux" monoculture.
Wouldn't that be similarly vulnerable?
Obviously not.
Bill Gates learned early on to keep his pols WELL greased.
today's upgrades want to upgrade 246 packages and replace the
kernel for a little under 1 GB of downloads. It's the KDE spin
so a lot of it seems to be getting plasma, Qt, and kwhatever
to play nice. Almost every day is a new batch of upgrades.
"26yh.0712" <26yh.0713@e6t5y.net> writes:
Ah ... wunnerful Winders :-)
It should be banned as a socioeconomic WMD ...
Imagine systemd swallowing package management, doing automagic
security updates and such a "MSLinux" monoculture.
Wouldn't that be similarly vulnerable?
IMO "MSLinux" everywhere would have the same problem.
I think redundancy, diversity and reducing complexity is the right
answer.
I remember US robotics sold future proof modems that could be upgraded.
No one ever did.
They threw them and bought the newer modems instead
Don’t like those “GUI bells and whistles”? Don’t install them. That’s not
a choice Windows gives you.
Do we, the world, WANT
to be stuck with naught but M$ and the wormy
apple ???
If so, the cyber-villains have
already won and we'll be back to exchanging
pigs for chickens again.
As for Biz ... I'd still say to go with some kind
of Unix at this time. Some of the apps might have
that 80s terminal/curses look but they'd be SOLID.
As far as both are Turing-complete, there's probably not much difference
in capabilities for this discussion. Windows does not hold a monopoly in
the capability to run code with errors.
(In fact, given that Broadcom has their own wireless linux drivers,
possibly with the same quality level as their firmware...)
But immediately ruling out this scenario for Linux systems sounds quite unrealistic to me. (And, from what I've read yesterday, I got the
impression that there had been a similar incident with Linux systems,
but I didn't study that further.)
On 2024-07-20, 26yh.0712 <26yh.0713@e6t5y.net> wrote:
Do we, the world, WANT
to be stuck with naught but M$ and the wormy
apple ???
"Ooooh, shiny!"
(In other words, for suitable values of "the world",
the answer is a resounding yes.)
If so, the cyber-villains have
already won and we'll be back to exchanging
pigs for chickens again.
I'll raise you two hens and a rooster.
As for Biz ... I'd still say to go with some kind
of Unix at this time. Some of the apps might have
that 80s terminal/curses look but they'd be SOLID.
I still see curses-style screens in some commercial
venues. They're not only solid but lightning-fast.
But all they give you is what you need, so I don't
see them getting far in the mass market...
The Natural Philosopher wrote:
I remember US robotics sold future proof modems that could be upgraded.
Only the "Courier" model had DSP upgrades, other models like "Sportster"
only had firmware upgrades.
No one ever did.
When I bought mine, Demon supported 14.4kbps, that modem was upgraded
all the way to 56kbps.
They threw them and bought the newer modems instead
Still have a couple here.
Pushing an update for privileged software to tens of thousands of
systems all at once is never a good idea. It should have been done in
stages starting with a small number of systems, with verification that
it was working properly at each stage of the roll out.
Lawrence D'Oliveiro wrote:
Don’t like those “GUI bells and whistles”? Don’t install them. That’s not
a choice Windows gives you.
Oh? Windows Server Core.
In Message-ID: <-7CcndX6lpSstAb7nZ2dnZfqnPudnZ2d@earthlink.com> 26yh.0712:
[Snip...]
Bill Gates learned early on to keep his pols WELL greased.
Quoting ProPublica:
A full, public accounting of what happened in the Solar Winds case would
have been devastating to Microsoft. ProPublica recently revealed that Microsoft had long known about -- but refused to address -- a flaw used
in the hack. The tech company's failure to act reflected a corporate
culture that prioritized profit over security and left the U.S. government vulnerable, a whistleblower said.
Please excuse any snits slrn had about this reference URL:
https://www.propublica.org/article/cyber-safety-board-never-investigated-solarwinds-breach-microsoft
Lawrence D'Oliveiro wrote:
Don’t like those “GUI bells and whistles”? Don’t install them. That’s not
a choice Windows gives you.
Oh? Windows Server Core.
But immediately ruling out this scenario for Linux systems sounds quite unrealistic to me. (And, from what I've read yesterday, I got the
impression that there had been a similar incident with Linux systems,
but I didn't study that further.)
Pushing an update for privileged software to tens of thousands of
systems all at once is never a good idea. It should have been done in
stages starting with a small number of systems, with verification that
it was working properly at each stage of the roll out.
Even worse, our support people
are indoctrinated from Day One that unless the system is completely
broken and can't get any worse never push out updates on Friday when
everyone is headed to the beach.
That was very interesting. Although following the link to the article
about the whistleblower who quit Microsoft, guess who hired them next?
The Windows situation... OBVIOUSLY... would never happen in a Linux evironment although systemd makes a huge step forward to make it
possible.
On Sat, 20 Jul 2024 11:08:50 +0100, Nuno Silva wrote:
But immediately ruling out this scenario for Linux systems sounds quite
unrealistic to me. (And, from what I've read yesterday, I got the
impression that there had been a similar incident with Linux systems,
but I didn't study that further.)
Sure. But remember, the various pieces of a Linux system are just
inherently put together in a more modular, flexible fashion, and that includes systemd. That does reduce the chance for trouble quite significantly.
and that
includes systemd.
systemd myth number 1: “systemd is monolithic”
<http://0pointer.de/blog/projects/the-biggest-myths.html>
On 7/20/24 8:55 PM, Lawrence D'Oliveiro wrote:
systemd myth number 1: “systemd is monolithic”
<http://0pointer.de/blog/projects/the-biggest-myths.html>
You are a fucking idiot.
On 21 Jul 2024 10:17:55 +1000, Computer Nerd Kev wrote:
That was very interesting. Although following the link to the article
about the whistleblower who quit Microsoft, guess who hired them next?
What is that supposed to be suggesting, exactly? Is it saying something
about the ethics of the whistleblower, or of the company who hired them?
If so, what?
On 7/20/24 8:55 PM, Lawrence D'Oliveiro wrote:
and that includes systemd.
Umm no it doesn't
On 7/20/24 6:08 AM, Nuno Silva wrote:
As far as both are Turing-complete, there's probably not much difference
in capabilities for this discussion. Windows does not hold a monopoly in
the capability to run code with errors.
(In fact, given that Broadcom has their own wireless linux drivers,
possibly with the same quality level as their firmware...)
For thirty years people have been saying stupid and meaningless stuff
like this. It is garbage.
The Windows situation... OBVIOUSLY... would never happen in a Linux evironment although systemd makes a huge step forward to make it
possible.
It has nothing to do with turing machines and advanced theoretical calculations.
It has to do with the more secure Unix level design for
Linux based systems and the way decisions are made in Linux development
and how updates are run and generated.
Does this make Linux perfect.. No. But it gives it a shot. MS makes insecure decisions from the ground up for business decisions. We have
spent a lift time watch MS systems doing things they just should be able
to do making them rich targets for visues big and small, and malware... things like runnng fucking email as an executable binary and autoruning
DVD software etc etc. I can't even begin to discuss what it does to the browser.
So please... put your bullshit away.
THis was inevitable and it is inevitable to happen again.
On Sat, 20 Jul 2024 11:08:50 +0100, Nuno Silva wrote:
But immediately ruling out this scenario for Linux systems sounds quite
unrealistic to me. (And, from what I've read yesterday, I got the
impression that there had been a similar incident with Linux systems,
but I didn't study that further.)
Sure. But remember, the various pieces of a Linux system are just
inherently put together in a more modular, flexible fashion, and that includes systemd. That does reduce the chance for trouble quite significantly.
On 7/20/24 8:55 PM, Lawrence D'Oliveiro wrote:
On Sat, 20 Jul 2024 11:08:50 +0100, Nuno Silva wrote:
But immediately ruling out this scenario for Linux systems sounds quite
unrealistic to me. (And, from what I've read yesterday, I got the
impression that there had been a similar incident with Linux systems,
but I didn't study that further.)
Sure. But remember, the various pieces of a Linux system are just
inherently put together in a more modular, flexible fashion, and that
includes systemd. That does reduce the chance for trouble quite
significantly.
BTW - you are now in my kill fly, so you can troll the back of the hand now...
That was very interesting. Although following the link to the
article about the whistleblower who quit Microsoft, guess who
hired them next?
""The decisions are not based on what's best for Microsoft's
customers but on what's best for Microsoft," said Harris, who now
works for CrowdStrike, a cybersecurity company that competes with
Microsoft." ...
So it indeed seems like you can't really rely on any company in
this market.
The Windows situation... OBVIOUSLY... would never happen in a Linux evironment although systemd makes a huge step forward to make it possible.
Well, there is one notable piece of software in Linux systems that's
quite monolithic, unless something has changed and I didn't get the
memo: the kernel itself.
If you write a bad quality module that crashes the kernel, what
mechanisms are there to recover from that?
On Sat, 20 Jul 2024 16:05:05 -0400, David W. Hodgins wrote:
Pushing an update for privileged software to tens of thousands of
systems all at once is never a good idea. It should have been done in
stages starting with a small number of systems, with verification that
it was working properly at each stage of the roll out.
Canary testing is definitely beneficial. Even worse, our support people
are indoctrinated from Day One that unless the system is completely broken and can't get any worse never push out updates on Friday when everyone is headed to the beach.
On Sun, 21 Jul 2024, Popping Mad wrote:
On 7/20/24 8:55 PM, Lawrence D'Oliveiro wrote:Wise choice! I also discovered that Lawrence was just a troll and choose
On Sat, 20 Jul 2024 11:08:50 +0100, Nuno Silva wrote:
But immediately ruling out this scenario for Linux systems sounds
quite unrealistic to me. (And, from what I've read yesterday, I got
the impression that there had been a similar incident with Linux
systems, but I didn't study that further.)
Sure. But remember, the various pieces of a Linux system are just
inherently put together in a more modular, flexible fashion, and that
includes systemd. That does reduce the chance for trouble quite
significantly.
BTW - you are now in my kill fly, so you can troll the back of the hand
now...
the same action. He really has nothing of value to say in my opinion.
On 2024-07-20, rbowman <bowman@montana.com> wrote:
On Sat, 20 Jul 2024 16:05:05 -0400, David W. Hodgins wrote:
Pushing an update for privileged software to tens of thousands of
systems all at once is never a good idea. It should have been done in
stages starting with a small number of systems, with verification that
it was working properly at each stage of the roll out.
Canary testing is definitely beneficial. Even worse, our support people
are indoctrinated from Day One that unless the system is completely
broken and can't get any worse never push out updates on Friday when
everyone is headed to the beach.
What is it you find so bad about not updating on a Friday?
On Sun, 21 Jul 2024 00:41:53 -0400, Popping Mad wrote:
On 7/20/24 8:55 PM, Lawrence D'Oliveiro wrote:
systemd myth number 1: “systemd is monolithic”
<http://0pointer.de/blog/projects/the-biggest-myths.html>
You are a fucking idiot.
systemd-haters are like the anti-fluoridationists of the Open-Source world.
On Sun, 21 Jul 2024 11:23:08 +0200, D <nospam@example.net> wrote in <09a33276-1f22-a9af-6c0b-990cef30f9ad@example.net>:
On Sun, 21 Jul 2024, Popping Mad wrote:
On 7/20/24 8:55 PM, Lawrence D'Oliveiro wrote:Wise choice! I also discovered that Lawrence was just a troll and choose
On Sat, 20 Jul 2024 11:08:50 +0100, Nuno Silva wrote:
But immediately ruling out this scenario for Linux systems sounds
quite unrealistic to me. (And, from what I've read yesterday, I got
the impression that there had been a similar incident with Linux
systems, but I didn't study that further.)
Sure. But remember, the various pieces of a Linux system are just
inherently put together in a more modular, flexible fashion, and that
includes systemd. That does reduce the chance for trouble quite
significantly.
BTW - you are now in my kill fly, so you can troll the back of the hand
now...
the same action. He really has nothing of value to say in my opinion.
There's a far cry from "I disagree" to "nothing of value".
I don't agree with everything Lawrence posts, and I've called
him out on his "snip and snark" style, but not everything he
posts is without merit.
Regarding the crowdstrike matter: It seems that Linux
systems would be much less vulnerable to such SNAFUs -- and
there are Linux distributions that don't use systemd, if
that is a concern.
On Sun, 21 Jul 2024 16:37:13 GMT, Charlie Gibbs wrote:
What is it you find so bad about not updating on a Friday?
I don't think you what you wrote is what you intended.
Anyway for most organizations Friday is the end of the week and people are more focused
on planning their weekend. If there is IT support on the weekend it is
an oncall situation and they are not actually at their desks. In the CrowdStrike scenario that really hurts since a remote reboot doesn't work.
Too put it colloquially, people really don't want to deal with shit on
Friday and that goes for more than software updates. Sure, in this case
where the system is completely FUBAR they have to but the response time is slower.
systemd has a large attack surface.
On 2024-07-21, Lawrence D'Oliveiro wrote:
On Sat, 20 Jul 2024 11:08:50 +0100, Nuno Silva wrote:
But immediately ruling out this scenario for Linux systems sounds
quite unrealistic to me. (And, from what I've read yesterday, I got
the impression that there had been a similar incident with Linux
systems, but I didn't study that further.)
Sure. But remember, the various pieces of a Linux system are just
inherently put together in a more modular, flexible fashion, and that
includes systemd. That does reduce the chance for trouble quite
significantly.
Well, there is one notable piece of software in Linux systems that's
quite monolithic, unless something has changed and I didn't get the
memo: the kernel itself.
If you write a bad quality module that crashes the kernel, what
mechanisms are there to recover from that?
On Sun, 21 Jul 2024 09:36:06 +0100, Nuno Silva wrote:
On 2024-07-21, Lawrence D'Oliveiro wrote:
On Sat, 20 Jul 2024 11:08:50 +0100, Nuno Silva wrote:
But immediately ruling out this scenario for Linux systems sounds
quite unrealistic to me. (And, from what I've read yesterday, I got
the impression that there had been a similar incident with Linux
systems, but I didn't study that further.)
Sure. But remember, the various pieces of a Linux system are just
inherently put together in a more modular, flexible fashion, and that
includes systemd. That does reduce the chance for trouble quite
significantly.
Well, there is one notable piece of software in Linux systems that's
quite monolithic, unless something has changed and I didn't get the
memo: the kernel itself.
It’s always been modular. Look up “Linux kernel modules”:
Paging suddenly stopped working and it took
a while to figure out a dispatcher got sick of listening to the modem
and turned it off.
Note: not all outages are due to software bugs on our part.
Configuration changes on the customer site can kill things just as effectively, and in fact are the more likely cause of a failure. Or
maybe someone unplugged something they shouldn't. But if data stops
flowing, the finger is pointed at us first, rightly or wrongly. So not
only do we not do updates on Friday, we recommend the philosophy on
genreral principles.
Nuno Silva <nunojsilva@invalid.invalid> wrote:
Well, there is one notable piece of software in Linux systems that's
quite monolithic, unless something has changed and I didn't get the
memo: the kernel itself.
If you write a bad quality module that crashes the kernel, what
mechanisms are there to recover from that?
Boot into single user mode (hopefully the module is not autoloaded by
the kernel itself) and remove/rename the module file.
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Sun, 21 Jul 2024 09:36:06 +0100, Nuno Silva wrote:
On 2024-07-21, Lawrence D'Oliveiro wrote:
On Sat, 20 Jul 2024 11:08:50 +0100, Nuno Silva wrote:
But immediately ruling out this scenario for Linux systems sounds
quite unrealistic to me. (And, from what I've read yesterday, I got
the impression that there had been a similar incident with Linux
systems, but I didn't study that further.)
Sure. But remember, the various pieces of a Linux system are just
inherently put together in a more modular, flexible fashion, and that
includes systemd. That does reduce the chance for trouble quite
significantly.
Well, there is one notable piece of software in Linux systems that's
quite monolithic, unless something has changed and I didn't get the
memo: the kernel itself.
It’s always been modular. Look up “Linux kernel modules”:
Ah, no. Although one does have to time travel back to circa 1994 to
find a Linux kernel that did not have the modules subsystem. But it
has not "always" been modular.
Back in those days we had to recompile the kernel to turn on drivers
that one's distro did not compile in by default. And compiling the
kernel on a 386 was a multi hour proposition.
On 2024-07-22, Rich wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Sun, 21 Jul 2024 09:36:06 +0100, Nuno Silva wrote:
On 2024-07-21, Lawrence D'Oliveiro wrote:
On Sat, 20 Jul 2024 11:08:50 +0100, Nuno Silva wrote:
But immediately ruling out this scenario for Linux systems sounds
quite unrealistic to me. (And, from what I've read yesterday, I got >>>>>> the impression that there had been a similar incident with Linux
systems, but I didn't study that further.)
Sure. But remember, the various pieces of a Linux system are just
inherently put together in a more modular, flexible fashion, and that >>>>> includes systemd. That does reduce the chance for trouble quite
significantly.
Well, there is one notable piece of software in Linux systems that's
quite monolithic, unless something has changed and I didn't get the
memo: the kernel itself.
It’s always been modular. Look up “Linux kernel modules”:
Ah, no. Although one does have to time travel back to circa 1994 to
find a Linux kernel that did not have the modules subsystem. But it
has not "always" been modular.
Back in those days we had to recompile the kernel to turn on drivers
that one's distro did not compile in by default. And compiling the
kernel on a 386 was a multi hour proposition.
The modular part, AFAIK, only applies to having the separate files and loading and unloading. Isn't it still a monolithic process in-memory?
Or, for what matters for the topic of this thread: if code in a module crashes, how can the rest of the kernel continue running?
On 2024-07-21, Rich wrote:
Nuno Silva <nunojsilva@invalid.invalid> wrote:
Well, there is one notable piece of software in Linux systems that's
quite monolithic, unless something has changed and I didn't get the
memo: the kernel itself.
If you write a bad quality module that crashes the kernel, what
mechanisms are there to recover from that?
Boot into single user mode (hopefully the module is not autoloaded by
the kernel itself) and remove/rename the module file.
I was thinking more along the lines of recovering without a reboot.
But for what you say, it's indeed an approach (unless there is
something in place that prevents such access to remove the file -
which, I think, has been happening with some Windows machines with CrowdStrike, and could always be implemented on Linux systems too).
Nuno Silva <nunojsilva@invalid.invalid> wrote:
On 2024-07-22, Rich wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Sun, 21 Jul 2024 09:36:06 +0100, Nuno Silva wrote:
On 2024-07-21, Lawrence D'Oliveiro wrote:
On Sat, 20 Jul 2024 11:08:50 +0100, Nuno Silva wrote:
But immediately ruling out this scenario for Linux systems sounds >>>>>>> quite unrealistic to me. (And, from what I've read yesterday, I got >>>>>>> the impression that there had been a similar incident with Linux >>>>>>> systems, but I didn't study that further.)
Sure. But remember, the various pieces of a Linux system are just
inherently put together in a more modular, flexible fashion, and that >>>>>> includes systemd. That does reduce the chance for trouble quite
significantly.
Well, there is one notable piece of software in Linux systems that's >>>>> quite monolithic, unless something has changed and I didn't get the
memo: the kernel itself.
It’s always been modular. Look up “Linux kernel modules”:
Ah, no. Although one does have to time travel back to circa 1994 to
find a Linux kernel that did not have the modules subsystem. But it
has not "always" been modular.
Back in those days we had to recompile the kernel to turn on drivers
that one's distro did not compile in by default. And compiling the
kernel on a 386 was a multi hour proposition.
The modular part, AFAIK, only applies to having the separate files and
loading and unloading. Isn't it still a monolithic process in-memory?
For that, one starts delving into semantics, which I'm trying to avoid.
For those "literal thinking art students" like Lawrence, the mere fact
that the word "module" is used to name the loadable code files means
the kernel must be "not-monolithic".
Or, for what matters for the topic of this thread: if code in a module
crashes, how can the rest of the kernel continue running?
It can't, just about any (unexpected) CPU protection fault while
running ring 0 (kernel) mode code (whether in the main kernel or code
from a loaded module) results in a kernel panic and halt of the system.
But that fact does not lend any evidence for, or against, whether the
kernel itself is "modular".
if CrowdStrike were operating with a similar driver on Linux
as they do on Windows (a comment I linked elsewhere in the thread
suggests they might (hopefully?) be doing something else now), it'd just
fail in the same way as it did on Windows: with a hung system that needs
a reboot/restart/....
On 2024-07-22, Rich wrote:
Nuno Silva <nunojsilva@invalid.invalid> wrote:
On 2024-07-22, Rich wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Sun, 21 Jul 2024 09:36:06 +0100, Nuno Silva wrote:
On 2024-07-21, Lawrence D'Oliveiro wrote:
On Sat, 20 Jul 2024 11:08:50 +0100, Nuno Silva wrote:
But immediately ruling out this scenario for Linux systems sounds >>>>>>>> quite unrealistic to me. (And, from what I've read yesterday, I got >>>>>>>> the impression that there had been a similar incident with Linux >>>>>>>> systems, but I didn't study that further.)
Sure. But remember, the various pieces of a Linux system are just >>>>>>> inherently put together in a more modular, flexible fashion, and that >>>>>>> includes systemd. That does reduce the chance for trouble quite
significantly.
Well, there is one notable piece of software in Linux systems that's >>>>>> quite monolithic, unless something has changed and I didn't get the >>>>>> memo: the kernel itself.
It’s always been modular. Look up “Linux kernel modules”:
Ah, no. Although one does have to time travel back to circa 1994 to
find a Linux kernel that did not have the modules subsystem. But it
has not "always" been modular.
Back in those days we had to recompile the kernel to turn on drivers
that one's distro did not compile in by default. And compiling the
kernel on a 386 was a multi hour proposition.
The modular part, AFAIK, only applies to having the separate files and
loading and unloading. Isn't it still a monolithic process in-memory?
For that, one starts delving into semantics, which I'm trying to avoid.
For those "literal thinking art students" like Lawrence, the mere fact
that the word "module" is used to name the loadable code files means
the kernel must be "not-monolithic".
(I don't know what to say, the kernel is monolithic, it's a single
process,
and wasn't this also a topic of a discussion between Torvalds
and Tanenbaum that's part of the USENET lore?)
Or, for what matters for the topic of this thread: if code in a
module crashes, how can the rest of the kernel continue running?
It can't, just about any (unexpected) CPU protection fault while
running ring 0 (kernel) mode code (whether in the main kernel or
code from a loaded module) results in a kernel panic and halt of the
system. But that fact does not lend any evidence for, or against,
whether the kernel itself is "modular".
It does provide evidence against the claim that something like the CrowdStrike incident would not be likely on Linux: what you describe
means that, if CrowdStrike were operating with a similar driver on
Linux as they do on Windows (a comment I linked elsewhere in the
thread suggests they might (hopefully?) be doing something else now),
it'd just fail in the same way as it did on Windows: with a hung
system that needs a reboot/restart/....
On Sun, 21 Jul 2024 22:04:11 GMT, Charlie Gibbs wrote:
Note: not all outages are due to software bugs on our part.
Configuration changes on the customer site can kill things just as
effectively, and in fact are the more likely cause of a failure. Or
maybe someone unplugged something they shouldn't. But if data stops
flowing, the finger is pointed at us first, rightly or wrongly. So not
only do we not do updates on Friday, we recommend the philosophy on
genreral principles.
Yup. Our clients are PSAPs (dispatch software in 911 call centers). They
get really unhappy when the software goes down during a mass casualty incident.
The typical procedure is to deploy software to a backup/training server
and test it using the site's configuration files before pushing it to the main servers and workstations.
We're definitely #1 on the 'who do you call?' list. My favorite goes back
to the days of modems. Paging suddenly stopped working and it took a while
to figure out a dispatcher got sick of listening to the modem and turned
it off.
For sure. We have call tracking software in some 911 call centres;
it doesn't do the actual dispatching, but records call metadata
generated by the dispatch software (both for PSAPs and downstream
agencies).
The consequences of our software going down are less severe than the
dispatch software going down - still, though, the police would get a bit miffed if call data was missing when they're trying to get a record of
all calls related to, say, reports of gunshots in an area.
On Mon, 22 Jul 2024 18:43:01 GMT, Charlie Gibbs wrote:
For sure. We have call tracking software in some 911 call centres;
it doesn't do the actual dispatching, but records call metadata
generated by the dispatch software (both for PSAPs and downstream
agencies).
The consequences of our software going down are less severe than the
dispatch software going down - still, though, the police would get a bit
miffed if call data was missing when they're trying to get a record of
all calls related to, say, reports of gunshots in an area.
Previous history certainly is important and we search either by location
or phone number. There is a configurable limit on returns. Mom's Nursing
Home and Joe's Bucket of Blood tend to generate a lit of previous history. There are also database searches for persons or vehicles involved in
previous incidents. I wouldn't want to be a dispatcher. You never know if
the next time the phone rings if it will be somebody complaining about the neighbor's cat, a medical emergency, or a home invasion in progress.
It's also easy for the clients to create alerts that will pop up for a location. They may be informational for businesses with contact
information and Knox Box locations or comments on a resident who doesn't interact well with police.
The historical data has to be retained too. Sometimes it takes years for a case to come to court where evidence has to be presented. The volume of
data has taken off with the increased use of bodycams and dashcams.
Luckily we just pass incident information to a third party. They're responsible for activating cameras for the responding units, capturing the video data, and archiving it. That's got to amount to petabytes sooner or later.
... if CrowdStrike were operating with a similar driver on Linux
as they do on Windows ...
Nuno Silva <nunojsilva@invalid.invalid> wrote:
On 2024-07-22, Rich wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Sun, 21 Jul 2024 09:36:06 +0100, Nuno Silva wrote:
On 2024-07-21, Lawrence D'Oliveiro wrote:
On Sat, 20 Jul 2024 11:08:50 +0100, Nuno Silva wrote:
But immediately ruling out this scenario for Linux systems sounds >>>>>>> quite unrealistic to me. (And, from what I've read yesterday, I got >>>>>>> the impression that there had been a similar incident with Linux >>>>>>> systems, but I didn't study that further.)
Sure. But remember, the various pieces of a Linux system are just
inherently put together in a more modular, flexible fashion, and that >>>>>> includes systemd. That does reduce the chance for trouble quite
significantly.
Well, there is one notable piece of software in Linux systems that's >>>>> quite monolithic, unless something has changed and I didn't get the
memo: the kernel itself.
It’s always been modular. Look up “Linux kernel modules”:
Ah, no. Although one does have to time travel back to circa 1994 to
find a Linux kernel that did not have the modules subsystem. But it
has not "always" been modular.
Back in those days we had to recompile the kernel to turn on drivers
that one's distro did not compile in by default. And compiling the
kernel on a 386 was a multi hour proposition.
The modular part, AFAIK, only applies to having the separate files and
loading and unloading. Isn't it still a monolithic process in-memory?
For that, one starts delving into semantics, which I'm trying to avoid.
For those "literal thinking art students" like Lawrence, the mere fact
that the word "module" is used to name the loadable code files means
the kernel must be "not-monolithic".
Or, for what matters for the topic of this thread: if code in a module
crashes, how can the rest of the kernel continue running?
It can't, just about any (unexpected) CPU protection fault while
running ring 0 (kernel) mode code (whether in the main kernel or code
from a loaded module) results in a kernel panic and halt of the system.
But that fact does not lend any evidence for, or against, whether the
kernel itself is "modular".
I recently was starting up a game, which triggered rebuild of DXVK
shaders for the game. The nvidia module freaked out, wreaking havoc on
the kernel, and freezing the display.
John McCue <jmccue@hairball.jmcunx.com> wrote at 13:49 this Saturday (GMT):
followups trimmed to comp.os.linux.misc
In comp.os.linux.misc yeti <yeti@tilde.institute> wrote:
"26yh.0712" <26yh.0713@e6t5y.net> writes:
Ah ... wunnerful Winders :-)
It should be banned as a socioeconomic WMD ...
Imagine systemd swallowing package management, doing automagic
security updates and such a "MSLinux" monoculture.
I can see this happening, I think they just swallowed sudo.
You mean polkit?
Wouldn't that be similarly vulnerable?
Maybe, any complex solution is open to vulnerabilities. I
think (hope) these changes would be tested better than
crowdstrike was. But as things get more complex, the harder
to test :(
I still think these changes Red Hat is pushing is their way
to make things easier for admins, but to me, eventually you
end up with a Windows clone. Now I wonder if they will "AI"
systemd, I think it is possible since IBM seems to be
getting into AI.
That sounds like a nightmare. AI Systems...
IMO "MSLinux" everywhere would have the same problem.
I think redundancy, diversity and reducing complexity is the right
answer.
followups trimmed to comp.os.linux.misc
In comp.os.linux.misc yeti <yeti@tilde.institute> wrote:
"26yh.0712" <26yh.0713@e6t5y.net> writes:
Ah ... wunnerful Winders :-)
It should be banned as a socioeconomic WMD ...
Imagine systemd swallowing package management, doing automagic
security updates and such a "MSLinux" monoculture.
I can see this happening, I think they just swallowed sudo.
Wouldn't that be similarly vulnerable?
Maybe, any complex solution is open to vulnerabilities. I
think (hope) these changes would be tested better than
crowdstrike was. But as things get more complex, the harder
to test :(
I still think these changes Red Hat is pushing is their way
to make things easier for admins, but to me, eventually you
end up with a Windows clone. Now I wonder if they will "AI"
systemd, I think it is possible since IBM seems to be
getting into AI.
IMO "MSLinux" everywhere would have the same problem.
I think redundancy, diversity and reducing complexity is the right
answer.
No he means "sudo" is going to be replaced with "run0." <https://www.howtogeek.com/will-linux-run0-command-run-sudo-out-of-town/
"Sudo" is a bad implementation which replaced "su".
which invoked superuser privileges. You had to use your root
account password but Ubuntu decided that was dangerous so to invoke
the same privileges you can use your user accont passwork.
Canonical thought apparently that it was asking too
much of their projected userbase to remember User account
password and root password.
The Natural Philosopher <tnp@invalid.invalid> writes:
On 31/07/2024 06:58, Bobbie Sellers wrote:
"Sudo" is a bad implementation which replaced "su".
which invoked superuser privileges. You had to use your root
account password but Ubuntu decided that was dangerous so to invoke
the same privileges you can use your user accont passwork.
Canonical thought apparently that it was asking too
much of their projected userbase to remember User account
password and root password.
Sudo allowed tailored access by certain users to certain root
privileges, that su did not.
It's a reasonable admin tool for a multiuser system.
But who tuns a true multiuser system these days especially one where
users can do simple admin?
Even disregarding hobbyists, more than zero but I expect the number is
indeed rather small.
There’s a few points here:
* You can still set a root password and use ‘su’ on Ubuntu systems if
that’s what you want. Canonical are not enforcing a policy here, just
setting a default.
* The ‘sudo instead of su’ model is common everwhere, not just Ubuntu; I
expect the motivation for the default setup on Ubuntu is
simplification, not any theories about who can remember how many
passwords.
* Trusting sudo to enforce the a tailored access model is somewhat
optimistic given its CVE record, and the general record of the setuid
model that underpins it.
* By escaping the setuid model run0 may improve on this issue, though it
brings other kinds of complexity with it; how it balances out is
probably a question for a few years time.
* In the single-user context, sudo effectively creates the model that
your single user account has privileges equivalent to root, but that
you must explicitly mark any privileged operation. The former is just
acknowledging reality, the latter is a useful guard against accidents.
On 7/30/24 22:30, candycanearter07 wrote:
John McCue <jmccue@hairball.jmcunx.com> wrote at 13:49 this Saturday (GMT): >>> followups trimmed to comp.os.linux.misc
In comp.os.linux.misc yeti <yeti@tilde.institute> wrote:
"26yh.0712" <26yh.0713@e6t5y.net> writes:
Ah ... wunnerful Winders :-)
It should be banned as a socioeconomic WMD ...
Imagine systemd swallowing package management, doing automagic
security updates and such a "MSLinux" monoculture.
I can see this happening, I think they just swallowed sudo.
You mean polkit?
No he means "sudo" is going to be replaced with "run0." <https://www.howtogeek.com/will-linux-run0-command-run-sudo-out-of-town/>
Not right away but sooner or later unless it causes even
more problems. "Sudo" is a bad implementation which replaced "su".
which invoked superuser privileges.
You had to use your root account password but Ubuntu decided that
was dangerous so to invoke the same privileges you can use your user
accont passwork.
Canonical thought apparently that it was asking too
much of their projected userbase to remember User account
password and root password.
On 31/07/2024 10:23, Richard Kettlewell wrote:
The Natural Philosopher <tnp@invalid.invalid> writes:
But who tuns a true multiuser system these days especially one where
users can do simple admin?
Even disregarding hobbyists, more than zero but I expect the number is
indeed rather small.
There’s a few points here:
* You can still set a root password and use ‘su’ on Ubuntu systems if
that’s what you want. Canonical are not enforcing a policy here, just >> setting a default.
* The ‘sudo instead of su’ model is common everwhere, not just Ubuntu; I >> expect the motivation for the default setup on Ubuntu is+1 to all of that.
simplification, not any theories about who can remember how many
passwords.
* Trusting sudo to enforce the a tailored access model is somewhat
optimistic given its CVE record, and the general record of the setuid >> model that underpins it.
* By escaping the setuid model run0 may improve on this issue, though it
brings other kinds of complexity with it; how it balances out is
probably a question for a few years time.
* In the single-user context, sudo effectively creates the model that
your single user account has privileges equivalent to root, but that
you must explicitly mark any privileged operation. The former is just >> acknowledging reality, the latter is a useful guard against accidents. >>
I use sudo if its just one thing I need to do, but if its messing with
config files and restarting daemons, I use su -
The relevant point is that there are (at least a few) large
organizations running multi-user Unix systems, and care about
isolation between users.
For typical Ubuntu setups (single user who is system owner and the only
user) sudo adds no value add over just becoming root via su (other
than, as you say, not having to remember a 'root' password).
The relevant point is that there are (at least a few) large
organizations running multi-user Unix systems, and care about isolation between users.
For example, my workplace. Most of our Linux and macOS machines are not people's personal systems, but dedicated build/test machines with fairly full-time jobs. I am not a skilled sysadmin, but being able to use sudo
for simple tasks gets them done a lot faster than opening a helpdesk
ticket.
On 31/07/2024 16:34, Richard Kettlewell wrote:
The relevant point is that there are (at least a few) large
organizations running multi-user Unix systems, and care about isolation
between users.
There are, but they are rare birds.
Most 'multi-user' machines run pure web applications.
I cant offhand think of anything outside say a research super computer
where true multiuser exists
The Natural Philosopher <tnp@invalid.invalid> writes:
On 31/07/2024 16:34, Richard Kettlewell wrote:
The relevant point is that there are (at least a few) large
organizations running multi-user Unix systems, and care about isolation
between users.
There are, but they are rare birds.
Most 'multi-user' machines run pure web applications.
I cant offhand think of anything outside say a research super computer
where true multiuser exists
The example I hear about most is more or less that, specifially a
compute farm used for genomics research. You don’t get to log into the compute nodes, but the ‘head nodes’ used for uploading data sets and submitting jobs have logins for all.
I’m less clear on the details of the other example I’m aware of, we only really got to hear about how it interacts with attributes of our
product.
We have a few in-principle shared Unix machines at work but in practice
they can go months between anyone logging in.
On Tue, 30 Jul 2024 22:58:28 -0700, Bobbie Sellers wrote:
No he means "sudo" is going to be replaced with "run0."
<https://www.howtogeek.com/will-linux-run0-command-run-sudo-out-of-town/
sudo has been a running saga of security vulnerabilities. Poettering is offering a much simpler design with a smaller attack surface. He actually wants to do away with the whole idea of set-user-ID executables.
I see now on this system (Mint 21.3) that ping is no longer setuid. (Nowadays, it uses Linux capabilities.)
John McCue <jmccue@hairball.jmcunx.com> wrote at 13:49 this Saturday (GMT):
followups trimmed to comp.os.linux.misc
In comp.os.linux.misc yeti <yeti@tilde.institute> wrote:
"26yh.0712" <26yh.0713@e6t5y.net> writes:
Ah ... wunnerful Winders :-)
It should be banned as a socioeconomic WMD ...
Imagine systemd swallowing package management, doing automagic
security updates and such a "MSLinux" monoculture.
I can see this happening, I think they just swallowed sudo.
You mean polkit?
Wouldn't that be similarly vulnerable?
Maybe, any complex solution is open to vulnerabilities. I
think (hope) these changes would be tested better than
crowdstrike was. But as things get more complex, the harder
to test :(
I still think these changes Red Hat is pushing is their way
to make things easier for admins, but to me, eventually you
end up with a Windows clone. Now I wonder if they will "AI"
systemd, I think it is possible since IBM seems to be
getting into AI.
That sounds like a nightmare. AI Systems...
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 489 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 31:44:28 |
| Calls: | 9,666 |
| Calls today: | 1 |
| Files: | 13,716 |
| Messages: | 6,168,857 |