CentOS - Jul 2015 - Fedora change that will probably affect RHEL

On Wed, Jul 29, 2015 at 4:37 PM, Warren Young <wyml at etr-usa.com> wrote:
> Security is *always* opposed to convenience.
False. OS X by default runs only signed binaries, and if they come
from the App Store they run in a sandbox. User gains significant
security with this, and are completely unaware of it. There is no
inconvenience.

What is the inconvenience of encrypting your device compared to the
security? Zero vs a ton more secure (either when turned off and data
is at rest or a remote kill that makes it very fast to effectively
wipe all data)

> I?m still not seeing how it?s difficult to remember, securely record, type,
or transcribe a password that will pass the new restrictions.  They?re on the
mild side, as these things go.
I disagree to the point I'd stop using products based on such
restrictions. I will not participate in security theatre, other than
to be theatrically irritated.

I'm guessing you're not a tester or much of a home user. There are
many such people using OS X, Windows, and yes Fedora and likely
CentOS, where environments and use case preclude compulsory compliance
because the risk is managed in other ways.

And Apple and Microsoft have been working to kill login passwords for
a while. Google and Facebook too. No one likes them. And our trust in
them is diminishing. They are not long term tenable. Making longer
ones compulsory already causes companies who do so grief as people
complain vociferously about such policies.

> I have no strong feelings on the new libpwquality rules, exactly.  What I
do feel strongly about is that there should be *some* reasonable minima that
can?t easily be bypassed.
This idea that opt in is not sufficient demonstrates how archaic and
busted computer security is when you have to become coercive to
everyone regardless of use case to make it safe.

In any case, the complaint over on the Fedora proposal has been
sufficiently addressed, even though the details are still being worked
out. The gist is that the user will have informed consent, and will
opt in to better quality passwords. So they will essentially be told
a. the password they've proposed sucks, b. fairly clear information on
why it sucks, c. the option to change it or continue anyway.

> I don?t see why we can?t take some responsibility for this mess and try to
build up some herd immunity.
Because there is no such thing when it comes to computers. Computers
with strong passphrases still sometimes get pwned, and at a much
higher rate than vaccines not working. Please stop with this hideously
bad analogy. Computers with NO passwords are often not ever getting
pwned for their entire lifetime, and those computers, a.k.a. mobile
devices, are used in public spaces, on public wifi, on public
networks. Anyone without vaccines in such proximity to illness would
definitely get sick. That doesn't happen with computers.

The environment has changed, and the old architectures and methods
aren't working the way they did. And somehow free open source software
has got to do better than it has been with security, because
proprietary systems are innovating more in this space right now, and
aren't passing the buck onto the user with this burden in the form of
stronger password requirements.

Besides, it's FOSS for a reason and people will opt out because
ultimately you can't make them do what you want. Apple and Microsoft
could possibly get away with it. I think their customers would become
foaming irate, however.


-- 
Chris Murphy

On Jul 29, 2015, at 5:40 PM, Chris Murphy <lists at colorremedies.com>
wrote:
> 
> On Wed, Jul 29, 2015 at 4:37 PM, Warren Young <wyml at etr-usa.com>
wrote:
> 
>> Security is *always* opposed to convenience.
> 
> False.  OS X by default runs only signed binaries, and if they come
> from the App Store they run in a sandbox. User gains significant
> security with this, and are completely unaware of it. There is no
> inconvenience.
You must not use OS X regularly, else you?d know there is plenty of
inconvenience in this policy.  There?s a whole lot of good software that is both
unsigned and not in the App Store.  Examples:

a. Most open source software.  Many of these projects (e.g. KiCad) can barely
manage to serve community-provided unsigned binaries on OS X as it is.  Signing
apps and managing the App Store submission process is out of the question.  The
next version of OS X will block all the third-party app repositories (e.g.
Homebrew) by default, in order to provide better security:

  http://www.imore.com/os-x-el-capitan-faq

b. Most network monitoring software, because putting en0 into promiscuous mode
violates the Gatekeeper rules.  (Wireshark, etc.)  Some App Store networking
software (e.g. RubberNet) manages to get around this by offering a second app
download from the author?s web page.  You don?t call that inconvenient?

c. Low-level utilities, such as Karabiner and Scroll Reverser, since they also
need to bypass the sandbox guidelines to do their job.

On top of all that, to bypass Gatekeeper, you need to right-click an app and
disable Gatekeeper for it on the first launch.  Another inconvenience.

I?m not saying Gatekeeper and such are bad, only that they are in fact exemplars
of the rule: better security always causes greater inconvenience.
> What is the inconvenience of encrypting your device compared to the
> security?
I can?t hook my iPad up to my PC and browse it as just another filesystem, as I
can with any other digital camera or MP3 player.  Apple must do this in order to
prevent sideloading malicious apps.

Did you see my exchange with James Byrne?  His bogus counter to my claim that
iPads can?t be turned into botnet conscripts was to point (very indirectly) to a
paper where some researchers found a way to jump through a whole bunch of hoops
to bypass all the security Apple had placed in the path of app sideloading.

Android doesn?t bother with most of this, and what security there is is
bypassable with a checkbox in the Settings app.  Consequence: a whole lot more
Android devices are security-compromised than Apple ones.

So, yet another example where greater security is paid for with greater
inconvenience.

There?s more: Until recently, Android didn?t encrypt the whole device to
anywhere near the same extent that iOS has for years.  Why?  Because it costs
either CPU time (hence more battery) or die space for low-energy hardware
encryption (hence increased device cost).  That?s one of the reasons Apple
devices cost more than Android ones.  That?s not merely an inconvenience for
some, it?s a complete barrier to entry.

Good security is never free.
> I will not participate in security theatre
Really?  You?re going to lay *that* card in this game?

When you stretch words and phrases beyond their original meaning, they lose
shape and utility.

6-9 character password limits are *not* "security theatre?.
> I'm guessing you're not a tester
I write software for a living.  Testing is not my primary job, but I do a fair
bit of it.
> or much of a home user.
I use computers at home far more than is good for me. :)

My home passwords have passed the new libpwquality rules for *years*.

My iOS ones do, too, by the way, despite the increased difficulty of typing
them.  I put too much of my life on them to use 4-digit PINs.
> There are
> many such people using OS X, Windows, and yes Fedora and likely
> CentOS, where environments and use case preclude compulsory compliance
> because the risk is managed in other ways.
The Fedora project leader already said in this thread, multiple times, that this
new policy will not be compulsory.  I?m not asking for that, either.  I?m merely
agreeing that ?double Done? makes the current restrictions so easy to bypass
that they?re basically nonexistent.

I don?t know what Fedora or Red Hat will be doing to allow bypass, but I do know
that libpwquality is configurable:

  http://linux.die.net/man/5/pwquality.conf
>> there should be *some* reasonable minima that can?t easily be bypassed.
> 
> This idea that opt in is not sufficient demonstrates how archaic and
> busted computer security is when you have to become coercive to
> everyone regardless of use case to make it safe.
No, it demonstrates that, left to their own devices, most people will hang their
assets out in the wind for anyone to slap.

There are numerous laws and insurance restrictions that require locks and safety
mechanisms on all sorts of things.  How many of those locks would continue to be
provided as a matter of course if those laws and provisions did not exist?
>> I don?t see why we can?t take some responsibility for this mess and try
to build up some herd immunity.
> 
> Because there is no such thing when it comes to computers.
Pay more attention to history.

Once upon a time, we had the likes of Blaster, Code Red and Nimda, which
continuously flooded the internet with traffic intended to find exploitable
holes in Microsoft OSes.  They kept finding new boxes so frequently that normal
efforts consistent with contemporaneous practice entirely failed to stamp them
out.

  https://en.wikipedia.org/wiki/Code_Red_(computer_worm)
  https://en.wikipedia.org/wiki/Blaster_(computer_worm)
  https://en.wikipedia.org/wiki/Nimda

It got so bad that connecting a new Windows box to the internet without either a
NAT router or a third-party software firewall would almost guarantee an
infection within minutes:

  http://blog.chron.com/techblog/2008/07/average-time-to-infection-4-minutes/

Then Windows XP SP2 came out, with Microsoft?s first enabled-by-default
firewall, and these worms quickly died out.  Windows acquired herd immunity to
this whole class of attack.

Yes, herd immunity.  There are still a few pre-SP2 XP boxes out there, but NAT
routers and low infection rates mean the old 4-minuutes-to-infection rule no
longer applies.

We didn?t get the immunity without a cost.  I used to be able to ?message? a
remote Windows computer merely by knowing its IP, and I could browse its
registry without jumping through hoops.  Can?t do that any more.

Meanwhile over here in CentOS land, you still see SSH password guessers banging
on every public IP that responds to port 22.  Why?  Because it still
occasionally works.  Increase the password strength minima, and this class of
worm, too, will quickly die out.
> Computers with strong passphrases still sometimes get pwned
The occasional failure of a prophylactic measure does not tell you that you
should discontinue its use.
> and at a much higher rate than vaccines not working.
I thought you threw out a 95% number for vaccine effectiveness above.  You are
saying that more than 5% of all computers with strong passphrases are currently
infected with something?  Prove it.
> Anyone without vaccines in such proximity to illness would
> definitely get sick.
Not true.  Some people have innate immunity, and others can fight off the
infection.

This doesn?t demolish the analogy, though, it just shows that computers are even
worse than humans at fighting off attacks.  Unlike humans, computers either have
a block already in place against the attack, or they do not.
> The environment has changed, and the old architectures and methods
> aren't working the way they did. And somehow free open source software
> has got to do better than it has been with security, because
> proprietary systems are innovating more in this space right now, and
> aren't passing the buck onto the user with this burden in the form of
> stronger password requirements.
So your solution is to wait for unspecified innovations to come?  All these
problems will go away in the indefinite future, so we should do nothing now?

On Thu, Jul 30, 2015 at 1:20 PM, Warren Young <wyml at etr-usa.com> wrote:
> On Jul 29, 2015, at 5:40 PM, Chris Murphy <lists at
colorremedies.com> wrote:
> >
> > On Wed, Jul 29, 2015 at 4:37 PM, Warren Young <wyml at
etr-usa.com> wrote:
> >
> >> Security is *always* opposed to convenience.
> >
> > False.  OS X by default runs only signed binaries, and if they come
> > from the App Store they run in a sandbox. User gains significant
> > security with this, and are completely unaware of it. There is no
> > inconvenience.
>
> You must not use OS X regularly, else you?d know there is plenty of
> inconvenience in this policy.  There?s a whole lot of good software that is
> both unsigned and not in the App Store.  Examples:
>
> a. Most open source software.  Many of these projects (e.g. KiCad) can
> barely manage to serve community-provided unsigned binaries on OS X as it
> is.  Signing apps and managing the App Store submission process is out of
> the question.  The next version of OS X will block all the third-party app
> repositories (e.g. Homebrew) by default, in order to provide better
> security:
>
>   http://www.imore.com/os-x-el-capitan-faq
>
> b. Most network monitoring software, because putting en0 into promiscuous
> mode violates the Gatekeeper rules.  (Wireshark, etc.)  Some App Store
> networking software (e.g. RubberNet) manages to get around this by offering
> a second app download from the author?s web page.  You don?t call that
> inconvenient?
>
> c. Low-level utilities, such as Karabiner and Scroll Reverser, since they
> also need to bypass the sandbox guidelines to do their job.
>
> On top of all that, to bypass Gatekeeper, you need to right-click an app
> and disable Gatekeeper for it on the first launch.  Another inconvenience.
>
> I?m not saying Gatekeeper and such are bad, only that they are in fact
> exemplars of the rule: better security always causes greater inconvenience.
>
> > What is the inconvenience of encrypting your device compared to the
> > security?
>
> I can?t hook my iPad up to my PC and browse it as just another filesystem,
> as I can with any other digital camera or MP3 player.  Apple must do this
> in order to prevent sideloading malicious apps.
>
> Did you see my exchange with James Byrne?  His bogus counter to my claim
> that iPads
>
+Snip+

Can someone mod this thread, I'm sure everyone has an opinion about this I
know I do and obviously so do other but I think the fedora mail list would
be more suited to this discussion.

I think enough points and counter points have been said, lets move onto
more relevant Centos Topics.

Thanks

On Thu, Jul 30, 2015 at 12:20 PM, Warren Young <wyml at etr-usa.com>
wrote:
> On Jul 29, 2015, at 5:40 PM, Chris Murphy <lists at
colorremedies.com> wrote:
>>
>> On Wed, Jul 29, 2015 at 4:37 PM, Warren Young <wyml at
etr-usa.com> wrote:
>>
>>> Security is *always* opposed to convenience.
>>
>> False.  OS X by default runs only signed binaries, and if they come
>> from the App Store they run in a sandbox. User gains significant
>> security with this, and are completely unaware of it. There is no
>> inconvenience.
>
> You must not use OS X regularly, else you?d know there is plenty of
inconvenience in this policy.
Really, I must not, even though it's roughly 80/20 OS X to Fedora...

>  There?s a whole lot of good software that is both unsigned and not in the
App Store.  Examples:
Spare me. The fact it is imperfect is meaningless to the discussion.
The original argument was that security increase always cause user
inconvenience. That is not true. Millions of users using tens of
thousands of applications in an eco system they see no problem with,
unaware that those applications are code signed, and no concern at all
about the alternatives. Good for them, they're safer than without code
signing and their life has not been made inconvenient as a result.

That this needs to be expanded, made easier, made more open, so that
it's not just customers using proprietary software who benefit from
stronger security measures with minimal usability impact.

>
>> What is the inconvenience of encrypting your device compared to the
>> security?
>
> I can?t hook my iPad up to my PC and browse it as just another filesystem,
as I can with any other digital camera or MP3 player.  Apple must do this in
order to prevent sideloading malicious apps.
OK one of us must have the self control to stop, because your
arguments are terrible and I'm losing patience.

What you just claimed, has nothing to do with encryption. It has
everything to do with Apple simply not treating their devices as mass
storage devices which they haven't done since forever - even without
encryption.

And Android is the same. Whether encrypted or not, it's not a mass
storage device, you can't mount the file system. It supports MTP,
whether encrypted or not. JFC....

>> I will not participate in security theatre
>
> Really?  You?re going to lay *that* card in this game?
>
> When you stretch words and phrases beyond their original meaning, they lose
shape and utility.
>
> 6-9 character password limits are *not* "security theatre?.
Ok well I consider passwords that keep the dog out and probably most
family members to be security theater.

No fail2ban, no firewall rules, sshd by default, challengeresponseauth
by default, and a 9 character (even random) passphrase, and that shit
is going to get busted into. Against a targeted attack by a botnet,
you need something stronger than a 9 character password, today. Let
alone 6 years from now.

Those other measures need to get better (PKA only, put it behind a
VPN). Not the password getting slightly longer.

ATMs and credit cards in the U.S. The weak link is the magnetic
stripe, not the 4 digit PIN. The enhancement for credit cards due this
year is not 5 or 6 digit PINs. It's EMV chips. And the end user will
be minimally affected in terms of usability, the security will be
vastly better than even if 5 or 6 digit PINs were employed and besides
no one would accept that anyway.

And that's where we are with computers and passwords.

> Meanwhile over here in CentOS land, you still see SSH password guessers
banging on every public IP that responds to port 22.  Why?  Because it still
occasionally works.  Increase the password strength minima, and this class of
worm, too, will quickly die out.
No they just get better, like they have been, at an exponential rate
compared to our ability to recall login passwords.


>
>> Computers with strong passphrases still sometimes get pwned
>
> The occasional failure of a prophylactic measure does not tell you that you
should discontinue its use.
>
>> and at a much higher rate than vaccines not working.
>
> I thought you threw out a 95% number for vaccine effectiveness above.  You
are saying that more than 5% of all computers with strong passphrases are
currently infected with something?  Prove it.

Define strong. Diceware puts the minimum for large botnet protection
at 5 word passphrases. 6 word passphrases for protection against a
government entity. Your idea of strong thus far is 9 characters which
seems to be b.s. today and certainly laughable in 6 years when we do
the autopsy on today's policy successes and failures.

> So your solution is to wait for unspecified innovations to come?  All these
problems will go away in the indefinite future, so we should do nothing now?
I did say disable sshd by default, and several other suggestions many
of which could be done right now. That you gloss over this and turn it
into this pile of crap leading questions is fairly disqualifying in
debate. Each suggestion has greater security efficacy than a 2-3
character increase in password length.


-- 
Chris Murphy

> On Jul 30, 2015, at 12:20, Warren Young <wyml at etr-usa.com> wrote:
> 
> Meanwhile over here in CentOS land, you still see SSH password guessers
banging on every public IP that responds to port 22.  Why?  Because it still
occasionally works.  Increase the password strength minima, and this class of
worm, too, will quickly die out.
If the Windows fix was firewall on by default, why isn?t that the appropriate
?fix" for Linux distros? Why mess with the password strength or which
daemons are running?

Seems like it adds the necessary step of ?STOP: If you turn off this, you?d
better know what you?re doing?, without messing around with default settings of
packages and/or password library configuration files.

?
Nate