8 ms·

As an experienced RHEL admin, a few years ago I probably would have said this is very bad advice in any professional context, and you should spend the time to l

As an experienced RHEL admin, a few years ago I probably would have said this is very bad advice in any professional context, and you should spend the time to learn it because it will save you one day. Now, I think my advice would be: Put everything in a container, and learn how to run Docker or Podman (or k8s) in a secure way (ie no root containers, be very careful with volume mounts, etc). Yes, they aren’t as mature as SELinux, but containers aim to provide many of the same benefits that SELinux does (and even more) except in a way that’s much easier to manage. Even better is that these container runtimes often come with SELinux and AppArmor policies out of the box on good Linux distros.

devman0 4y ago
I was about to argue with you until I read to your last point. Totally agree one of the great things about containers is indeed they integrate very well with various Mandatory Access Control implementations SELinux included and don't generally require specialized policies for each app.
ximm 4y ago
I agree that containers are easier to manage than SELinux, but still not easy enough. Linux provides many low level primitives for restricting applications and SELinux, Apparmor, Docker, Flatpak, and systemd all provide high level abstractions for those. But IMHO none of them really finds a sweet spot between flexibility and usability. `systemd-analyze security` for example lists 80 (!) different settings, even though some of them are very high level such as `ProtectSystem`. Containers have made the conceptual shift from allow/deny to isolate/share. Somehow this feels better even though it is effecitvely the same. I am still waiting for an abstraction that uses all the low level features and wraps them in a high-level interface that puts usability front and center. I am not sure if this is even possible though because many applications are not built with sandboxing in mind. Adding another file somewhere on the system that needs to be accessed is not considered a breaking change by most. So maybe we need a more fundamental shift.
- zozbot234 4y ago
  > I am still waiting for an abstraction that uses all the low level features and wraps them in a high-level interface that puts usability front and center. Bubblewrap? FlatPak's sandboxing features are built on it already.
- tinco 4y ago
  In my opinion, if an application requires more access than a docker container gives by default, then that application should probably just run in a VM. If the application needs more access because it needs to manage or control some hardware, then it should be tailored to the O/S and have a small core service that runs naked under systemd or whatever. If fancy management of that core service is needed, it can expose a port that an application can talk to, that's safely isolated in a docker container. Maybe that's just daydreaming about a perfect world, but I agree that it should be easy to reason about the access levels.
  - ximm 4y ago
    What about an application like vim? It should be able to access any file I pass that is explicitly opened, but not much more. That is hard to express with current tooling.
    - tinco 4y ago
      You shouldn't run an application like vim in Docker. Unless your server is running Vim as some sort of service, in which case it should only open files in a volume you bound to it. Vim is exactly the kind of application you would run in a virtual machine.
    - legalcorrection 4y ago
      You could do it with a file picker API that opened an out-of-process file picker. I'm pretty sure this is how WinRT works. Would be tricky for a purely command line workflow, but very doable with a GUI.
      - 4y ago
tpetry 4y ago
And when everything is in docker you can use SELinux again: A docker container is not allowed to access the host system or access the filesystem of other containers. That‘s the default. SELinux protection without any weird problems.
bitcharmer 4y ago
Container approach is not always feasible, for example when you need to stay on bare metal. There are Linux applications where selinux definitely gets in your way and there are legitimate reasons to turn it off completely. edit: I like how I'm getting down-voted for sharing factual information. No-one in high frequency trading employs containers because it doesn't help soft-realtime, low-latency goals. There are other performance-sensitive domains where containers aren't an option. Sometimes I feel like this place is turning into Reddit.
- TheDong 4y ago
  > when you need to stay on bare metal What cases can linux containers not handle? Containers can access GPUs, /dev/kvm, block devices... I'm having trouble thinking of anything they can't do. After all, they're just processes in a glorified chroot, not that different from processes on the linux host.
  - Gigachad 4y ago
    Not sure about need but I do remember it being a pain in the ass to run anything that expects to be managing docker inside docker. Things like self hosted gitlab ci where its trying to start up containers itself.
    - KronisLV 4y ago
      > ...anything that expects to be managing docker inside docker. Now that's an interesting problem to have! If you trust those tools and don't have untrusted users or untrusted code, you can sometimes just mount /var/run/docker.sock and use the VM/VPS/server's Docker directly. It is actually the approach that was used by excellent tools like Portainer, though it's also really risky as well. Alternatively, you can try to just run Docker in Docker (DinD), which is a bit more tricky and the opinions there are split about whether to do it and when to do it: https://github.com/jpetazzo/dind https://github.com/jpetazzo/dind Of course, someone might also jump in and suggest that Docker is architecturally problematic (i don't care much, just want my containers to run, then again; i don't deal with untrusted code or any sort of multitenancy) and you should use Podman or another set of technologies, which is interesting advice but would necessitate other approaches. In short, like with most technologies: Docker and OCI container in general get more messy as your requirements become more advanced. For the problems that they do solve easily (app packaging), they are pretty good, though!
patrck 4y ago
A couple sysadm red flags: 1) The article author is Testing in PROD 2) selinux debugging relies on auditd, so sanity checks required. df -P /var/log/audit # has space? tail -1 /var/log/audit/audit.log # is recent? semodule -DB # disable dontaudit setenforce 0 # run the failing test audit2allow -l After which the selinux debugging experience boils down to: mk_semod() { module_name=$1; shift audit2allow -l -m ${module_name} -a > ${module_name}.te $EDITOR ${module_name}.te || return checkmodule -M -m -o ${module_name}.mod ${module_name}.te semodule_package -o ${module_name}.pp -m ${module_name}.mod semodule -i ${module_name}.pp }
- kelnos 4y ago
  I think you just proved the author's point. That looks entirely inscrutable.
seodisparate 4y ago
As a lightweight alternative to Docker-based (or any container-based) solutions: Try firejail. You can set up a directory that will be the "home" of the sandboxed application you're running, then you can do something like `firejail --private="${HOME}/my_firefox_jail" firefox`. There are built-in profiles for many applications already, and you can customize them (by adding `.local` files, not editing the existing `.profile` files). See the following link for details. https://wiki.archlinux.org/title/Firejail https://wiki.archlinux.org/title/Firejail
- kaba0 4y ago
  Convenience matter. Without it being automatically on everywhere, it doesn’t protect from much. Sure it can be good for the occasional random software you trust the least, but how many exploitable bugs were found in any of your completely trustable tools? Also, afaik firejail runs as suid, making any possible escape much more serious.
  - seodisparate 4y ago
    [1] discusses firejail running as root: > For a server, the process exposed to the outside world runs as an unprivileged user (unbound or nobody). The process is started by a separate process running as root (as explained by @Ferroin above). The starting process is never exposed to outside. > The same is true for Firejail. By the time the unprivileged server process starts, Firejail is already sleeping. And I think Docker has a similar problem as mentioned in the "warning" section in [2]: > Warning: Anyone added to the docker group is root equivalent because they can use the docker run --privileged command to start containers with root privileges. For more information see [3] and [4]. [1]: https://github.com/netblue30/firejail/issues/1720 https://github.com/netblue30/firejail/issues/1720 [2]: https://wiki.archlinux.org/title/Docker#Installation https://wiki.archlinux.org/title/Docker#Installation
    - goodpoint 4y ago
      Actually docker is much worse due to the large attack surface.
kkfx 4y ago
Hum, as another admin... No thanks. With IllumOS I can agree on zones, I can partially agree on lpar on AiX, I can accept GNU/Linux limits with cgroups. Enlarging the attack surface to follow the current wannabe Gurgle mania... No. Like no in the recent past to full-stack virtualization on x86 to enrich VMWare, buy big desktops sold as powerful servers just to play matryoshka doll for someone else business... Of course, it's hard to satisfy hw "subdivision" vs sw subdivision, in the past we have tried the hw path with blades for the small side, infiniband and co for the large side and both proved to be not very scalable but the issue is in actual OS design and can only be solved changed that: An OS mush be a single application, with internal namespacing, networking. We have seen it in various past OSes. It's about time to make them again accepting that the IBM model is good only for IBM, witch means for selling stuff to people having no choice but buy or ignoring something better can be done.
- anonymousDan 4y ago
  Can you elaborate on the scalability problems with infiniband?
  - kkfx 4y ago
    It's not a problem with infiniband but a problem of sw mutating needs vs actual hw assets: matching is hard. Hw cost money so anyone try to be moderately tight, looking at life expectancy and supposed sw changes in that timeframe, but hw and sw have different lifecycle. At a certain point in time sw infra change while hw is still the same, at another point in time available/current iron change but software on it remain the same. In classic times that's just a matter of balancing both, carefully designing both, but in modern time developers just "produce code", operation is pushed aside, communications are constrained often by the policies and the result it's a mess => companies choose "the cloud" witch means outsource the issue to third parties. Those third parties count on the fact that even if anything change in the end a computer is always a computer so they can live on a changing world because if single companies have irregularly changing needs on average the rate of change is similar. Also on scale redundancy needs lower the costs and that's why we switch from classic big iron to desktop crap packed in racks. Now we start seeing more and more the limit of such model, and no solution is here. Big iron is long lost, now way to expensive not much in absolute terms but in demand terms: try to sell a Power system, the customer look at specs and say "hu?! a couple of PCs from nearby grocery store are equally powerful!". Such iron modularity coming from classic mainframes (infiniband in the end is crylink changed a bit by SGI and others) is considered too expensive, on the other side of the spectrum small-board ARM super-blades tentative still results in fails. Until we accept that hw and sw can't really be two separate world and both must be open to being able to interoperate on scale we will not find any really scalable solution. Sw side it's not different: these days is the containers mania days because after many have suffered burn with full-stack virtualization on x86 they look for something with less overhead and equal design: hw-sw decoupled, possibility of run an infra you do not know buy pre-made images/containers from third parties who maintain them without needing to know your infra. The result again is an enormous amount of layers and giant attack surface no one really know how extended it is. Since coms are needed we punch holes here and there, and on the other side "safety features" arrive to compensate, making more complicatedness layers on complicatedness instead of admitting the basic issue: in sw terms our OSes are badly designed for current needs, they are a relic form a long lost past where they aren't even good but just cheaper alternatives to something better. If we ever admit those errors probably we will be able to design modular iron and modern OSes marginalizing those issue, but so far no one want such a nightmarish adventure...
zozbot234 4y ago
AppArmor is great. It can do much of what SELinux does, but it uses plain configuration files as opposed to incredibly obscure and clunky filesystem-level hacks.
- porker 4y ago
  It still has the same gotchas as a user though. I was daemonizing a uvicorn (Python) process using systemd and could not get the Python script to write its log file anywhere. Not the current directory owned by the user, not elsewhere, and no errors showing up in the system logs. After a few hours banging my head against the wall I discovered systemd's ReadWritePaths. Once I set that, it would log to any directory I specified. It's the only service I've created where this has been necessary, and others write logs, so I have no idea why this one caused errors. If I did something wrong, let me know how this should be handled.
  - db48x 4y ago
    Most systemd services log to stdout and let systemd put it in the journal, or they log to syslog and let systemd put it in the journal. Most don’t write their own log files any more. I really recommend going that route because it is nice to be able to search the journal, especially if you provide extra metadata for each log message. It sounds like you were using the DynamicUser=, ProtectSystem=, or ProtectHome= settings which can greatly limit where a service is allowed to read from and write to and thus require you to open specific directories back up. Instead of using ReadWritePaths=, you might prefer to set LogsDirectory=.
    - egberts1 4y ago
      Yet another rabbit hole has emerge. And it is called “systemd”. What a great time to be a Linux system administrator.
      - NoGravitas 4y ago
        Compared to selinux, though, the systemd documentation is excellent, and the tools for observing the state of the system are very good.
raesene9 4y ago
I'd generally agree with this, but for production use (where it'll be CRI-O or ContainerD in all likelihood) it's worth noting that using containers does increase your attack surface. We've had container breakout CVEs in the Kernel+ContainerD+CRI-O this year, and the ContainerD/CRI-O ones were not complex at all, so you do need to stay on top of patching as well as the other good practices mentioned.
- bonzini 4y ago
  A lot the container breakout CVEs do not affect a system that uses SELinux properly.
  - raesene9 4y ago
    have you seen an analysis of SELinux against the recent set of breakouts? That'd be interesting to see. Definitely the CRI-O one (which is most likely to affect Red Hat based systems) was able to exploit a default OpenShift cluster in my testing.
fsflover 4y ago
> Put everything in a container, and learn how to run Docker or Podman (or k8s) in a secure way Or just use Qubes OS: https://qubes-os.org https://qubes-os.org.
nigma1337 4y ago
As a completely new admin, could you elaborate on "be very careful with volume mounts"? In the k8s env I run, the filesystem is backed by ceph, which creates persistent volumes that the different pods can claim. Is it just "be careful not to mount docker.sock"?
goodpoint 4y ago
> but containers aim to provide many of the same benefits that SELinux does Absolutely not. They are not designed as security tools in the first place. Especially docker, with its huge attack surface. You are confusing containers with sandboxes. Furthermore they don't implement anything resembling RBAC.
mmis1000 4y ago
Docker actually comes with an apparmor config that disallows you to interact with any files outside of the container. It's not a so strong guarantee compares to inode based approach (selinix), but is still much better than don't have one. And if you enables uid mapping, your permission in the host system is just as high as nobody if there isn't a kernel exploit happened somewhere. But the fact it is nobody is also problematic, because dir mount will be almost alwyas read-only now.
- cpuguy83 4y ago
  It comes with both an apparmor profile and an SELinux profile. What gets used depends on what's on the system... and I guess you need to actually set the flag on dockerd to enable SELinux.
rbanffy 4y ago
> much easier to manage I would say it's not necessarily easier to manage, but it's much easier to understand, because containers create natural borders between the different software running on the machine.
someguydave 4y ago
By using containers you can multiply your security problems! That is, it does nothing to address security problems latent to each container binary.

devman0 4y ago

I was about to argue with you until I read to your last point. Totally agree one of the great things about containers is indeed they integrate very well with various Mandatory Access Control implementations SELinux included and don't generally require specialized policies for each app.

ximm 4y ago

I agree that containers are easier to manage than SELinux, but still not easy enough. Linux provides many low level primitives for restricting applications and SELinux, Apparmor, Docker, Flatpak, and systemd all provide high level abstractions for those. But IMHO none of them really finds a sweet spot between flexibility and usability. `systemd-analyze security` for example lists 80 (!) different settings, even though some of them are very high level such as `ProtectSystem`. Containers have made the conceptual shift from allow/deny to isolate/share. Somehow this feels better even though it is effecitvely the same. I am still waiting for an abstraction that uses all the low level features and wraps them in a high-level interface that puts usability front and center. I am not sure if this is even possible though because many applications are not built with sandboxing in mind. Adding another file somewhere on the system that needs to be accessed is not considered a breaking change by most. So maybe we need a more fundamental shift.

zozbot234 4y ago
> I am still waiting for an abstraction that uses all the low level features and wraps them in a high-level interface that puts usability front and center. Bubblewrap? FlatPak's sandboxing features are built on it already.
tinco 4y ago
In my opinion, if an application requires more access than a docker container gives by default, then that application should probably just run in a VM. If the application needs more access because it needs to manage or control some hardware, then it should be tailored to the O/S and have a small core service that runs naked under systemd or whatever. If fancy management of that core service is needed, it can expose a port that an application can talk to, that's safely isolated in a docker container. Maybe that's just daydreaming about a perfect world, but I agree that it should be easy to reason about the access levels.
- ximm 4y ago
  What about an application like vim? It should be able to access any file I pass that is explicitly opened, but not much more. That is hard to express with current tooling.
  - tinco 4y ago
    You shouldn't run an application like vim in Docker. Unless your server is running Vim as some sort of service, in which case it should only open files in a volume you bound to it. Vim is exactly the kind of application you would run in a virtual machine.
  - legalcorrection 4y ago
    You could do it with a file picker API that opened an out-of-process file picker. I'm pretty sure this is how WinRT works. Would be tricky for a purely command line workflow, but very doable with a GUI.
    - 4y ago

tpetry 4y ago

And when everything is in docker you can use SELinux again: A docker container is not allowed to access the host system or access the filesystem of other containers. That‘s the default. SELinux protection without any weird problems.

bitcharmer 4y ago

Container approach is not always feasible, for example when you need to stay on bare metal. There are Linux applications where selinux definitely gets in your way and there are legitimate reasons to turn it off completely. edit: I like how I'm getting down-voted for sharing factual information. No-one in high frequency trading employs containers because it doesn't help soft-realtime, low-latency goals. There are other performance-sensitive domains where containers aren't an option. Sometimes I feel like this place is turning into Reddit.

TheDong 4y ago
> when you need to stay on bare metal What cases can linux containers not handle? Containers can access GPUs, /dev/kvm, block devices... I'm having trouble thinking of anything they can't do. After all, they're just processes in a glorified chroot, not that different from processes on the linux host.
- Gigachad 4y ago
  Not sure about need but I do remember it being a pain in the ass to run anything that expects to be managing docker inside docker. Things like self hosted gitlab ci where its trying to start up containers itself.
  - KronisLV 4y ago
    > ...anything that expects to be managing docker inside docker. Now that's an interesting problem to have! If you trust those tools and don't have untrusted users or untrusted code, you can sometimes just mount /var/run/docker.sock and use the VM/VPS/server's Docker directly. It is actually the approach that was used by excellent tools like Portainer, though it's also really risky as well. Alternatively, you can try to just run Docker in Docker (DinD), which is a bit more tricky and the opinions there are split about whether to do it and when to do it: https://github.com/jpetazzo/dind https://github.com/jpetazzo/dind Of course, someone might also jump in and suggest that Docker is architecturally problematic (i don't care much, just want my containers to run, then again; i don't deal with untrusted code or any sort of multitenancy) and you should use Podman or another set of technologies, which is interesting advice but would necessitate other approaches. In short, like with most technologies: Docker and OCI container in general get more messy as your requirements become more advanced. For the problems that they do solve easily (app packaging), they are pretty good, though!

patrck 4y ago

A couple sysadm red flags: 1) The article author is Testing in PROD 2) selinux debugging relies on auditd, so sanity checks required. df -P /var/log/audit # has space? tail -1 /var/log/audit/audit.log # is recent? semodule -DB # disable dontaudit setenforce 0 # run the failing test audit2allow -l After which the selinux debugging experience boils down to: mk_semod() { module_name=$1; shift audit2allow -l -m ${module_name} -a > ${module_name}.te $EDITOR ${module_name}.te || return checkmodule -M -m -o ${module_name}.mod ${module_name}.te semodule_package -o ${module_name}.pp -m ${module_name}.mod semodule -i ${module_name}.pp }

kelnos 4y ago
I think you just proved the author's point. That looks entirely inscrutable.

seodisparate 4y ago

As a lightweight alternative to Docker-based (or any container-based) solutions: Try firejail. You can set up a directory that will be the "home" of the sandboxed application you're running, then you can do something like `firejail --private="${HOME}/my_firefox_jail" firefox`. There are built-in profiles for many applications already, and you can customize them (by adding `.local` files, not editing the existing `.profile` files). See the following link for details. https://wiki.archlinux.org/title/Firejail https://wiki.archlinux.org/title/Firejail

kaba0 4y ago
Convenience matter. Without it being automatically on everywhere, it doesn’t protect from much. Sure it can be good for the occasional random software you trust the least, but how many exploitable bugs were found in any of your completely trustable tools? Also, afaik firejail runs as suid, making any possible escape much more serious.
- seodisparate 4y ago
  [1] discusses firejail running as root: > For a server, the process exposed to the outside world runs as an unprivileged user (unbound or nobody). The process is started by a separate process running as root (as explained by @Ferroin above). The starting process is never exposed to outside. > The same is true for Firejail. By the time the unprivileged server process starts, Firejail is already sleeping. And I think Docker has a similar problem as mentioned in the "warning" section in [2]: > Warning: Anyone added to the docker group is root equivalent because they can use the docker run --privileged command to start containers with root privileges. For more information see [3] and [4]. [1]: https://github.com/netblue30/firejail/issues/1720 https://github.com/netblue30/firejail/issues/1720 [2]: https://wiki.archlinux.org/title/Docker#Installation https://wiki.archlinux.org/title/Docker#Installation
  - goodpoint 4y ago
    Actually docker is much worse due to the large attack surface.

kkfx 4y ago

Hum, as another admin... No thanks. With IllumOS I can agree on zones, I can partially agree on lpar on AiX, I can accept GNU/Linux limits with cgroups. Enlarging the attack surface to follow the current wannabe Gurgle mania... No. Like no in the recent past to full-stack virtualization on x86 to enrich VMWare, buy big desktops sold as powerful servers just to play matryoshka doll for someone else business... Of course, it's hard to satisfy hw "subdivision" vs sw subdivision, in the past we have tried the hw path with blades for the small side, infiniband and co for the large side and both proved to be not very scalable but the issue is in actual OS design and can only be solved changed that: An OS mush be a single application, with internal namespacing, networking. We have seen it in various past OSes. It's about time to make them again accepting that the IBM model is good only for IBM, witch means for selling stuff to people having no choice but buy or ignoring something better can be done.

anonymousDan 4y ago
Can you elaborate on the scalability problems with infiniband?
- kkfx 4y ago
  It's not a problem with infiniband but a problem of sw mutating needs vs actual hw assets: matching is hard. Hw cost money so anyone try to be moderately tight, looking at life expectancy and supposed sw changes in that timeframe, but hw and sw have different lifecycle. At a certain point in time sw infra change while hw is still the same, at another point in time available/current iron change but software on it remain the same. In classic times that's just a matter of balancing both, carefully designing both, but in modern time developers just "produce code", operation is pushed aside, communications are constrained often by the policies and the result it's a mess => companies choose "the cloud" witch means outsource the issue to third parties. Those third parties count on the fact that even if anything change in the end a computer is always a computer so they can live on a changing world because if single companies have irregularly changing needs on average the rate of change is similar. Also on scale redundancy needs lower the costs and that's why we switch from classic big iron to desktop crap packed in racks. Now we start seeing more and more the limit of such model, and no solution is here. Big iron is long lost, now way to expensive not much in absolute terms but in demand terms: try to sell a Power system, the customer look at specs and say "hu?! a couple of PCs from nearby grocery store are equally powerful!". Such iron modularity coming from classic mainframes (infiniband in the end is crylink changed a bit by SGI and others) is considered too expensive, on the other side of the spectrum small-board ARM super-blades tentative still results in fails. Until we accept that hw and sw can't really be two separate world and both must be open to being able to interoperate on scale we will not find any really scalable solution. Sw side it's not different: these days is the containers mania days because after many have suffered burn with full-stack virtualization on x86 they look for something with less overhead and equal design: hw-sw decoupled, possibility of run an infra you do not know buy pre-made images/containers from third parties who maintain them without needing to know your infra. The result again is an enormous amount of layers and giant attack surface no one really know how extended it is. Since coms are needed we punch holes here and there, and on the other side "safety features" arrive to compensate, making more complicatedness layers on complicatedness instead of admitting the basic issue: in sw terms our OSes are badly designed for current needs, they are a relic form a long lost past where they aren't even good but just cheaper alternatives to something better. If we ever admit those errors probably we will be able to design modular iron and modern OSes marginalizing those issue, but so far no one want such a nightmarish adventure...

zozbot234 4y ago

AppArmor is great. It can do much of what SELinux does, but it uses plain configuration files as opposed to incredibly obscure and clunky filesystem-level hacks.

porker 4y ago
It still has the same gotchas as a user though. I was daemonizing a uvicorn (Python) process using systemd and could not get the Python script to write its log file anywhere. Not the current directory owned by the user, not elsewhere, and no errors showing up in the system logs. After a few hours banging my head against the wall I discovered systemd's ReadWritePaths. Once I set that, it would log to any directory I specified. It's the only service I've created where this has been necessary, and others write logs, so I have no idea why this one caused errors. If I did something wrong, let me know how this should be handled.
- db48x 4y ago
  Most systemd services log to stdout and let systemd put it in the journal, or they log to syslog and let systemd put it in the journal. Most don’t write their own log files any more. I really recommend going that route because it is nice to be able to search the journal, especially if you provide extra metadata for each log message. It sounds like you were using the DynamicUser=, ProtectSystem=, or ProtectHome= settings which can greatly limit where a service is allowed to read from and write to and thus require you to open specific directories back up. Instead of using ReadWritePaths=, you might prefer to set LogsDirectory=.
  - egberts1 4y ago
    Yet another rabbit hole has emerge. And it is called “systemd”. What a great time to be a Linux system administrator.
    - NoGravitas 4y ago
      Compared to selinux, though, the systemd documentation is excellent, and the tools for observing the state of the system are very good.

raesene9 4y ago

I'd generally agree with this, but for production use (where it'll be CRI-O or ContainerD in all likelihood) it's worth noting that using containers does increase your attack surface. We've had container breakout CVEs in the Kernel+ContainerD+CRI-O this year, and the ContainerD/CRI-O ones were not complex at all, so you do need to stay on top of patching as well as the other good practices mentioned.

bonzini 4y ago
A lot the container breakout CVEs do not affect a system that uses SELinux properly.
- raesene9 4y ago
  have you seen an analysis of SELinux against the recent set of breakouts? That'd be interesting to see. Definitely the CRI-O one (which is most likely to affect Red Hat based systems) was able to exploit a default OpenShift cluster in my testing.

fsflover 4y ago

> Put everything in a container, and learn how to run Docker or Podman (or k8s) in a secure way Or just use Qubes OS: https://qubes-os.org https://qubes-os.org.

nigma1337 4y ago

As a completely new admin, could you elaborate on "be very careful with volume mounts"? In the k8s env I run, the filesystem is backed by ceph, which creates persistent volumes that the different pods can claim. Is it just "be careful not to mount docker.sock"?

goodpoint 4y ago

> but containers aim to provide many of the same benefits that SELinux does Absolutely not. They are not designed as security tools in the first place. Especially docker, with its huge attack surface. You are confusing containers with sandboxes. Furthermore they don't implement anything resembling RBAC.

mmis1000 4y ago

Docker actually comes with an apparmor config that disallows you to interact with any files outside of the container. It's not a so strong guarantee compares to inode based approach (selinix), but is still much better than don't have one. And if you enables uid mapping, your permission in the host system is just as high as nobody if there isn't a kernel exploit happened somewhere. But the fact it is nobody is also problematic, because dir mount will be almost alwyas read-only now.

cpuguy83 4y ago
It comes with both an apparmor profile and an SELinux profile. What gets used depends on what's on the system... and I guess you need to actually set the flag on dockerd to enable SELinux.

rbanffy 4y ago

> much easier to manage I would say it's not necessarily easier to manage, but it's much easier to understand, because containers create natural borders between the different software running on the machine.

someguydave 4y ago

By using containers you can multiply your security problems! That is, it does nothing to address security problems latent to each container binary.