5 ms·

I'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 ago
While 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 ago
  Hey, 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!)
  - cyphar 10y ago
    > About ~9min in your talk on a user namespace slide you talk about device creation restrictions implying it is linked to user namespaces [...] No, mknod() is also gated by a capable(CAP_MKNOD) check if the node is a character or block device (see vfs_mknod). Which you can't have if you've created an unprivileged namespace. Devices cgroup is an additional restriction but you hit capable(CAP_MKNOD) long before that check. > Similarly at 19:50 or so I believe the statements about things not working only apply to some container system The entire talk is about rootless containers, so I'm specifically talking about the case where you have only mapped a single user and don't have the ability to modify cgroups. I'm well aware how to grant access to devices if you have root -- the whole point of rootless containers is that you don't have root. ;) > Re: ~32:50 + crystal balling: [...] Yeah, I wrote that slide about 10 minutes before my talk. My point was that I'm really hoping one day we see containers (or specifically the sandboxing capabilities of containers) be integrated into normal applications and extended to the point where every user uses this stuff. And as you said, the main benefit is that you can then apply a bunch of useful security profiles that knock out the low-hanging fruit.
    - contingencies 10y ago
      No, mknod() is also gated by a capable(CAP_MKNOD) check if the node is a character or block device (see vfs_mknod). Which you can't have if you've created an unprivileged namespace. Devices cgroup is an additional restriction but you hit capable(CAP_MKNOD) long before that check. Namespaces (of which there are many, so 'unpriveleged' must be qualified) != cgroup controllers (of which there are similarly many) != capabilities (of which there are also many). IIRC these are separate and no use of one implies the other. Therefore I do not understand your comment and believe it may be in error, as it seemed both in your talk and in this reply that you are implying a link is now implied at the kernel level. I strongly suspect that your impression comes from container userland runtime system specific code (in which my "for some of these comments it depends which container runtime you are using" comment stands), and I strongly doubt it is kernel code, but am always more than willing to be re-educated.
      - 10y ago
- wlamartin 10y ago
  I suppose we'd better return this sculpture we had made then... If you're ever over London way (where most of the CF Garden team are), we'd love to host you for something! Otherwise hopefully some conference overlap.
- hiremaga 10y ago
  You're welcome to drop by most Tuesdays for lunch or breakfast at 8:30 any day of the week, we're at 155 Clarence. Drop me a line at abhih at pivotal.io if you'd like that :)

cyphar 10y ago

While 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 ago
Hey, 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!)
- cyphar 10y ago
  > About ~9min in your talk on a user namespace slide you talk about device creation restrictions implying it is linked to user namespaces [...] No, mknod() is also gated by a capable(CAP_MKNOD) check if the node is a character or block device (see vfs_mknod). Which you can't have if you've created an unprivileged namespace. Devices cgroup is an additional restriction but you hit capable(CAP_MKNOD) long before that check. > Similarly at 19:50 or so I believe the statements about things not working only apply to some container system The entire talk is about rootless containers, so I'm specifically talking about the case where you have only mapped a single user and don't have the ability to modify cgroups. I'm well aware how to grant access to devices if you have root -- the whole point of rootless containers is that you don't have root. ;) > Re: ~32:50 + crystal balling: [...] Yeah, I wrote that slide about 10 minutes before my talk. My point was that I'm really hoping one day we see containers (or specifically the sandboxing capabilities of containers) be integrated into normal applications and extended to the point where every user uses this stuff. And as you said, the main benefit is that you can then apply a bunch of useful security profiles that knock out the low-hanging fruit.
  - contingencies 10y ago
    No, mknod() is also gated by a capable(CAP_MKNOD) check if the node is a character or block device (see vfs_mknod). Which you can't have if you've created an unprivileged namespace. Devices cgroup is an additional restriction but you hit capable(CAP_MKNOD) long before that check. Namespaces (of which there are many, so 'unpriveleged' must be qualified) != cgroup controllers (of which there are similarly many) != capabilities (of which there are also many). IIRC these are separate and no use of one implies the other. Therefore I do not understand your comment and believe it may be in error, as it seemed both in your talk and in this reply that you are implying a link is now implied at the kernel level. I strongly suspect that your impression comes from container userland runtime system specific code (in which my "for some of these comments it depends which container runtime you are using" comment stands), and I strongly doubt it is kernel code, but am always more than willing to be re-educated.
    - 10y ago
wlamartin 10y ago
I suppose we'd better return this sculpture we had made then... If you're ever over London way (where most of the CF Garden team are), we'd love to host you for something! Otherwise hopefully some conference overlap.
hiremaga 10y ago
You're welcome to drop by most Tuesdays for lunch or breakfast at 8:30 any day of the week, we're at 155 Clarence. Drop me a line at abhih at pivotal.io if you'd like that :)