[arch-general] user namespaces

[Eli Schwartz]

On 02/02/2017 10:29 AM, sivmu wrote:
> Am 02.02.2017 um 11:28 schrieb Daniel Micay via arch-general:
>> On Thu, 2017-02-02 at 02:40 +0100, sivmu wrote:
>>> Am 01.02.2017 um 21:21 schrieb Daniel Micay via arch-general:
>>>>>> it's a nearly useless feature. 
>>>>>
>>>>> That's a baseless claim, that was already proved wrong in my first
>>>>> post
>>>>> by the many applications that use this feature.
>>>>
>>>> That doesn't demonstrate that it's useful relative to the
>>>> alternatives.
>>>> It enables unprivileged OS containers but isn't really any use for
>>>> app
>>>> containers.
>>>
>>> Pretty much all famous container programms use this. I wonder why if
>>> there is no use for it.
>>>
>>> Also I would still like to see a simple alternative for unprivileged
>>> namespaces to sandbox apps.
>>> How do you provide something like bubblewrap without user namespaces?
>>> And no that android example below is not the same as long as there is
>>> no
>>> simple way to use this (which I am not aware of)
>>
>> Doing things properly is not easy.
>>
> 
> That's a bad attitude. It sounds like proper implementations need to be
> difficult. That's not true. Especially security and above all crypto
> fails often because it is hard to apply. That is why people like Bruce
> Schneier have often talked about this. Dan Bernstein has created the
> crypto library NaCl for that very reason, to allow the use of crypto
> without overly complex and error prone implementations like needed by
> openssl.
> 
> That is why this sentence is extremly wrong and dangerous.
> If there is no way to privide users or developers with easy tools to
> sandbox apps, then one has to be created. Just saying that doing things
> properly isn't easy will do more harm then features like user namespaces
> will ever be able to.
> 
> And if I am not mistaken, that is pretty much what android does: it
> provides app developers with easy ways to drop privileges and sandbox
> their apps.
> 
> Therefore I think the wish and need for easy ways to privode security is
> important.
> 
> Bubblewrap is one of the concepts that I think do a great job on
> providing easy isolation of apps, even if they utilise namespaces for
> that purpose. (The Tor people seem to agree)

Up until here, I was watching this thread with some interest, despite
knowing very little about security myself. But I've finally realized you
are blatantly trolling. It took a while, despite your extremely
aggressive attitude towards people who actually know what they are
talking about and disagree with you, but I like to give people the
benefit of the doubt...

This is *so wrong*, for multiple meanings of the word wrong. You're not
even comparing apples to oranges, you're comparing apples to... I don't
know, maybe small decorative handcarved wooden knickknacks purporting to
be sourced from a Native American reservation.

Having someone who works full time on infosec and is one of the core
developers for Arch Linux tell you "designing properly-secure backends
for sandboxing that don't have security holes -- either through design
or bugs -- is hard work and therefor not easy to accomplish" and
responding "OMG you're evil and dangerous and have a bad attitude and
stuff, because you are promulgating the belief that security libraries
should have inscrutable APIs which make it harder for downstream
developers to make use of them" is just a flat-out mudslinging lie.

You have proven that your only interest in starting this thread is to
troll, sling mud at the people responsible for disabling your precious
features, and stir up trouble in the process.

Please consider taking a break from the internet while you cool down.

Also I strongly urge everyone else here to do as I did, and add this
thread to your spam filter. Continuing to reply to this trollish
behavior can only cause more fighting, it will most assuredly not
produce useful results.

-- 
Eli Schwartz

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20170202/4aa69fd0/attachment.asc>