►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2021 Virtual from May 4–7, 2021. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Seccomp: What Can It Do For You? - Justin Cormack, Docker
Seccomp is a system call filtering tool built into Linux. It has been used as a security layer in Docker for coming up to five years, and is working through a long path to become on by default in Kubernetes. We look at what seccomp can usefully do to improve real world security, and how best to use it. This talk also covers a reworking of the widely used Docker default seccomp policy, based on experience of security vulnerabilities in the last five years. Seccomp can both be used as a policy in a runtime, and also directly by applications, so both aspects are covered. The policy has also caused a number of usability issues over the years, so we look at the pitfalls involved in using it as syscalls change over time.
https://sched.co/ekEJ
A
A
A
So
what
what
is
setcomp
anyway-
and
why
does
it
matter?
Setcomp
is
a
thing
that
stands
for
secure
computing,
which
sounds
like
a
really
great
thing.
It's
a
bit
of
a
ambitious
name,
perhaps
back
in
2005
when
it
was
first
created.
It
was
basically
an
extreme
sandboxing
method
when
extreme
sandboxing
wasn't
actually
that
common
a
thing.
It
was
really
just
for
code
that
just
does
computer
operations
and
it
could
only
read
or
write
from
existing
files
and
basically
exit.
A
So
in
2013,
a
more
general
version
was
introduced,
which
is
called
second
bpf,
but
it's
usually
just
called
setcom,
because
it's
the
most
commonly
used
version
and
there's
a
small
bpf
program.
So
bpf
is
a
technique
originally
used
for
in
the
network.
Stack
you've
probably
heard
about
recently
about
his
grown-up
ebpf,
extended
version,
but
bpf
is
the
kind
of
original,
simple
version
lets.
A
You
write
very
simple
programs
to
decide
if
system
calls
should
be
allowed
or
not
or
if
they're
not
allowed,
whether
they
should
error
or
be
logged
or
kill
the
processors
running
them
so
effectively,
because
system
calls
are
the
interface
between
applications
and
the
kernel.
This
basically
is
a
method
of
controlling
what
programs
can
actually
do
outside
just
computing
stuff,
so
what
kind
of
interaction
they
have
with
the
outside
world,
which
sounds
really
useful.
A
A
You
can
pretend
the
system
call
doesn't
exist
at
all
which
is
enosis
or
any
other
kind
of
operation.
So
that's
the
theory
in
practice.
It's
not
quite
like
that
for
so
for
our
examples
there,
when
you
open
a
file
with
setcomp,
you
don't
actually
get.
Your
program
doesn't
actually
get
to
see
what
the
file
name
was.
A
Unfortunately,
because
it
just
sees
the
direct
arguments
of
the
system
call
and
the
argument
for
a
open
system
call,
isn't
directly
a
string,
it's
actually
just
a
pointer
to
a
string,
and
all
you
guess
is
the
pointer
and
you
can't
follow
the
pointer
to
see
what
it
pointed
at,
which
is
the
name,
so
you
have
to
make
decisions
actually
based
on
quite
limited
information
compared
to
what
you
might
want
and
and
so
and
yours
this
is
kind
of
limiting
you
also.
You
can't
know
what
kind
of
file
descriptor
has
been
used.
A
If
someone's
doing
a
read,
it
could
be
read
from
a
network
or
read
from
a
local
file,
and
you
might
want
to
allow
one
and
not
the
other.
You
can't
do
that.
There's
also
weird
peculiarities
and
you
also
didn't
really
get
any
context.
You're
just
called
every
time
the
system
call
and
you
can't
actually
keep
state
in
between
those.
So
you
can't
say
you
can
do
this
after
you
do
that,
but
not
before
or
anything
like
that
very
easily.
A
One
of
the
first
things
I
worked
on
when
I
started
talking
with
jesse
frazelle
was
adding
sitcom
support
for
docker,
and
it
was
enabled
by
default,
which
was
a
nice
thing
to
have
done,
and
most
people
don't
disable
it.
So
most
people
get
it
got.
You
know
had
the
benefit
of
using
it.
Since
then,
kubernetes
spent
a
long
time
working
out
on
its
implementation
and
really
only
in
119,
so
not
very
long
ago
now.
A
Finalized
the
api
or-
and
it
does
not
enable
it
by
default-
and
it's
still
somewhat
complicated
to
manage
in
kubernetes-
is
because
sitcom
profiles
tend
to
be
at
the
moment
very
long
files
like
the
docker
default.
One
is
800
lines,
long
and
apparently
800
more
lines
of
yaml
was
seen
as
too
much
so
you
have
to
work
out
how
to
distribute
files
with
this
configuration
on.
A
If
you
want
to
customize
the
this
or
you
can
just
use
the
runtime
default
setting,
which
will
give
you
something
that's
pretty
much
like
the
like
the
docker
setup.
Basically,
as
given
you
by
the
runtime
it'll,
be
the
docker
one,
if
you're
using
docker,
if
you're
using
container
d,
it'll
be
or
cryo
it'll
be
similar,
but
due
to
kind
of
maintenance
things
not
exactly
the
same
in
the
sort
of
oci
sort
of
structure
of
hierarchy.
A
We
have
in
the
container
thing
where
we
have
kubernetes
and
then
cri,
and
then
we
have
run
times
it's
kind
of
complicated
set
up
because
and
we'll
talk
about
this
a
little
bit
more
later,
but
there's
a
bunch
of
abstraction
layers.
This
goes
through
effectively
everything's
just
passed
down
all
the
way
to
run
c,
which
then
it
calls
the
go
binding
to
libset
comp,
which
is
a
simplified
version
of
what
the
actual
sitcom
ppf
looks
like.
A
And
this
and
these
simplified
calls
are
generated
from
a
json
config
that
is
slightly,
you
know,
is
basically
abstract
again
the
kind
of
rules
that
you
can
use
with
with
lipset
comp.
So
there's
this
weird
and
then
the
runtime
actually
might
have
a
different
form
of
the
json
which
has
it
has
different
runtime
customizations.
It's
a
kind
of
messy
kind
of
process,
of
converting
jason
to
jason.
To
go
to
c
to
ppf
to
running
the
kernel,
so
it's
it's
a
bit
kind
of
messy.
A
A
There's
some
system
calls
in
linux,
which
are
not
really
considered
safe
for
isolated
programs
to
use.
Some
of
these
have
a
very,
very
large
attack,
surface
and
they've
been
a
lot
of
cves
around
them.
Perfect
open
is
one
of
those
username
spaces
when
bpf
we'll
talk
about
a
bit
later.
These
are
just
very
large
subsystems
that
in
general,
most
containers
don't
actually
need
to
use.
A
Often
these
are
used
by
runtimes
and
and
other
sort
of
software,
rather
than
actually
end
user
applications
and
they've
been
a
lot
of
cves
that
basically
meant
that
you
can
escape
from
a
container.
If
you
can
access
these
cisco,
so
blocking
them
is
actually
proven
to
be
useful.
We'll
talk
about
specific
examples
of
where
there's
been
a
benefit
later.
A
Some
syscalls
can
disable
security
features
such
as
the
pr
cuddle
adder,
no
randomize,
which
basically
disables
aslr
address-based
layout
randomization,
which
is
a
security
feature.
That's
been
added
for
good
reasons,
so
we
applications
can
simply
turn
it
off,
which
is
really
unhelpful
and
some
things
are
obsolete.
A
So
what
have
we
succeeded
in
doing
with
the
sepca
sitcom
subsystem
username
spaces?
There's
this
quote
from
angela
mursky
is
one
of
the
kind
of
maintainers.
You
know
basically
saying
that
the
huge
attack
surface
from
user
namespaces
is
huge
risk
and
if
unprivileged
users
can
program
ip
tables
they're
bound
to
be
some
privilege
escalations.
He
said
this
was
before
this
was
you
know.
A
Normally.
This
needs
cap
net
admin
which
is
not
granted
so
normally
it's
safe.
But
if
you're
using
the
namespaces
you
get
capnet
admin
in
your
username
space,
you
can
call
these
commands
in
your
username
space.
You
can't
change
root,
ip
tables
functions,
but
you
can
compromise
the
kernel,
so
it
doesn't
really
matter
whether
it's
actually
which
namespace
it's
in.
This
was
mitigated
by
docker's
default
policy
and
so
users
using
that
were
not
affected
more
recently
again.
The
bpf
verifier,
which
again
is,
is
a
is
a
new
feature
for
extended
bpf.
A
I
had
some
bounds
checks
on
32-bit
operations
that
were
not
enforced,
and
you
could
read
and
write
kernel
memory,
which
basically
means
you
can
control
the
entire
host
again.
An
unprivileged
user
with
access
to
ppf
cisco
could
do
this
again.
The
docker
policy
blocks
use
the
bpf
by
default
unless
you
actually
grant
caps's
admin,
which
is
basically
a
privilege
to
access
anyway.
A
A
I
stopped
people
running
emacs
in
containers
with
setcomp
enabled
for
many
years.
This
was
a
really
strange
story.
It
really
surprised
me
when
this
the
complaints
came
in
about
this
quite
early
on
emacs.
Had
this
very,
very
strange
thing
that
a
lot
of
people
didn't
like.
For
other
reasons,
the
muscle
lipsy
maintainer
was
against
it
because
it
didn't
work
with
muzzle
lipsc
as
well,
but
basically
it
in
order
to
make
startup
of
emacs
faster
it
used
to
during
a
build
time.
A
It
would
start
running
the
binary,
then
dump
the
output
and
then,
instead
of
re-running
the
code
that
generated
this
the
initial
setup,
it
would
just
load
the
memory
snapshot
basically,
but
the
way
it
required
to
do
this
was
very
normal,
but
it
required
memory
locations
to
be
loaded
exactly
the
same
way
as
they
were
before
and
if
you
had
aslr.
This
was
not
the
case,
because
memory
locations
would
be
randomized
and
so
wouldn't
work,
so
it
disabled
it
by
disabling
randomization.
A
But
this
was
one
of
the
things
was
explicitly
blocked,
because
this
basically
is
allowing
applications
to
bypass
a
security
mitigation.
Eventually,
emacs
realized
that
well,
computers
were
fast
enough.
You
could
just
run
the
startup
code,
normally
like
a
normal
application
and
not
stop
being
so
good.
A
Quite
so
weird,
and
so
this
problem
has
gone
away
and
now
you
can
happily
run
emacs
in
containers,
but
really
I
just
felt
it
was
not
worth
changing
the
default
policy
to
basically
reduce
security
for
everyone
just
so
that
emacs
could
be
run
more
effectively
with
its
weird
things
in
a
container
worse
than
that,
though,
worse
than
breaking
emacs,
I
also
broke
steam.
This
was
not
on
purpose
and
not
something
I
wanted
to
do.
Linux
has
made
a
bunch
of
changes
to
32-bit.
A
A
It
was
a
weird
multiplex
syscall
that
does
that
could
do
socket
or
bind
or
connect
or
any
of
the
other
socket
calls
and
switch
to
separate
syscalls,
and
we
hadn't
actually
allowed
for
this
change,
and
I
think
debian
did
it
early
and
they
did
the
same
thing
with
64-bit
time
support
on
those
two-bit
systems.
They
again
they
switched
early
before
it
was
officially
upstream,
and
these
were
all
temporarily
blocked
by
said
comp
until
we
fixed
this
problem.
A
A
Only
really,
I
o
intensive
applications
will
notice
this,
and
so
actually
very
few
people
complain,
but
a
few
people
have
and
they've
generally
disabled
sitcom,
rather
than
actually
fixing
it
and
then
there's
some
interesting
areas,
security
issues
where
setcomp
didn't
actually
help
at
all
and
we
didn't
do
anything
to
help
users,
one
of
which
is
probably
my
favorite
kernel,
cve
that
jan
horn
found.
This
is
a
really
interesting
security
issue
in
linux.
It's
a
cash
invalidation
bug.
A
Basically,
there's
a
there
was
a
a
32-bit
counter,
and
if
you
did
the
right
thing
at
the
point
at
which
the
counter
wrapped
around
back
to
zero
again,
you
could
basically
exploit
the
kernel
and
escape
your
container
and
all
you
had
to
do
to
do.
This
was
some
memory
mapping
and
some
cloning
of
processes,
which
is
all
totally
normal,
normal
stuff
that
we
couldn't
possibly
block
with
setcomp.
A
So
there
was
just
no
way
we
could
protect
against
this
kind
of
thing.
It
eventually
was
changed,
but
fixed
by
changing
a
counter
to
b64
bits.
32
bits
is
too
small
for
any
kind
of
security
on
anything
you
can
always
overflow
a
32-bit
counter,
but
over
flying
a
64-bit
counter
is
pretty
impossible
because
it's
so
huge.
Actually
it
was
actually
interesting
that
they
were.
A
A
And
generally,
I
think
the
answer
is
that
we
do
want
efficient
isolation
without
going
into
using
virtual
machines
for
everything
it's
actually
relatively.
The
number
of
container
escapes
has
bee
exploits
has
been
not
too
bad
over
the
years
for
most
people.
This
level
of
security
is
actually
kind
of
fine,
and
also
most
of
our
applications
don't
use
a
whole.
You
know
the
whole
linux
is
called
space.
Most
applications
use
a
kind
of
narrow,
a
subset
that
doesn't
include.
A
You
know
the
sort
of
specialized
things
you
get
in
linux.
Doesn't
most
people's
code
doesn't
run?
Most
application
code
doesn't
run
bpf,
it
doesn't
run
username
spaces.
Those
things
are
being
used
for
security,
critical
applications
and
often
for
control,
plane,
applications
but
end
user
applications.
Basically,
just
use
networking
and
storage,
and
I
mean
some
people
would
say
they
should
just
use
the
posix,
subset
and
and
linux
the
lens
cisco
space
is
just
way
too
expensive.
A
I
mean,
I
think,
there's
arguments
about
what
the
boundaries
of
what
normal
applications
should
care
about
are
but
and
it
this
does
change
over
time,
with
kind
of
performance
reasons
for
using
different
system
calls
and
so
on.
But
you
know
it's,
there
is
actually
a
kind
of
set
of
things
that
most
applications
don't
use
and
it's
sensible
for
us
to
isolate
them
off
for
security,
because
the
common
syscalls
are
basically
mostly
most
of
the
time
other
than
that
cve.
I
just
pointed
you
out
generally
are
actually
safe.
A
Setcomp
was
designed
that
every
application
would
write
its
own
profile,
but
this
is
really
and
right,
really
really
difficult
for
users
to
do.
It
was
not
designed
for
kind
of
platform
administrators
and
like
if
you
read
the
documentation,
we're
kind
of
doing
it
wrong
in
the
container
space,
but
it's
actually
too
difficult
for
end
user
applications
to
use,
and
you
only
find
very,
very
specialist
applications.
A
A
A
A
If
you're
not
going
to
use
it,
I
recommend
you
update
your
kernel
weekly,
that's
a
that's
a
burden.
Maybe
using
setcomp
means
you
can
do
it
less
often
than
that.
Maybe
you
get
a
higher
rate
of
zero
days,
but
the
rate's
relatively
low.
Maybe
you
can
live
with
it.
I
I
suspect
that
a
lot
of
people
are
going
to
just
continue
to
ignore
it
and
just
live
with
those
vulnerabilities.
A
I
don't
think
we
could
actually
rationalize
the
policy
we.
We
went
for
an
allow
this
not
a
block
list
at
the
beginning.
Because
of
the
whole
issue,
I
mean
it's
the
recommended
thing
with
setcomp:
it's
the
recommended
thing
with
most
security
things
just
you
know,
you
know
what
you
what's
safe,
you
list
what's
safe
and
then
everything
else
is
blocked,
and
so,
if
there's
a
new
dangerous
syscall
added
and
many
arguably
the
new
cisco's
office
often
do
have
security
issues
more
than
the
old
ones.
Then
you're
safe.
A
A
It's
less
likely
to
break
something
when
new,
safe
syscalls
are
added
like
the
the
time
64
ones
for
those
stupid
systems
which
were
you
know
these
things,
it
turns
out
that
there's
new,
safe
cisco's
added
a
lot
of
the
time,
because,
probably
because
of
stupid
things
like
there
weren't
enough
flags
allocated
on
cisco's
and
there's
now
new
cisco's,
with
more
flags
being
added
for
everything.
Things
like
that.
These
block
policies
would
be
easier
to
understand
because
you
can
see
what
they
do
rather
than
try
and
re
work
out
the
negative
of
what
they
do.
A
They
wouldn't
be
800
lines
long.
They
would
be
maybe
10
lines
long,
so
we
could
actually
inline
them
in
the
yaml.
We'd
have
to
obviously
change
the
kubernetes
setcom
format
again
to
do
this,
but
you
know
I
think
this
would
be
kind
of
nice
if
you
could
say,
allow
bpf
to
remove
the
default
block
list
approach
to
bpf,
and
that
would
be
the
one
line
you
need.
Allow
bpf
allow
open,
perf
event
that
kind
of
thing,
so
I
think
that
would
be
easier
to
understand.
A
There
would
be
less
maintenance
work.
You
wouldn't
get
people
complaining
things,
don't
work
and
needing
to
suddenly
fix
them.
A
lot
of
these
problems
have
been
like
cross
architecture.
Problems
with
architectures
have
different
syscalls
and
new
changes
and
people
running
you
know
a
distro
that
expects
one
kernel
on
another
and
it
behaves
differently.
A
We
have
a
huge
problem
in
the
kubernetes
ecosystem,
but
whose
problem
is
this?
Should
users
really
have
to
understand
about
setcomp?
No,
should
applications
have
to
understand
it
too
difficult?
Is
it,
but
should
it
be
done
at
the
kubernetes
level,
where
you
have
to
configure
it
now
or
should
it
be
the
responsibility
of
the
cri
or
run
or
the
sort
of
run
c
type
layer
of
the
actual
container
runtime?
A
Currently
we're
pushing
responsibility
up
to
the
user,
which
is
kind
of
terrible?
We?
Why
don't?
We
have
runtimes
that
provide
actual
security
guarantees,
instead
of
just
letting
you
configure
it
and
making
it
your
choice.
We
are
starting
to
see
some
of
these
runtimes.
I
mean
arguably
g
visor,
which
I'll
talk
about
in
a
second
and
vm
runtimes
are
basically
trying
to
make
better
security
guarantees.
A
You
know,
but
why
have
we
pushed
down
this
whole
idea
that
you
list
a
bunch
of
syscalls
in
json,
which
is
what's
this
called
handling,
rules
and
json,
which
is
what
we're
doing
it's
a
it's,
not
a
good
design
and
there's
a
definitely
a
layering
and
responsibility
issue
that
we
need
to
solve
g
visor
g
visas,
a
really
interesting
response
to
this.
It,
basically
it
basically
reimplements
large
portions
of
works
in
go.
A
Basically,
it
kind
of
you
know
has
a
go:
tcp
stack
and
everything
it
basically
says:
well,
linux
wasn't
very
secure,
we're
going
to
re-implement
it
in
go
in
user
space
in
a
memory,
safe
language,
and
then
we're
going
to
wrap
this
up.
We're
going
to
use
setcomp
internally
in
it
just
to
make,
because
it
doesn't
actually
use
many
syscalls.
A
A
I
don't
know,
is
lambda
kind
of
solved
a
lot
of
these
problems
by
having
a
very
restricted.
I
said,
container
runtime,
it's
strict,
I
mean
people,
don't
think
of
it
as
a
container,
but
it's
a
very
similar
problem.
Space
user
said
comp.
I
haven't
actually
probed
this
policy
to
see
what
exactly
what
it
doesn't
doesn't
allow.
It
has
a
custom
learner's
kernel
with
features
removed,
which
is
what
a
lot
of
people
who
run
secure
systems
do
is
just
disable
a
lot
of
parts
of
the
linux
kernel.
A
This
has
thousands
and
thousands
of
subsystems
that
are
not
generally
very
secure,
and
you
can
often
access
them
by
from
user
space
by
opening
weird
kinds
of
sockets
that
you
don't
really
use
in
practice.
Much
and
things
like
that,
but
the
linux
distro
is
a
very
general
purpose
and
they
tend
to
ship
with
a
kernel
that
does
everything.
Has
everything
as
a
module
loads?
Anything
because
you
know
the
general
purpose
you
might
want
to
do
anything?
A
A
We
could
do
something
very
much
like
this.
We
could
have
a
you
know,
a
container
runtime
that
made
these
choices
and
had
a
clear
delineation
of
what
you
can
and
can't
do,
and
a
security
model
and
testing
and
things
like
that
in
a
way
the
the
sandboxed
flag
proposal
for
kubernetes
is
kind
of
like
this,
but
it
doesn't
define
any
kind
of
specification.
A
That
makes
these
decisions,
in
effect,
the
things
like
the
firecracker
container
to
effectively
kind
of
make
those
decisions
for
you
ish,
but
but
there
isn't
a
kind
of
normal
container
runtime
that
does
that
as
of
linux,
5.7,
there's
something
that
we've
been
talking
about
for
a
really
really
long
time
that
got
merged
the
ebf
ebpf
lsm
lsm
has
done
a
security
module
module.
These
are
things
like
se,
linux
and
app
armor,
but
selenius
and
f
armor,
give
you
a
kind
of
general
purpose
way
of
configuring.
A
A
And
there
are
a
lot
of
these
points
they're
much
more
than
just
at
the
syscall
there
they're
all
sorts
of
places
like
and
there,
and
you
get
much
more
specific
information
about.
What's
going
on
at
these
places
as
well
than
you
do
at
this,
this
is
called
abi.
You
can
basically
run
an
ebpf
program
that
can
make
real
programmatic
decisions
about.
Can
this
application
do
this
at
this
point
and
it
can
maintain
more
state
and
can
make
you
know
basically
have
much
more
information
to
make
these
decisions?
A
This
is
not
simple,
I
think,
as
I
said,
it's
a
start-up
size
problem
potentially
or
perhaps
an
nsa
sized
problem.
I
think
the
nsa
wrote
sc
linux
in
the
first
place
and
basically
defined
the
kind
of
shape
of
what
it
looks
like,
and
you
know
the
nsa
is
an
organization,
that's
interested
in
this
type
of
problem,
but
yeah.
It's
the
sort
of
thing
that
you
could.
You
could
potentially
do
with
a
you
know
a
medium-sized
team
and
work
on
this
problem
for
a
few
years.
A
This
is
very
much
looking
as
a
technical
solution.
It
doesn't
solve
the
human
problems
of
really
what
kind
of
what
kind
of
policies
do
you
need
to
enforce
and
what
kind
of
model
you've
actually
got
here
and
how
does
the
human
communicate
intense
over
this
problem?
Things
like
that.
So,
there's
still
a
lot
of
human
problems
that
you
have
to
solve
there.
A
So
what
is
going
to
happen
with
said
comp?
My
prediction
is
that
the,
if
you
look
at
the
state
of
the
container
ecosystem,
now,
there's
a
continuing
lack
of
investment
in
the
low
levels
of
the
stack
there's,
really
not
many
people
working
on
these
problems.
It's
not
clear
who's
who's
going
to
work
on
these
problems.
Most
people
seem
to
expect
someone
else
to
do
it
and
not
get
involved
themselves.
A
I
think
setting
up
an
ebp,
flsm
container
security
starts
up
is
probably
quite
easy
to
get
funded,
but
the
other
options
might
not
even
happen.
The
serious
service
providers,
like
the
cloud
providers,
are
basically
just
using
vms,
and
so
that's
why
you're
seeing
quite
mature
things
like
firecracker?
A
The
problem
is
that
most
no
most
other
users
of
containers
are
running
their
containers
in
vms,
already
they're,
either
running
vmware
on
prem
or
they're
running
in
cloud
provider,
vms
and
not
cloud
provider
bare
metal
or
other
bare
metal.
So
most
of
them
don't
have
the
option
of
using
vms
for
containers.
At
this
point,
so,
even
though
their
stack
is
becoming
relatively
mature,
most
people
are
simply
not
using
it.
So
we'll
probably
see
the
split
where
more
and
more
people
are
using.
A
You
know,
provider
services
like
you,
know,
cloud
provider
services
and
they
will
just
use
vms
vm
based
containers
via
providers
or
or
things
like
that.
Like
you
know,
things
like
you
know
this,
the
fargate
containers
of
kubernetes
and
aws
things
like
that
which
are
all
vm
based
and
just
scale
as
as
containers,
rather
than
as
hosts
we're,
not
assuming
security
vendors.
Solving
this
type
of
problem,
there's
a
there's
lots
of
reasons
for
this
thomas
dallian's
done
a
bunch
of
talks
which
are
interesting.
A
Talk
to
me
if
you're
interested
in
the
questions
about
why
the
security
industry
isn't
interested
in
this
kind
of
problem
and
end
user,
as
if
kubernetes
find
it
difficult
to
contribute
back
to
this
sort
of
problem,
because
these
problems
are
quite
technically
difficult.
There's
not
a
lot
of
people
who
have
the
right
kind
of
expertise
around
the
learner's
kernel
and
how
things
actually
work
in
container
runtimes
and
have
time
to
work
on
these
problems.
A
They
have
other
pressing
problems
to
work
on
it's
kind
of
difficult,
I
mean
even
very
large
end.
Users
have
tend
to
have
very
little
and
it's
kernel
expertise
and
they
tend
to
work
much
mostly
higher
up
in
the
stack.
So
we're
not
really
seeing
much
at
the
moment
much
end
user
contribution
to
solving
these
problems.
So
I'm
actually
not
optimistic
that
a
lot
of
this
stuff
will
happen
quickly.
It's
taken
a
long
time.