Project

General

Profile

Feature #6178

Evaluate current state of Linux namespaces

Added by intrigeri about 6 years ago. Updated about 1 year ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
07/20/2013
Due date:
% Done:

0%

Feature Branch:
Type of work:
Research
Starter:
Yes
Affected tool:

Description

We should evaluate if a container-based solution (e.g. LXC or unshare(1)) is now a viable, secure-enough solution for creating isolated jails.

See the blueprint for the current state of our research.


Related issues

Related to Tails - Feature #5525: Sandbox the web browser Resolved 01/24/2015 02/04/2015
Related to Tails - Bug #9534: Tighten AppArmor policy Resolved 06/04/2015
Related to Tails - Feature #15874: Start looking at snaps/Flatpak for sandboxing Confirmed 08/30/2018

History

#1 Updated by intrigeri over 5 years ago

  • Description updated (diff)

#2 Updated by intrigeri over 5 years ago

  • Description updated (diff)

#3 Updated by Dr_Whax over 5 years ago

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

Spender: if you were using grsec1, 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 NNP2 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 over 5 years ago

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 about 5 years ago

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.

#6 Updated by intrigeri about 5 years ago

  • Assignee set to Dr_Whax
  • QA Check set to Info Needed

#7 Updated by intrigeri about 5 years ago

  • Description updated (diff)
  • Blueprint set to https://tails.boum.org/blueprint/Linux_containers/

#8 Updated by intrigeri almost 5 years ago

#9 Updated by intrigeri over 4 years ago

#10 Updated by intrigeri over 4 years ago

#11 Updated by Dr_Whax about 4 years ago

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:

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

#12 Updated by intrigeri over 2 years ago

  • Related to Bug #9534: Tighten AppArmor policy added

#13 Updated by intrigeri over 2 years ago

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 :)

#14 Updated by u about 2 years ago

  • QA Check deleted (Info Needed)

Info has been provided it seems.

#15 Updated by Dr_Whax about 1 year ago

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..

#16 Updated by intrigeri about 1 year ago

  • Related to Feature #15874: Start looking at snaps/Flatpak for sandboxing added

#17 Updated by intrigeri about 1 year ago

#18 Updated by intrigeri about 1 year ago

  • Status changed from Confirmed to Rejected
  • Assignee deleted (Dr_Whax)

Next step is #15874.

Also available in: Atom PDF