7 ms·
Rootless containers feature merged into runC
- barbazfoo 10y agoThis is huge, major props to cyphar and the runC folks. Congrats! The result of 11mo of dev work. Dope AF.
- cyphar 10y ago<3 The one thing I've really learned from all of this is just how many different things can break if you take away root privileges from a process. I'm kinda excited to see how much of cri-o and kubernetes we can make run as an unprivileged user (especially given how Cloud Foundry has already taken advantage of this).
- SEJeff 10y agoAnd when we finally bridge the containers seriously with criu for container migrations, wow.
- jacques_chester 10y agoI've been nagging anyone who will listen that this ought to be done. (Easy for me: I don't have to do it. I will of course take credit to the fullest extent the law allows.)
- minimaxir 10y agoA semi off-topic note: As shown in the linked thread, this Hacker News submission was promoted via an image of the submitted link in /newest. This is a modern form of vote manipulation (although in this case perhaps unintentionally) which seems to be the rage nowadays, especially on a certain other social-voting website. (The content of the submission is good/important regardless, but others should keep in mind that this form of voting manipulation isn't clever)
- advisedwang 10y agoI'm not sure I understand how this is vote manipulation? Surely they are just replying to the "somebody should post this to HN" comment by showing that they did? Why does an image get illegitimate votes?
- minimaxir 10y agoPosting an image makes it obvious what to upvote. (as opposed to replying "I posted on Hacker News") But even then that would technically be vote manipulation because it's drawing attention to an immature submission. (and there is little genuine reason to do so. The only counterexample I can think of is using HN as a comments section)
- eriknstr 10y agoThere were 15 participants in the GitHub issue. Hardly enough people to manipulate anything, so obviously that was not the intention. Even though some 300 people are watching the repo as a whole I doubt that many of them would see that particular comment. As the parent to your comment said, a screenshot is a reasonable way to inform the others in the thread that the link has been posted. I am against vote-manipulation of course but I don't think that this is an instance of it.
- MichaelBurge 10y agoThis thread has 71 points in 3 hours. Having 15 people upvote it all at once could get it onto the front page, where it then keep getting upvoted naturally.
- marcosnils 10y ago@minimaxir OP here. I don't really understand why / how this is vote manipulation, and I also wouldn't care either. I'm not a regular HN user. Wouldn't be the same to just reply to the thread by just sharing the thread link?. Just thought that sharing the image would generate a nice impact.
- arianvanp 10y agowhat is the diffference between runc and rkt? they both implement OCI right?
- psiclops 10y agorunc is lower level. Docker uses runc under the hood to run each individual container, and rkt is somewhere in the middle as far as features go http://jvns.ca/blog/2016/10/02/i-just-want-to-run-a-container/ http://jvns.ca/blog/2016/10/02/i-just-want-to-run-a-containe...
- cyphar 10y agoI'd compare runC to LXC as opposed to rkt. It just takes a path and configuration and starts a container, without managing images or networking topologies. rkt is on the same level as cri-o (or containerd) since it also implements image handling as well as other related things. Also, rkt (by default at least) uses systemd-nspawn to create containers. In runC we have our own implementation called libcontainer.
- justincormack 10y agorkt does not implement the OCI runtime spec, which is what runc implements. It supports the OCI image spec.
- arianvanp 10y agowhat is the diffference between runc and rkt? they both implement OCI right?
- 0x006A 10y agorelated talk cyphar gave at linux.conf.au 2017 on this topic: https://www.youtube.com/watch?v=r6EcUyamu94 https://www.youtube.com/watch?v=r6EcUyamu94
- cyphar 10y agoOne thing that really excites me about getting this into runC is that now we can work on making other parts of container orchestration and management run as an unprivileged user. Huge props to the Cloud Foundry team who already have taken rootless containers and have some experimental support for them[1]. It'd be awesome if we could do something similar to Kubernetes so that you could start clusters as an unprivileged user (in my mind the networking is the hardest part and I think the only way right now is to implement pseudo-bridge interfaces in userspace). But I'm pretty excited about the possibilities. :P [1]: https://github.com/cloudfoundry/garden-runc-release/blob/develop/docs/rootless-containers.md https://github.com/cloudfoundry/garden-runc-release/blob/dev...
- jacques_chester 10y agoI'm sure if you ask nicely, Pivotal, IBM, SAP or Google would host a merge party for you. All are present in Sydney. Disclosure: I work for Pivotal.
- cyphar 10y agoWhile it'd be really cool to go to said offices for a merge party, I feel like that might be a bit too self-indulgent. Though meeting some of the Pivotal team in Sydney might be fun. :P
- contingencies 10y agoHey, another Sydneysider here (currently based in China), did some early implementations with LXC, eg. https://github.com/globalcitizen/lxc-gentoo https://github.com/globalcitizen/lxc-gentoo (in US) and talked with the IBM guys at that time. Nitpicks: About ~9min in your talk on a user namespace slide you talk about device creation restrictions implying it is linked to user namespaces but I am pretty sure that is the device cgroup's job and it's possible to bugger that up if you're not careful. Similarly at 19:50 or so I believe the statements about things not working only apply to some container systems, eg. IIRC mknod can be allowed and controlled on a per-major:minor basis via the device cgroup. Another security area I looked at was docker grsec incompatibilities, eg. https://github.com/docker/docker/issues/20303 https://github.com/docker/docker/issues/20303 though didn't get closure despite suggesting what IMHO seems a decent fix. Meh. Re: ~32:50 + crystal balling: My personal impression is that the whole container based infrastructure / development trend will continue to snowball in to larger devops solutions that automatically secure systems in many ways (via cgroup configurations, kernel security toolkit policies such as syscall and device whitelisting, readonly path lockdowns, network traffic and bandwidth restrictions, etc.) over the next few years. Existing tools like atime, fsnotify and network traffic dumps should make this pretty easy. IMHO it should be a natural progression for obtaining low hanging security enhancements currently unused due to configuration complexities. It will be basically enabled through decent workflow (ie. CI/CD + testing), and may result in a "safe CFLAGS"-like set of aggressiveness presets for new services. Thought this out and implemented to some extent while at Kraken (~2011-2015). (Now working on a more hardware/mech eng. related business and am not longer spending time in the area. Down for a drink next trip though, email in profile!)
- ptspts 10y agoWhat is the status of TCP/IP networking in rootless runC? How can incoming and outgoing connections be restricted?
- cyphar 10y agoYou can't both use iptables and have access to host network interfaces (as an unprivileged user), if that's what you mean. You can either create a network namespace and manage network interfaces (but not have a bridge to the host) or just deal with what access you're given. In the future my plan is to write a CNI plugin that implements pseudo-bridges in userspace so that you could get both (though I'm not sure if it'll work at the moment). But if you're an administrator you can restrict it like any other process.
- thinxer 10y agoIs rootless containers safe now? It is not turned on by default in ArchLinux because of security concerns[1]. [1]: https://bugs.archlinux.org/task/36969 https://bugs.archlinux.org/task/36969
- falcolas 10y agoIf a rootless container process runs as the root user and can't be switched, is it considered to be "root" as far as the kernel is concerned? As in, does it have access to root-only kernel features (like the root keychain)?
- cyphar 10y agoNo, the kernel knows what it's "real" UID and GID are. It even knows what unmapped UIDs and GIDs are. I haven't tried to access the root keychain inside a rootless container, but if it does work I would consider that to be a vulnerability in the kernel.