[arch-general] sandboxing

[sivmu]

-- Changed the topic to keep things clean --


Am 01.02.2017 um 21:16 schrieb Leonid Isaev:
> 
> But you see, sandboxing apps is by itself is a misleading security feature. Why
> do I need to sandbox my browser if it is written properly and allows me to
> disable the unnecessary (for me) features?
> 

Sorry to say this, but this is the most disturbingly naive thing I have
read in quite some time.


As a rule, it is said that programms contain one error for every 1000
lines of code.

Firefox contains 14 million lines of code
Chromium has 15,3 million lines

Do the math


No matter how much you focus on secure coding, there will always be
vulnerabilities and sandboxing can help to contain the consequences of
their exploitation.

However it is to be said, that sandboxing does not protect the contained
application and the data it has access to. Therefore sandboxing a
browser will not prevent the compromisation of the data you access with
it. Sandboxing a browser has therefore only limited use.




> In the end, every sandbox uses DAC protection, no? And I already proposed a
> sandbox which is far better than firejail or the one used in chrome, and
> doesn't use userns.
> 

Please take a look at bubblewrap
https://github.com/projectatomic/bubblewrap

On the default arch kernel it does not use user namespaces.

It is also use by tails to sandbox firefox or rather the tor browser


And chromium actually uses quite some nice sandboxing and has become
quite famous for being nearly unbreakable. They also have a bug bounty
programm, so if you find a way to break out of their sandbox you can get
up to 100k. Good luck :)


>>
>> Without any real prove of the claims you made in your post, it seems you
>> rather have a personal grudge against this feature while at the same
>> time saying you know better then all these people.
>> Sorry but that is pretty rich.
> 
> The issue is this: either enable userns fully, i.e. unprivileged users are
> able to create user namespaecs, or don't enable them at all. The way Fedora
> does things, for example, is worse that the latter (of course, if you used
> Fedora you know that it sucks in general).
> 

grsecurity has user namespaces enabled but restricted to privileged
users only. This allows privileged apps like docker to use this feature.
I think they know what they are doing.

btw. what does fedora do exactly? (I think I found somthing about a
kernel module parameter to enable userns. not sure why that is bad)

>> Don’t get me wrong I would love to discuss with you about this all day
>> long but I would like to ask you to reconsider your tone, as you sound
>> incredibly arrogant when you put yourself above all those voices/people
>> without providing real prove for your arguments.
> 
> So, why don't you just build your own kernel? It takes only 20 mins...
> 
> Cheers,
> 

thats not helping. And this is not about me getting this feature but
about a ton of applications that use suid and other shit to work around
this problem, which creates a lot of security problems for arch only.

And yes as pointed out without using these apps the kernel without
userns might be safer, but this still does not solve the general issue.




Am 01.02.2017 um 22:22 schrieb Martin Kühne via arch-general:
> As somebody with no actual knowledge of the details you guys are
> arguing over, but it seems to me OP has yet to learn that a simpler
> and more secure environment can only be achieved by using fewer and
> powerful components instead of many useless ones.

the features in question are inside the kernel and apart from user
namespaces there is no controvery that these features are helpful to
build containers.

But to provide unprivileged users with the ability to use namespaces,
user namespaces are required.


> Okay, there might be
> a point from which the amount of components will add enough obscurity
> to the overall system that simply nobody will bother trying to break
> it, but really, what's the big deal. I think sandboxing is a concept
> reminding too much of windows tools such as bullguard, which simply
> doesn't translate well enough (read: at all) to unixes, so I recommend
> checking whether you can trust the few things you use instead of
> adding a whole bunch of potempkin barriers. It's actually less work
> overall, too.

Not really sure what your point is here.
Sandboxing is not a concept from windows and that bullguard looks like
garbage after 0.1 seconds of looking at is, so no that does not compare.

Sandboxing has many aspects and is not bount to any plattform.

It should be said though, that sandboxing is not a replacement for
secure coding and has its limits.



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