Re: [PLUG] download from WHERE?

[Rich Freeman via plug <plug@lists.phillylinux.org>]

This is becoming a bit of an unwieldy thread, so I'm going to greatly
trim this down in this reply.

I'm not suggesting that there aren't a lot of great discussion topics
in the parts I cut out, or that things are somehow "settled" in these.
I just wanted to pick a few specific topics that I thought would be
interesting to discuss right now and try to add something, versus
trying to just go point-by-point on everything in what is becoming a
pretty extensive debate.

But I would be happy to discuss any of this stuff in any venue,
because I do genuinely enjoy the perspective you add.  Honestly, I
agree with much of what you say, but I think I just weight things a
little differently, which I guess is another whole topic of discussion
(a bit of which did come up in this thread).

On Mon, May 18, 2020 at 10:54 PM Fred Stluka <fred@bristle.com> wrote:
>
> On 5/13/20 10:30 AM, Rich Freeman wrote:
> See my Unix
> security tips about logwatch, fail2ban, and tripwire

Just on a side note, tripwire is one of those things that I completely
love in concept but it just doesn't work for me, largely because I'm
using source-based rolling release distros for much of what I do.

I think RedHat actually has some good ideas here around their concepts
for a read-only signed /usr and with moving /bin and so on into it.
If you bake the signature verification into everything then you get
most of the benefits of tripwire in an online environment, and of
course you can still do offline verification which would be just as
reliable as tripwire.  It works a lot better for a release-based
distro.  And I'll concede that in most production environments these
distros are generally more appropriate anyway.

> People generally prefer
> cheaper/sooner over better/later.  They're too impatient to put much
> value on secure/private/reliable/etc.
>
> So, better/later cannot compete with cheaper/sooner.  The only
> answer is to switch to better/sooner.  That's what Agile software
> development does, if you follow the spirit of Agile and don't get
> bogged down in any Agile "methodologies".

Sure, but again the issue is that the parts of "better" that the
consumer is willing to pay for are the parts that are more visible to
them.  Obviously crashes bother consumers.  Security issues tend not
to bother them unless they actually get burned by them.

And so companies don't spend on that stuff.

Ultimately it isn't the methodology so much as the requirements that
are the problem here.  Without quoting it though we're largely on the
same page regarding waterfall and how it tends to work in reality in
big companies.

> You're just saying that Windows now
> is more secure than Windows then, right?  That may be true, but
> I've still NEVER had any trouble breaking into any Windows system
> where a client needed access that someone had decided he wasn't
> supposed to have.

Honestly, these clients might not exactly be examples of
best-in-class.  The fact that they're paying you to hack themselves
suggests they've gotten it wrong somewhere along the way.

I'm certainly not suggesting that it is perfect, however.

> None of this can be fixed until Windows does one of the following:
>
> 2. Re-implement the whole file permission mechanism, but
>      applied to branches and keys of the registry, instead of
>      directories and files in the file system.  That is, treat the single
>      registry as an embedded file system, and bake the access
>      rules into the OS.  And then spend lots of time in the future
>      maintaining that entirely unnecessary duplicated effort.

Uh, I believe this has been how the Registry has worked since WinNT.

Filesystems and the Windows registry are really just databases,
obviously optimized for particular types of use.

I think a lot of frustrations with the registry comes down to the fact
that rescue disks with registry editors weren't much of a thing until
relatively recently, while in the Linux world a rescue disk with a
text editor have always been around.  It isn't so much that text files
are better so much that there are so many tools for working with them,
and they tend to be small and preloaded on rescue disks.

> > Second, you're comparing multi-user setups with single-user setups.
>
> OK.  Had to read ahead quite a bit, but I think you're saying that
> the secure ones (mainframes, VAXes, Unix/Linux) are typically
> multi-user systems.  Servers, not desktops.  So security matters.
> So they have security.  Right?

No.

Let's forget about windows entirely and just focus on something like
Ubuntu Desktop installed out of the box following all the
out-of-the-box best in class practices.  Let's go ahead and have
encrypted home directories, encrypted lvm, non-root user using sudo.
Basically turn on all the security-conscious settings that are just
checkboxes, but we won't get into SELinux or some of the more exotic
things that are possible on Linux.

> And why would a Mac or Linux user loosen all the permissions
> when it's so easy to sudo as needed?  My Mac laptop IS basically
> single-user, but I don't just login as root.  I login as the much
> more restricted fred.  That allows the file permissions to prevent
> me from doing something stupid via a simple typo.  And I think
> carefully whenever I use sudo.  I treat my Mac laptop like a
> server.  And I'd treat a Linux laptop like a server too.  Why not?

This is exactly the sort of scenario we're talking about.

> > This has already been argued to death so I'll be brief.  Suppose you
> > are hit by a zero-day on Windows vs Linux in your browser, which is
> > probably any desktop user's single biggest vulnerability window (that
> > and their MUA I guess).  Now some remote code has the ability to
> > execute arbitrary commands using your UID.  Unless you're
> > containerizing your browser/etc that code can already read all your
> > personal info in both scenarios - the only thing it can't do on either
> > platform is modify the core of the OS.  I'd argue that on Windows it
> > can probably tamper with fewer of your settings/etc due to the whole
> > UAC mechanism, while on linux pretty-much anything in
> > .config/.whateverrc and so on is editable without priv escalation.
>
> Wow!  That's a lot of assumptions.  You're basically saying that every
> desktop users logs in as root and runs a browser.  So, if the browser
> is hacked, root access is gained, and it's "game over".  Right?

No.  You're running as fred.  The harmful code can only execute code
under your own fred uid.

It can only read stuff readable by fred.  It can only modify stuff
modifiable as fred.  It can only do the things that you can do.

So, what does that include?

1.  It can read everything in your browser cache and all your browser
cookies.  This can probably be used to authenticate into various
websites.
2.  It can read all your documents.
3.  It can attach to any process running under your uid and read any
memory in these processes.
4.  It can connect to your X11 server and read keystrokes directed at
any window, and capture an image of any window at any time.
5.  It can make arbitrary outbound network connections to anywhere and
send any data it wants out over them (which will usually consist of
all the stuff above).
6.  It can participate in botnets and DDoS attacks and all that good
stuff.  It can hack into random stuff on the internet and the attacks
are traceable to your network.
7.  It can stick whatever it wants in your .bashrc, in various
settings that are executed whenever you log into your desktop
environment, and so on.  So it can have code that persists across
reboots.

None of this stuff requires access to root.

Here is why I mentioned why single- vs multi-user matters.  It is a
mindset thing.

Multi-user OSes like Unix/Linux/etc were largely designed to protect
users from each other.  So in this scenario if you created a non-root
account for me called rich, and my browser got exploited, then the
data stored in your fred account would be perfectly safe.  However,
these OSes generally by default don't protect users from "themselves."
 Granted, we're not talking about "themselves" literally, but to Linux
any code running under your uid is the same as any other code, in the
absence of additional layers of security like SELinux.

So, even if hackers don't gain root access to your box, if they gain
access to the UID of the only human being who actually uses the box,
and it is a desktop, it is basically the same thing.


> > Now, I will concede that Linux has more tools available to lock this
> > stuff down like containerizing applications, or SELinux with
> > fine-grained permissions so that random processes can't just go
> > editing your .bashrc or whatever.  However, most of this stuff is not
> > configured in a typical desktop environment, and even distros that use
> > SELinux by default probably don't lock it down to that degree - it
> > would require a lot more conventions around what goes where in a
> > user's home directory and so on.
>
> Huh?  By default on a Linux desktop, you login as root?  Or all the
> files in the whole tree are chmod 777?  Or what?  Why not leave all
> users files at 755 or less?  Then no rogue process can edit my
> .bashrc.  What conventions are needed about what goes where?
> Just lock down the users tree so only the user can edit it.  That's
> been the default on every Unix/Linux system I've ever used.

So, what I was referring to here is additional security on top of the
built-in user-level security.  That rogue process that is editing your
.bashrc is running under YOUR uid.

The way to block this sort of thing is adding a ton of rules using
something like SELinux.  Maybe you let vim edit .bashrc, but only if
it was spawned by an interactive shell.  Maybe files in
~/Documents/lodocs can only be opened by LibreOffice or Thunderbird.
As you can imagine this can become extremely unwieldy which is why
nobody does it this way, but it is possible.

> Lots of claims that I seriously doubt, and no evidence cited.  This
> is getting a little wacky.  You suspect that iOS is more secure than
> Linux?  Why?

So, I'm less familiar with the internals of iOS, but I believe it does
do application-level sandboxing.

That is, one application on your phone can't read data owned by a
different application on the phone.

On android this is accomplished by giving every application its own
UID, having a mechanism for applications to send data to another
application via OS-mediated APIs (which means the other application
gets to vet things), and then they have a dumping ground area of the
filesystem that anything can access but only if the user gives it
permissions to do so (the "sdcard" area).

I don't know the gory details of how this works on iOS but I'm pretty
sure it also does application-level sandboxing.

I bring these up because they address a real flaw in the natures of
attacks on desktop-oriented OSes.

> It talks about how to clear the TPM.  And says you should always
> do so before disposing of a computer because people can steal
> your keys out of the TPM itself!  Even if you follow that advice,
> what about stolen laptops?  No one warned you it was about to
> be stolen, so you didn't get a chance to clear the keys from the
> TPM.  Doh!

Obviously TPMs, like everything else, are physical implementations and
they can have flaws.  Unfortunately there have been some big ones
lately.

> > Of course not.  Hence the reason I used the word "dated."  I don't
> > think you're making things up - they were different back then.  Maybe
> > if they had more market power they'd be still doing that stuff today.
> > Maybe if RedHat had that kind of market power today they'd be doing
> > that stuff too.
>
> So you trust them because they're weaker and wouldn't dare?
> Doesn't inspire me with confidence...

Actually, I think that is something that SHOULD inspire you with
confidence, because it is an external factor.  It doesn't rely on
their morality, but rather on their power.


> > I'm not sure that they'd
> > have been any more secure if they were using most conventional Linux
> > distros.
>
> Huh?  Do most conventional distros have the single user log in as
> root?

So, I didn't want to go case by case but I deleted a ton of stuff
where you replied to my email just saying that you shouldn't run stuff
as root.

I just suggest you re-read my email keeping in mind that I'm saying
all of these are issues if you behave like a good Linux citizen and
always use sudo and then only with great care.

> > No moreso than anybody really.  You're talking about a company with
> > tens of thousands of employees.  Most of them are going to be just
> > like you or I.  Often you get some really scummy ones at all levels.
> > The ones at the bottom usually are leaches on the company, and the
> > ones at the top tend to be leaches on all of society, but often are
> > leaches on the company too.
>
> See my comment above about a "culture of dishonesty".  You've
> been in this field for a while.  I'm sure there are some entire
> companies that you'd rate as more ethical, more competent,
> better at security, etc. than others.  No, not every single individual
> has the same problems.  But the average can be significantly
> higher for one company than another.  And MS has a LOT of
> inertia to overcome.

I don't really believe that there are any "ethical" companies out
there.  Certainly there are ethical people.  And there are companies
that only have ethical people in them, though I think they get pretty
rare once you are talking about something bigger than a small
consulting shop or startup.

I think the best you can do in terms of corporate ethics is trust that
companies will do what is in their own interest, though their
employees might be looking out for their own personal interests which
could be contrary to this.

Finally, you seem to be under the impression that I generally
recommend Windows over Linux.  On servers that is absolutely not the
case for a bazillion reasons we didn't really go into but I suspect
we're 99% on the same page.  On desktops it is more of a mixed bag.
Software compatibility is obviously the biggest challenge with Linux,
and I'd argue that refinement of experience is another one, though
I've certainly run into my share of persistent windows issues that are
all that much harder to deal with because everything is closed.

My point is more that in a desktop environment the way we use Linux is
often not all that secure against the attacks that happen in the real
world, and Windows is actually not much worse if at all.  They're
different and there are pros and cons.  And of course, a lot has
changed since the 90s in the world of windows.

-- 
Rich
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug