[conspire] computer security

[Rick Moen]

Quoting Michael Paoli (Michael.Paoli at cal.berkeley.edu):

> Could quibble over finer points, but yeah, there's no "magic pixie
> dust" in Unix/Linux/BSD/*nix that inherently makes it secure or much
> more secure.  I would, however, point out, that in addition to common
> practices, there are some things that typically make Unix, etc., more
> secure than, well, compared to Microsoft operating systems.  

That's such a low bar, you can't hardly limbo under it.

What I said, that Unix wasn't designed for security, is quite thoroughly
true past dispute.  There _are_ OSes that actually were, such as EROS
(https://en.wikipedia.org/wiki/EROS_(microkernel) ) and many others.

> >Quoting Paul Zander (paulz at ieee.org):
> >>I recall a few years back that a major Linux repository was hacked.
> 
> >No, I'm betting you didn't.
> 
> Well ... sort'a kind'a yes ... and no(!).

He didn't -- and I played fair by elaborating on what I meant.

> And ... "worst" such case? ... well, at least that I can think of -
> though I think even it was discovered and corrected in relatively short
> order.  Linux Mint.  Though no longer the case, some number of years
> back, Linux Mint did not so sign their ISOs ... directly nor
> indirectly.  There was no trusted secure path to validate the ISOs and
> that they'd not been tampered with (or compromised in transmission).
> And likewise, though not as strong, there wasn't even a secure https
> path to such ISOs, as the site(s) didn't even offer https.  Every time I
> looked at that I was like, "Yeah, ... I can't take a (Linux) distro
> seriously if they can't even be bothered to do that" ... especially
> since, at least by then, they certainly ought to have known (and done)
> better.  And, not only did I point this out to them that they ought fix
> it
> https://blog.linuxmint.com/?p=2361#comment-93804
> but other(s) had also earlier pointed this out to 'em and called it
> to their attention.  And their response was essentially, "Yeah, not
> gonna bother, not a concern, don't worry about it.".  Well, within a
> couple years or so, ... their site got "hacked", and ISOs and/or other
> data on their site compromised ... "oops".  Who could'a ever
> guessed/predicted that?  Yeah, ... right.  Well, *after* that happened,
> they finally got their sh*t together and started doing appropriate
> digital signing (directly or indirectly) of their ISOs.  I mean after
> all, their ISOs were the only means of initially getting and installing
> their software (or at least kicking off that process), and they offered
> no alternative means to securely do that.  In any case, I believe that
> compromise was detected and corrected in relatively short order.  But
> it probably got a wee bit further with the less than quite aware users,
> notably due to the lack of any such digital signing.

I've repeatedly pointed out to Bobby Sellers on SF-LUG, the member who
downloads scads of distro ISO files and hands them out to people, that
although it's nice that she checks SHA1SUMs to ensure that she fully
downloaded the files, it would be wise if she spends two minutes more 
vetting the PGP signatues -- to verify that she not only downloaded 
complete files but also that they aren't trojaned ISOs full of ELF
infectors and back doors for computer criminals.

But nope.  She ignores the suggestion every time.

[kernel.org:]

> Yep ... one of the ones I also recently pointed out - though it
> happened quite a while ago.

Discovered August 12, 2011.

I cover the essential details along with the other host-compromise
incidents mentioned on http://linuxmafia.com/~rick/faq/

[In reference to that specific list of host-compromise incidents:]

> Yep, so, properly digitally signed, and such signatures generally
> used/validated, such tampering is generally detected in short order,
> and is mostly a non-issue.

_Moreover_, Linux users get acculturated that there is ordinarily no
need to grab upstream tarballs in the first place, that it's usually an
actively bad idea without a really compelling reason, and that they are
better off relying on distro package maintainers as gatekeepers.  The
_latter_ then shoulder the responsibility of checking upstream
developers' code signatures, as part of the gatekeeping process.

So, for example, at the end of June 2011, when an upstream source
tarball of vsftpd was replaced with a trojaned forgery because the
shared host had been security-compromised, and it sat there for three
days until an alert downloader noticed that the md5 and sha1 checksums
no longer validate against the developer's signature, the three-day
gap might have been unfortunate, but it's likely that few or no prior 
downloaders even encountered the trojan at all, because _why_ compile an
upstream tarball when you can use a distro package?

Anyway, I chronicle that and the other incidents in part to reinforce
the point that _if_ for some reason you circumvent your distro's
software packaging regime, responsibility for all of the security
(and quality, and distro-conformance) testing, that would normally be
done by a distro packager, falls onto _you_, and you'd better be
prepared to do that or may pay the consequences.

Of course, naively doing otherwise would typically be the sort of 
judgement error an itinerant MS-Windows "power user" would commit
on Unix, i.e., it takes a particular complex type of stupid, not just 
the usual laziness and not thinking.  But there are always people who're
only willing to learn the hard way.