Tails

#3 Updated by Dr_Whax 2014-03-02 12:36:46

I asked Spender who works on Grsecurity what his view on this ticket is. Basically what he said is:

Spender: if you were using grsec[1], that existing chroot would be effectively equivalent to the namespaces, minus the extra work. What I don’t see there is any discussion of what you want that you don’t have now and what the attack vectors are. For instance, if you’re worried about exploiting suid/sgid bins, then NNP[2] is an option too.

So what we should discuss is, what do we care about when we want to harden the browsers and Tor? I’m afraid that with existing namespaces and without a patched kernel with Grsec, we basically provide security with the equivalent of a chroot (hint, that isn’t a lot of security). I would even add Pidgin to the list of things to harden here, since it’s a castle made of sand.

My 0,02.

[1] https://grsecurity.net/
[2] “No New Privileges” [PR_SET_NO_NEW_PRIVS prctl]

#4 Updated by intrigeri 2014-03-04 00:22:44

Thank you for working on this!

Dr_Whax wrote:
> I’m afraid that with existing namespaces and without a patched kernel with Grsec, we basically provide security with the equivalent of a chroot (hint, that isn’t a lot of security).

The way I understand Spender’s comment, “namespaces = chroot as improved by grsec +
more work”, not “namespaces = chroot”. Did I miss anything?

BTW, this is Tails 2.0 material, not a WIP, that’s why the actual threat model etc. has not been thought through yet. Of course, you are more than welcome to work on this before 1.1 is out, but I just wanted to make clear you are walking in unknown territory, and the rest of the team will be swamped with the work towards Tails 1.0 and 1.1 until mid-June, so perhaps not very reactive on this topic.

#5 Updated by Dr_Whax 2014-07-10 15:54:56

SubgraphOS will be based on Grsecurity and LXC. Effectively, the namespaces get the same security properties as the host machine with a GRSecurity kernel.

Using just LXC will be raising the bar a little bit for an attacker to try and break-out of this. But as Spender said, it’s just a chroot and if we are not careful, we might introduce more vulnerabilities than fixing them.

I will ping the SubgraphOS people on how they plan to implement LXC.

#11 Updated by Dr_Whax 2015-07-01 13:55:29

intrigeri wrote:
> Dr_Whax wrote:
> > I will ping the SubgraphOS people on how they plan to implement LXC.
>
> Any news on that one?
>
> I’ve read somewhere that they use LXC + xpra. In this vein, we should have a look at:
>
> * http://pleonasm.info/blog/2012/10/privilege-separation-with-xpra/
> * https://github.com/rogaha/docker-desktop
> * https://www.stgraber.org/2013/12/20/lxc-1-0-blog-post-series/ and especially https://www.stgraber.org/2014/02/09/lxc-1-0-gui-in-containers/
> * https://unix.stackexchange.com/questions/134939/x-and-xdotool-in-lxc-instead-of-kvm
> * https://stackoverflow.com/questions/16296753/can-you-run-gui-apps-in-a-docker

They have open sourced their sandboxing method: https://github.com/subgraph/oz i’ll update the blueprint accordingly.

#13 Updated by intrigeri 2017-06-05 14:15:24

There’s been a huge amount of progress on this front in the last 2-3 years, both in the Linux kernel and on sandboxing wrappers. I’m confident we can start making good use of it as soon as we have time to invest there :)

#15 Updated by Dr_Whax 2018-08-25 13:00:38

ChromeOS recently introduced Linux containers, so you’re able to run you’re own Debian container/vm within ChromeOS.

The design is outlined here: https://chromium.googlesource.com/chromiumos/docs/+/master/containers_and_vms.md

There’s some open issues like no sound or accelerated graphics from within the container but these are open issues for now. Hopefully, Google either improves it upstream or similar so we all benefit from it.

Will update the blueprint with this link. My own chromebook won’t be supported so I unfortunately can’t test it out. But i’m curious how they’ll introduce this UX/UI wise into chromeos..