On Thu, Jul 30, 2015 at 9:10 AM, Lamar Owen <lowen@xxxxxxxx> wrote:
> On 07/29/2015 07:40 PM, Chris Murphy 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.
>
>
> While I agree with you about the long-term viability of passwords, I'll
> disagree with this statement. There is a loss of convenience with signed
> binaries from a store: the user can no longer install directly from the
> program vendor's website but must go through the walled garden of the store,
This is untrue. Apple's developer program and OS X support two kinds
of code signed applications: App Store programs are signed by the
developer and Apple and only run in a sandbox limiting their
interaction with each other; and developer only signed applications,
which can opt into App Sandbox, and users can install these
applications normally including from the vendor's web site. Both types
of applications can be installed and executed by default. Unsigned
applications will not execute by default. An admin user can change
this and permit those applications to run - in fact the user has the
ability to grant an exception *per application*.
I have a litany of criticisms of the Apple developer program, but
those aren't relevant to this discussion. What is relevant is that
both developers and users in the OS X "walled garden" have a security
advantage with almost no inconvenience.
Now I see that the "Docker Engine will now automatically verify the
provenance and integrity of all Official Repos using digital
signatures." So that's a good thing on Linux, but it is far away from
ubiquitous let alone a default behavior.
> and developers are held hostage to having to meet the store's policy or get
> their signing key revoked and/or their app 'de-stored' or worse. There is
> significant inconvenience to users when their app is removed from the store
> for whatever reason and they cannot get updates (or reinstall their app, for
> which they may have paid a fee) anymore because the app is no longer in the
> store (and that could be for arbitrary reasons, including political ones).
These are all implementation criticisms. The idea of code signing is
valid and useful. Apple made it really quite easy for users, mostly
easy for developers, and that's the part that absolutely should be
replicated in free software. But that part is orthogonal to the thick
layer added on that is Apple's unique process, and I'm in no way
suggesting that part is a model, nor should it be suggested its
inextricably attached to the code signing concept.
I very much disagree with any sentiment that users, even sysadmins,
should be security experts. This shit is too complicated for that. The
penalty for getting it wrong is too high.
This idea that minimally better password quality is going to stop jack
shit? I don't buy it. It will stop Tonka Toy type attacks. It's not
going to stop anything moderately serious or more, to do that means
adopting best practices.
Again, I don't know who puts computers with sshd enabled with
challengeresponseauth directly facing the Internet, but that to me
sounds like a bad choice. I have to access all clients' servers
through a VPN first, none of them have such services Internet facing.
> Or a hackable remote kill that allows an attacker to wipe you device out
> from under you. Or now the inconvenience of losing access to the encrypted
> volume because you forgot the exact spelling of that ten word seventy-five
> character passphrase and you're locked out and no data recovery tool out
> there will get your files back.
>
> Security and convenience are always at odds with each other; more secure =
> less convenient in some form or fashion; even if you have to dig for the
> loss of convenience there will be a loss of convenience somewhere for
> increased security.
The security increase of even minimally higher quality passphrases is
less than the increase in inconvenience to the end user. And that
includes sysadmins. So full circle is that I think it's a bad idea for
sysadmins to be coddled into thinking that a GUI installer enforcing 8
character passwords instead of 6 means anything has actually improved.
It's still merely just treading water (or maybe sinking to the bottom
at the same rate). And in contrast to that, the same system blindly
enables sshd by default and also with challengeresponseauth. When I
called this password quality change concept turd polishing, I mean
leaving sshd enabled by default with challengeresponseauth is the turd
and polishing it is trying to protect this with an 8 character
password instead of 6 makes the former OK (and shinier). It's an
absurd juxtaposition.
Had the proposal been a compulsory 16 character passphrase, I merely
would have gone and made some popcorn. I'd have nothing to say about
that. Because at least *that* would be a meaningful increase in
minimum password quality, but holy hell people would have totally f'n
flipped out if they had to pick a 16 character password to install an
OS.
--
Chris Murphy
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
