Le 04/05/2020 à 17:35, Matej Tyc a écrit :
> Is there any other way how to satisfy everybody than to have a profile
> for unprivileged containers, and specialized profiles for privileged
I find this discussion very intersting and I think because of the new
raising ecosystem due to the massive use of containers, the way we are
hardening system may be rethought (Or at least discussed)
Recently, I read that article https://lwn.net/Articles/796700/ quoting
Stéphane Graber from Ubuntu/LXC project and I think he told something
very very intersting :
"LXC and LXD are used to create "system containers", which run
unmodified Linux distributions, not "application containers" like those
created using Docker. The idea is that LXD users will use the same
primitives as they would if they were running the distribution in a
virtual machine (VM); that they are actually running them on a container
is not meant to
be visible to them."
After reading that, for me the first question to ask about hardening is
not if the container is privileged or unprivileged but how it is built
and how it is executed.
The article says (and I agree with it) that there are two categories of
- The application containers (Micro-service architecture) where the
container is very minimalistic : Just the application,the dependencies,
and nothing more (For example alpine based containers)
- The system containers : If I sum up quickly, I would say it's a
complete distribution with userland only (No kernel, no bootloader)
For me, if we must think about SCAP profiles for containers, it's easier
with system containers because create such a profile could be "just"
tailoring a current profile removing everything not applicable (I mean
rules about kernel and bootloader). I would say it's a "userland SCAP
For application containers, the approach is very diffent and with some
of my colleagues we started to ask ourselves that question : Is it
relevant to have an hardening profile on application containers which
are very minimalistic ?
As I told before, a well built application container is very
minimalistic with normaly only the application running. So generally,
this is no authentication layer, no network configuration, no sysctl to
configure (generally done at the host level). My point of view, is that
when you try to reduce/tailor a SCAP profile for such a container, there
is only very few rules to apply. Example: Why hardening a PAM stack
which is never used or even not installed ?
Of course, it's just a first analysis with additional questions to
answer : What about if you add privilege/unprivileged status and what
about container who are between these two worlds ? (But for me the
answer can be simple : The container is not well built).
So maybe a first approach would be to focus on these "system containers"
and maybe try to define some guidelines for the "application containers" ?
My two cents !
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
scap-security-guide mailing list -- email@example.com
To unsubscribe send an email to firstname.lastname@example.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://email@example.com