[Bash & Docker] Namespaces

namespace

While chroot is a pretty straightforward, namespaces and cgroups are a bit more nebulous to understand but no less important. Both of these next two features are for security and resource management.

Let's say you're running a big server that's in your home and you're selling space to other people (that you don't know) to run their code on your server. What sort of concerns would you have? Let's say you have Alice and Bob who are running e-commerce services dealing with lots of money. They themselves are good citizens of the servers and minding their own business. But then you have Eve join the server who has other intentions: she wants to steal money, source code, and whatever else she can get her hands on from your other tenants on the server. If just gave all three them root access to server, what's to stop Eve from taking everything? Or what if she just wants to disrupt their businesses, even if she's not stealing anything?

Your first line of defense is that you could log them into chroot'd environments and limit them to only those. Great! Now they can't see each others' files. Problem solved? Well, no, not quite yet. Despite the fact that she can't see the files, she can still see all the processes going on on the computer. She can kill processes, unmount filesystem and potentially even hijack processes.

Enter namespaces. Namespaces allow you to hide processes from other processes. If we give each chroot'd environment different sets of namespaces, now Alice, Bob, and Eve can't see each others' processes (they even get different process PIDs, or process IDs, so they can't guess what the others have) and you can't steal or hijack what you can't see!

There's a lot more depth to namespaces beyond what I've outlined here. The above is describing just the UTS (or UNIX Timesharing) namespace. There are more namespaces as well and this will help these containers stay isloated from each other.

The problem with chroot alone

Now, this isn't secure. The only thing we've protected is the file system, mostly.

  1. chroot in a terminal into our environment
  2. In another terminal, run docker exec -it docker-host bash. This will get another terminal session #2 for us (I'll refer to the chroot'd environment as #1)
  3. Run tail -f /my-new-root/secret.txt & in #2. This will start an infinitely running process in the background.
  4. Run ps to see the process list in #2 and see the tail process running. Copy the PID (process ID) for the tail process.
  5. In #1, the chroot'd shell, run kill <PID you just copied>. This will kill the tail process from inside the chroot'd environment. This is a problem because that means chroot isn't enough to isolate someone. We need more barriers. This is just one problem, processes, but it's illustrative that we need more isolation beyond just the file system.

Safety with namespaces

So let's create a chroot'd environment now that's isolated using namespaces using a new command: unshareunshare creates a new isolated namespace from its parent (so you, the server provider can't spy on Bob nor Alice either) and all other future tenants. Run this:

NOTE: This next command downloads about 150MB and takes at least a few minutes to run.

exit # from our chroot'd environment if you're still running it, if not skip this

# install debootstrap
apt-get update -y
apt-get install debootstrap -y
debootstrap --variant=minbase bionic /better-root

# head into the new namespace'd, chroot'd environment
unshare --mount --uts --ipc --net --pid --fork --user --map-root-user chroot /better-root bash # this also chroot's for us
mount -t proc none /proc # process namespace
mount -t sysfs none /sys # filesystem
mount -t tmpfs none /tmp # filesystem

This will create a new environment that's isolated on the system with its own PIDs, mounts (like storage and volumes), and network stack. Now we can't see any of the processes!

Now try our previous exercise again.

  1. Run tail -f /my-new-root/secret.txt & from #2 (not the unshare env)
  2. Run ps from #1, grab pid for tail
  3. Run kill <pid for tail>, see that it doesn't work

We used namespaces to protect our processes! We could explore the other namespaces but know it's a similar exercise: using namespaces to restrict capabilities of containers to interfering with other containers (both for nefarious purposes and to protect ourselves from ourselves.)

namespaces only hide process, so clients cannot see each other; but it doesn't prevent one process take all the memory or CPU power, how to limit memory usage and CPU for one process, this is what CGROUP does.

posted @   Zhentiw  阅读(8)  评论(0编辑  收藏  举报
相关博文:
阅读排行:
· 阿里最新开源QwQ-32B,效果媲美deepseek-r1满血版,部署成本又又又降低了!
· Manus重磅发布:全球首款通用AI代理技术深度解析与实战指南
· 开源Multi-agent AI智能体框架aevatar.ai,欢迎大家贡献代码
· 被坑几百块钱后,我竟然真的恢复了删除的微信聊天记录!
· AI技术革命,工作效率10个最佳AI工具
历史上的今天:
2022-07-25 [Typescript] Excess property checking
2021-07-25 [SAA + SAP] 09. DynamoDB
2018-07-25 [Vue @Component] Write Vue Functional Components Inline
2017-07-25 [Nuxt] Display Vuex Data Differently in Each Page of Nuxt and Vue.js
2017-07-25 [Nuxt] Update State with Vuex Actions in Nuxt.js
2017-07-25 [Nuxt] Use Vuex Actions to Delete Data from APIs in Nuxt and Vue.js
2017-07-25 [Nuxt] Build a Vue.js Form then use Vuex Actions to Post to an API in Nuxt
点击右上角即可分享
微信分享提示