►
From YouTube: Lightning Talk: lockc - Containing the Containers That Do Not Contain - Michal Rostecki
Description
Lightning Talk: lockc - Containing the Containers That Do Not Contain - Michal Rostecki, Deepfence Inc
lockc is open source software for providing MAC (Mandatory Access Control) type of security audit for container workloads, written in Rust in C (soon to be written fully in Rust). The main reason why lockc exists is that containers do not contain. Containers are not as secure and isolated as VMs. By default, they expose a lot of information about host OS and provide ways to "break out" from the container. lockc aims to provide more isolation to containers and make them more secure through policies enforces in the kernel. The main technology behind lockc is eBPF - to be more precise, its ability to attach to LSM hooks. This talk will also mention Aya and the ability to write eBPF programs in Rust.
A
Yes,
so
hello,
everyone,
I'm
michael
dostetski,
and
I
would
like
to
talk
about
the
project
loxi,
which
is
trying
to
contain
the
containers
which
do
not
contain
before
I
dig
into
the
project
a
bit
about
myself,
I'm
michael
dostetski,
my
nickname
in
open
source
communities
is
wadodovsky,
I'm
a
software
engineer
at
deep
fence,
and
nowadays
I
rewrite
mostly
in
rust,
and
it
became
my
favorite
language.
Although
I
have
a
huge
background
in
go
c
and
python.
A
You've
probably
heard
a
lot
about
ebpf,
either
on
kubecon
or
any
kubernetes
related
conference,
but
to
briefly
describe
it,
it's
a
technology
coming
from
the
linux
kernel,
which
allows
to
run
sandbox
programs
inside
the
linux
kernel
and
those
programs
are
triggered
by
various
events.
It
can
be
the
event
of
calling
a
kernel
function.
A
It
can
be
an
event
related
to
incoming
network
packet
in
the
system
and
ebpf
is
event
driven,
so
ebpf
allows
you
to
write
programs
which
are
triggered
by
specific
kernel
event,
which
gets
the
context
of
that
event
and
does
something
with
it
and
ebpf
is
already.
It
has
many
years
it's
widely
adopted.
A
One
is
s
linux,
the
other
is
up
armor
and
both
of
them
are
built
on
top
lsm
and
lsm
is
an
api
in
the
kernel
which
provides
various
hooks
inside
their
linux
kernel,
which
led
programmers,
which
would
let
developers
of
security
security
systems
to
decide
whether
some
particular
action
is
allowed
to
happen
and
huge
examples
of
lsm
hooks
are
there's
a
hook
for
opening
a
file,
so,
for
example,
as
linux
or
up
armor
are
triggered
by
the
event.
When
you
are
opening
some
file
in
the
operating
system,
it's
getting
the
data.
A
What
the
file
is,
who
is
initiating
that
file,
opening
action
and
based
on
that
security
systems
are
making
a
decision,
whether
it's
it
looks
safe
to
them
or
whether
it's
a
malicious
behavior,
and
they
want
to
deny
it
and
well
for
the
most
of
time,
development
of
linux
security
modules
involved
either.
Writing
your
kernel
module,
which
would
have
to
be
loads
with
ls
mall,
for
example,
or
contributing
to
the
linux
kernel
source
tree
and
s.
A
Linux
and
up
armor
actually
have
kernel
modules
inside
the
upstream
kernel
source
code,
so
they
are
developed
together
with
the
linux
kernel
developers,
patches
of
s,
linux
and
armor
developers
are
eventually
ending
up
in
the
star
wars
review
and
linux
kernel
3,
but
that
was
for
the
majority
of
time.
Although,
since
kernel
5.7,
there
is
a
new
type
of
bpf
programs
which
actually
can
leverage
lsm
hooks.
So
nowadays,
there
is
no
need
anymore
for
writing,
kernel
modules
or
control
on
or
modifying
the
kernel
source
code.
A
It's
using
aya
and
aya
is
a
rust
library
which
lets
you
write,
bpf
programs
purely
in
rust,
both
eppf
part
and
user
space
part.
There
is
no
coding
and
see
needed,
and
there
is
no
need
to
use
sleep
bpf.
Everything
is
done
in
pure
rust
and
everything
you
need
to
build.
Bpf
programs
with
aya
is
just
having
cargo
and
rust
nightly
on
your
machine.
A
So
these
are
restricted
baseline
policies,
which
are
meant
for
regular
applications
running
in
kubernetes
cluster
and
the
privileged
one
where
everything
is
allowed
and
that
privileged
policy
is
meant
mostly
for
let's
say,
the
part
of
infrastructure,
cni
plugins
service
meshes
or
anything
which
needs
to
do
something
more
than
regular.
Containers
should
be
allowed
to
do
inside
kubernetes
cluster
and
to
briefly
step
by
step.
Describe
carloxy
works
is
that
there
is
one
bpf
program
and
there
is
fa
notify
mechanism
which
is
tracking
neurancy
processes.
A
It's
trying
to
figure
out
whether
what's
the
context
of
that
container,
whether
it's
running
in
docker
or
whether
it's
running
in
kubernetes,
if
it's
running
in
kubernetes,
it's
trying
to
figure
out
the
policy
which
should
be
applied
there
and
after
figuring
that
out,
it's
saving.
The
information
about
the
initial
process
runs
the
process,
content
container
and
policy
level
into
bpf
maps,
and
afterwards
there
are
other
lsmbpf
programs
which,
based
on
that,
when
there
is
a
lsm
hook
triggered
in
the
system.
A
A
Okay.
So
here
I
have
a
kubernetes
cluster,
which
is
running
loxi,
so
we
can
get
lots
of
it
and
for
now
it's
just
an
empty
k3s
cluster.
Let's
try
to
look
for
lox.
He
locks
in
the
separate
terminal
here.
For
that
you
can.
We
can
use
journal
ctl
a
fu,
lock
c
and
here
are
the
locks,
and
I
prepared
two
types
of
demons
of
deployments.
A
So
there
is
one
deployment
with
engine
x
which
should
fail,
and
that's
because
it's
using
the
default
container
image
of
engine
x,
which
is
running
as
root
and
by
default
loxi,
is
enforcing
a
good
practice
of
logging
as
a
regular
user
inside
containers
not
running
regular
applications
as
a
route.
So
when
we
try
to
deploy
it.