On Jul 29, 2015, at 5:40 PM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote:
>
> On Wed, Jul 29, 2015 at 4:37 PM, Warren Young <wyml@xxxxxxxxxxx> 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?
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
