Compartment user sessions using pam_namespace

[KellerFuchs]

• the unmnt_remnt option makes sudo switch to the destination user's namespace;
• {/var,}/tmp and /run/{shm,lock} are poly-instantiated on a per-user basis;
  root gets to escape this and see all instances.

I have been fairly conservative, so this shouldn't break anything.
In particular, I would like (in a future patch) to:

• also poly-instantiate /run/user, and possibly more things in /run, as many services get rather dirty in there;
• have a namespaced /dev which only allows access to pseudo-devices (null, zero, random, ...);
• enforce “read-onlyness” of the system files (equivalent to systemd.exec's ProtectSystem=full);
• only make visible that user's home, to avoid issues like Users have access to others home directory including mail. #11.

Also, I discussed with @lrvick the possibility of using network namespacing to give each user their own IPv6 (though this requires getting IPv6 connectivity first ...).

[KellerFuchs]

Ping?

[daurnimator]

I don't understand the consequences of this enough; it's new to me :) Hoping someone else might know more. @deleriux2 ping?

[KellerFuchs]

2 notes before this gets applied:

1. the directories have to be created (and chmod 000, but that's enforced by pam_namespace);
   systemd-tmpfiles-* need to be restarted;
2. we have to terminate user sessions after applying this to a shell server (otherwise, the user will end up with some different processes having a different idea of what /tmp is, for instance preventing them from connecting to a running tmux).

[KellerFuchs]

Also, ping @lrvick

[KellerFuchs]

No-one interected in reviewing that? :(

FYI, the same config is currently deployed at the local hackerspace, and works great.

[daurnimator]

If no one else replies; I say give it a try and see if it works out :P

[lrvick]

+1 to tias

On Sat, Oct 31, 2015 at 11:17 PM, daurnimator notifications@github.com
wrote:

If no one else replies; I say give it a try and see if it works out :P

—
Reply to this email directly or view it on GitHub
#28 (comment).

Lance R. Vick

---

Cell - 407.283.7596
Gtalk - lance@lrvick.net
Website - http://lrvick.net
PGP Key - http://lrvick.net/0x36C8AAA9.asc
keyserver - subkeys.pgp.net

---

[KellerFuchs]

tias == Try it and see ?

Anyhow, I guess I will try it on da1, once I have the needed access and warned the people using it.

[RyanSquared]

If you want, I think we can set up a temporary server for testing this.

[lrvick]

Yeah do1 is probably fine for the scope of this, then use admin tools to
roll to rest if all is good.

On Fri, Nov 6, 2015 at 7:22 AM, Charles Heywood notifications@github.com
wrote:

If you want, I think we can set up a temporary server for testing this.

—
Reply to this email directly or view it on GitHub
#28 (comment).

Lance R. Vick

---

Cell - 407.283.7596
Gtalk - lance@lrvick.net
Website - http://lrvick.net
PGP Key - http://lrvick.net/0x36C8AAA9.asc
keyserver - subkeys.pgp.net

---

[KellerFuchs]

This shoud also poly-instanciate /dev, given how annoying deployment is going to be.

[KellerFuchs]

Also, let's merge that once emergency root access is sorted out.

[KellerFuchs]

Emergency root access is happening now: hashbang/admin-tools#12 and #62

[KellerFuchs]

Ok, now that emergency root access is sorted out, I will TIAS this on to1.

[KellerFuchs]

Deployed and tested on to1. Caught a pty issue that I didn't hit when testing on my own machine.

That can be deployed to the other boxes by running sync.yml, then terminating all user session (but you might as well just reboot and make us sure nothing is still using the old (vulnerable) libc).

[KellerFuchs]

For the record: deployed everywhere.