:: Re: [DNG] ..are we|Devuan safe from…
Kezdőlap
Delete this message
Reply to this message
Szerző: Rick Moen
Dátum:  
Címzett: dng
Tárgy: Re: [DNG] ..are we|Devuan safe from this systemd backdoor malware, taking our kernels from Debian?
Quoting marc (marcxdv@???):

> Hello


And almost certainly goodbye. But before that:

> > It's irrational to talk about rootkits as if they were a security threat
> > (and my apologies in advance if, as seems likely, you're fully aware of
> > the difference; in these discussions, there will always be other readers
> > who don't.
>
> Apologies accepted :)


You know what's really tragic, here? I was trying to be nice -- since
your wording had left it very unclear whether you actually thought
rootkits are an attack vector. I said it's likely you didn't, being
generous of spirit, and apologised if that were the case -- an
obvious pro-forma apology, as a way to be nice. It would, of course, be
obvious that I had objectively offered no offence, therefore I wasn't
actually apologising, just trying to be nice about your unclear wording.

But hey, if you want to be ungracious, and act like you don't want to be
friends, I guess you do you.

> > By definition, a rootkit is a set of coverup tools installed by an
> > intruder _after stealing root via other means entirely). The point is
> > that focussing on what bad guys do after they broken into your system
> > and cracked the root account is largely a waste of time: After they
> > have completely broken security, they can do anything at all, and what
> > particular thing they choose do isn't very interesting -- or relevant
> > to system administration. What _is_ interesting and relevant is how
> > the bad guys got in and how they escalated privilege to root. And those
> > questions are the ones relevant to system administration.
>
> Well, yes and no. Of course if the system is fully compromised, then
> all bets are off. It does also mean that if a bad guy has broken into
> a system with writable {disk,graphics,nic,bios} firmware, then the only
> safe response is to throw away the hardware (owners of RPIs earlier
> than v4 only need to throw away the sd card).


You purport to disagree with what I said, but then throw out a lot of
word salad that doesn't address it.

I'm going to ignore that and move on.


> However, most system administrators don't do that. At best they reformat,
> cross their fingers and continue.


Anyone who does that, I'd fire.


> And you will note the current rootkit under discussion has two modes - a root
> mode where it pretends to be a systemd component, and a userlevel mode where
> it pretends to be a bit of gnome.


Completely irrelevant to what I was saying.

> But more importantly: This is a mailing list for a distribution, and
> distributions are where supply chain attacks can (or might already have)
> happen(ed).


A tautologically true but also totally useless observation.


> Some people subscribe to "with sufficient eyeballs, all bugs are shallow",
> others to "three people can keep a secret, if two are dead". Interestingly
> both apply - the latter when talking about who has access to the build
> infrastructure...


Another totally useless observation -- and also completely irrelevant to
what I said. _If_ you know anything about distros with competent build
infrastructures (including for example Debian), you will know that it is
for obvious reasons accessible only to the most highly trusted people.
Unless one of those happens to be Moriarty the Napoleon of Crime,
authors of *ix ELF infectors, rootkits, UDP-based backdoors, etc. can
dick around with their creations all day long and not be able to
compromise the package collection via the build infrastructure.


> There is always a first time (or a time of first discovery).


Send a telegram.

And I believe I'm done. Run away and play elsewhere, sonny. I'm busy.

[rest snipped per the Law of Diminishing Returns]

-- 
Cheers,            There are really only two hard problems in computer science:
Rick Moen                      o  Cache invalidation policy.
rick@???            o  Name-space management.
McQ! (4x80)                    o  Off-by-one errors.