►
From YouTube: ROS 2 Security Working Group (2020-07-28)
Description
Meeting notes: https://wiki.ros.org/ROS2/WorkingGroups/Security
A
So
everybody,
thanks
for
joining
the
july
28th
security
working
group
for
roz
too
looks
like
we
have
kind
of
a
light
agenda
which
is
kind
of
great
ruffin.
This
is
all
you
about
enclave
permission,
size
limitations
with
secure
dds,
okay,.
B
So
in
the
ticket
I
list
it's
just
been
sort
of
a
draft
pr
of
me
going
through
our
old
turtle
bot
three
demo
that
we
had
for
the
s
ros
ii
security
workshop
at
the
last
roscon.
B
So
I
was
just
revisiting
that
and
sort
of
updating
it
to
foxy
release.
So
me
and
me,
kyle,
just
been
kind
of
bouncing
through
some
of
the
changes
to
the
the
entire
demo
and
towards
the
end.
We
get
to
the
point
where
we'd
like
to
sort
of
update
the
entire
policy
based
on
the
the
using
the
generation
tool
to
survey
the
ross2
graph
of
the
navigation
stack
to
get
sort
of
a
comprehensive,
minimal
spanning
policy.
B
We
just
got
to
clean
that
up
using
the
the
macros
we
have
available
and
the
sort
of
the
policy
imports
and
use
sort
of
a
single
enclave
just
to
just
to
get
it
working
and
one
of
the
difficulties
we
had
is
we
weren't
quite
sure
why
nothing
was
connecting
or
starting
you
know
things.
I
don't
think
the
demo
worked
on
connects
because
maybe
there's
just
there's
just
so
many
nodes
maybe
exceeded
one
of
their
conventional
dds
limits
from
the
implementation,
but
we
knew
faster.
B
Our
tps
worked
in
the
previous
release,
so
we
were
kind
of
buffal
or
stumbling
on
that
until
I
I
looked
at
the
the
massive
amount
of
std
out
a
little
bit
closer
and
found
at
least
with
rti
rti
was
reporting
some
errors
on
the
rti
security,
helper,
verify
cert,
and
so
that's
one
of
the
functions
that
verifies
the
remote,
the
the
other
other
participants
certificates
valid
and
it
was
unable
to
get
that
certificate,
and
so
that's,
like
kind
of
a
scene
like
it's,
maybe
a
strapping
or
something
like
that.
B
Then,
if
we
also
look
at
the
the
built-in
security
topic,
the
the
on-channel
write
event
was
suffering
from
you
know
this
buffer
is
too
small
and
from
the
rti
documentation.
That
kind
of
that
that
the
that
leads
to
maybe
the
issue
that
for
your
qos,
you
set
the
buffer
too
small
or
too
conservative.
B
So
you
can
enlarge
that,
but
it
turns
out
that
doesn't
affect
the
limitation
for
the
built-in
topics,
and
so,
if
we
look
at
the
sign
permissions
file,
that
is
eventually
a
property
that
goes
into
the
dds
handshake
packet.
We
find
that
it's
bigger
than
the
maximum
size
of
a
udv
packet.
So
there's
no.
B
A
C
Sure
the
the
problem
is
not
at
least
at
least
in
the
in
the
first
dds
case.
We
do
support
a
fragmentation
on
built-in
topics.
The
problem
is
not
that
we
are
exceeding.
The
utp
limit
is
that
we
are
exceeding
the
limit
for
the
rtps
parameters,
which
are
defined
to
have
at
most
64
kilobytes.
C
So
in
this
case
the
dash
is
that
the
the
rtps
specification
itself
does
not
support
for
this
data
to
be
larger
than
those
64
kilobytes.
C
We
did
indeed
find
a
problem
with
our
implementation
that
we
are
not
checking
that
size
and
that's
why
you
didn't
find
any
any
error
being
been
issued,
but
nevertheless
the
the
example
is
not
going
to
work
in
in.
In
any
case,
we
are
going
to
cover
that
we
are
going
to
start
checking
the
the
length
for
the
for
the
parameters,
but
at
this
moment
we
have
no
way
of
feeding
such
a
large
file
permission
file
on
the
on
the
parameters.
C
What
we
can
do
is
either
keep
with
the
separating
the
the
permissions
for
for
each
of
the
of
the
participants,
or
there
is
a
way
of
trying
to
reduce
the
size
of
this
of
this
file
using
wildcards,
so
that
different
topics
can
if
they
share
the
same
the
same
permissions.
Let's
say
we
could
just
try
to
use
this
wildcards
assign
the
same
permissions
to
this
to
these
topics
and
thus
reduce
the
the
size
of
the
of
the
file.
C
Also
having
a
kind
of
default.
Permissions
is
possible
using
you
know
the
asterisk,
the
complete
wildcard
for
as
they
default
permissions
for
the
whole
system.
But
that's
this
moment,
as
far
as
we
can
go.
B
Okay,
so
so
I
it's,
I
think
it's
it's
it's
justifiable
and
understandable
why
the
the
size
restriction
is
there,
because
you
definitely
want
to
establish
the
handshake
quickly
and
having
to
sort
the
out-of-order
ed.
Packets
of
a
single
handshake
is
probably
just
adds,
exacerbates
the
latency
for
for
the
the
size
restriction.
It's
the
sum
of
the
properties
right
that
can't
add
up
to
64..
B
Okay,
so,
like
the
the
the
the
x
509
certificate,
plus
the
sign
permissions
file,
that
summation
has
to
be
yeah,
okay
and
then
yeah
you're
right
that
one
way
we
can
shortcut,
this
is
to
leverage
more
expressive,
aliases
or
or
so
the
posix
rule
formulation
that
the
dds
security
supports.
B
That's
one
thing
like
I
I
see,
or
I
showed
in
my
second,
the
last
comment
on
the
vr
was
kind
of
comparing
it
to
sort
of
an
administration
example
where
you
just
start
for
all
topics
and
all
services,
and
obviously
that
leads
to
a
much
smaller
permission
file.
B
I
think
this
is
this
is
sort
of
on
the
resolution
is
sort
of
on
the
on
the
sros
2
team,
because
yeah
we'll
have
to
we.
We
do
have
a
method
of
you
know,
affording
smaller
enclaves
and
that
you
can
move
your
your
permission,
profiles
for
esros
nodes
into
separate
enclaves
so
that
they
get
generated
into
separate
artifacts.
B
It's
just
that
we
don't
exactly
have
a
straightforward
means
and
the
ross
launch
to
point
the
processes
to
the
specific
we
have.
We
have
like
right
now,
an
environment
variable
that
says
to
manually
override
the
enclave,
but
there's
there
used
to
be
means
where
we
use
the
ross
node
namespace
to
have
the
node
look
up
its
own
plate.
It
was
relatively
straightforward
to
disperse
the
permissions
into
multiple
artifacts,
so
we're
just
kind
of
getting
that
back
up.
So
this
is
this
issue
is
really
more
like
a
motivation
of.
A
D
B
You
start
if
you
use
a
composable
nodes
and
you
and
it's
one
process,
and
you
just
start
having
so
many
dds
topics
that
might
be
that
might
start
getting
an
issue
yeah.
So
I
think
I
think
one
thing
you
could
probably
do
with
the
composable
node.
Is
you
throw
the
composable
node
in
its
own
namespace,
like
you
push
it
down
into
like
foo
or
something?
And
then
you
just
give
the
enclave
that's
given
to
that
process,
access
to
all
foo
or
something
that
might
be
a
readable
working
round.
E
B
I
I
think,
right
now
we
we
have
the
entire
nav
stack
simulation
slam,
some
teleop,
it's
it's
a
pretty
big,
extensive
enclave.
I
think
what
really
hammers
it
is
that.
B
For
every
node
it
has
its
own
private,
like
services
for
the
parameters
and
then
those
kind
of
multiply
into
so
like
there's
just
there's
this
combinatorial,
that's
kind
of
coming
into
play
that
there's
really
not
that
many
topics
or
permissions
in
the
root
enclave.
B
When
you
add
lots
and
lots
of
nodes,
even
each
node,
even
if
only
one
node
is
only
using
like
one
topic
like
clock,
it
expands
to
like
a
a
floor
of
eight
topics
or
something.
B
We
could
we
could
probably
change
the
alias
for,
maybe
so
so,
maybe
if
some,
if
we
customize
the
imports
for
a
node,
so
maybe,
instead
of
being
explicit
on
the
private
parameters
for
a
node,
we
just
do
the
nodes
name,
space
parameters,
dar
and
so
then
all
those
we
do
reduce
that
by
six,
and
so
we
for
every
node
we
take
off.
You
know
replace
six
six
permissions
with
one
or
something.
E
E
You
would
assume
that
that
node
should
have
access
to
it,
and
so
at
that
point
you
can
even
put
that
wider
because,
as
we
said
like
the
parameters
are
an
issue
but
also
lifecycle,
nodes
lifecycles
also
expose
a
bunch
of
other
interfaces,
and
so
for
a
single
lifecycle
known
that
topics.
It's
that
I
don't
know
publishes
to
a
single
topic.
E
Well,
I
think
there
is
another
thing
about
this.
It
is
like
well
kind
of
like
mixing
the
fact
that,
like
everything,
should
be
dynamic
and
generating
static
permissions,
which
in
general
is
like
it's
not
exactly
the
same
approach,
and
I
think
it's
also
fair
to
say
that
if
someone
composes
a
launch
file
or
process
that
has
all
the
navigation
stack
in
it
or
anything,
it
may
be
fair
to
say
that
the
person
should
put
that
in
a
navigation
namespace
and
everything
under
that
is
allowed
for
that
process,
because
it's
kind
of
dedicated
to
that
process.
B
That
that's
that's
why
I
meant
like.
If
you
have
a
super
big
composable
node,
you
just
throw
the
whole
composition
into
its
own
namespace,
and
then
you
can
allocate
that
one
permission
for
that
read
and
write
action
services
whatever
for
that
namespace.
D
B
C
Theoretically,
it's
possible
to
to
have
different
permissions
archives
and
send
them
each
one
on
a
different
on
a
different
parameter.
C
D
B
What's
what's
what's
the
expected
mechanic
thus
far
like
I
was
thinking
it's
just
a
different
way
of
updating
the
permission,
credentials
for
a
node
that
has
already
had
handshake
with
other
nodes,
rather
participants,
so
like
just
sort
of
a
side
channel,
but
I
think
I
think
it
would
be
sort
of
an
all
or
nothing
like
you
replace
you.
Don't
you
don't
you?
Don't
it's
a
replacement?
It's
not
an
edition.
Yeah
yeah,
don't
concatenate!
All
your
permissions
signed
permission
files.
I
think
it's
just
like
use
this
one.
Instead
now
something
like
that.
B
So
maybe
that's
that's
all
I
have
on
this
topic.
Are
there
any
other
topics
we
want
to
go
back
to
or
now
that
we
have
some
dds
experts
on
the
channel.
A
That
was
today's
only
topic,
which
is
cool
because
we
had
a
lot
of
time
to
discuss
it.
If
there's
no
other
topics
for
people.
D
I
do
I
do
have
and
we
have
some
dds
experts.
If
you
guys
don't
mind,
I
would
like
to
talk
just
more
about
the
access
control
listener
actually,
but
not
not,
for
I
don't
think
it's
a
solution
to
this
problem,
but
I
do
think
it
will
be
really
helpful
for
the
dynamic
behaviors
of
ross.
B
When,
when
you're
saying
like,
when
a
node
goes
to
add
a
new
subscriber
or
something
and
realize
it
has
insufficient
permissions,.
D
It
could
that's
a
little
more
complex
than
I
was
thinking
the
more
s.
The
simpler
case
would
be
like
a
node
container
wanting
to
load
a
new
node,
and
then
that
container
can
say
hey.
I
need
the
idl
for
this
node
and
then
it
can
concatenate
it
with
the
rest
and
then
update
its
own.
You
see
what
I'm
saying.
D
But
my
question
is:
is
that
is?
Is
that
even
possible
given
like
I-
I
only
just
heard
about
this
thing
yesterday,
so
so
my
question
for
for
the
dds
folks
is,
let's
say,
let's
say
I
have
a
a
set
of
nodes
running
into
container
with
a
set
of
permissions.
D
D
If,
if
you
wouldn't
mind
getting
back
to
me
that
I
think
that
could
unlock
some
really
interesting
capabilities
because
that's
been
sort
of
our
the
the
dynamic
nature
of
ross
has
sort
of
hit
the
static
wall
of
dds
in
a
number
of
ways,
and
that
might
that
might
unlock
some
really
cool
things.
C
A
A
new
button,
okay,
we
can
go
back
through
some
other
outstanding
things
unless
other
folks
had
topics.
I
know
there's
a
lot
of
people
on
this
call
and
we've
got
some.
A
A
You
know,
put
a
task
out
there
to
make
sure
that
we
potentially
try
to
improve
or
optimize
the
policy
files
based
on
you
know,
parameters
and
life
cycle
nodes
or
something
along
those
lines.
D
B
Yeah
so
me
and
me:
kyle
can
kind
of
experiment
and
like
how
much
we
can
kind
of
shave
off
the
the
base
load
of
the
permissions
by
playing
around
with
the
wild
cards.
B
And
then
you
know,
maybe
we'll
send
the
pr
upstream
into
sro2
to
change
the
the
ones
that
are
like
in
the
test.
Folder
as
a
reference.
A
B
It's
been
a
while
that
did
we
have
any
conclusion
from
that.
B
E
No,
we
didn't.
We
didn't
really
have
one
basically,
when
we
like
the
folks
that
worked
on
launch
basically
said.
Oh
we'll
table
it
for
later,
because
launch
doesn't
allow
anything
today
and
needs
to
be
refactored,
and
so
maybe
that
will
happen.
B
B
See
control
f,
launch,
there's
ticket
on
ross2
design,
ticket
272
refactoring
execute
process
to
execute
an
executable.
I
think
that's
rogers
yeah
yeah
yeah.
D
F
B
All
right
I'll
have
to
catch
it
up
on
that
ticket
to
get
on
the
discussion
is,
do
you
think
that's
a
point
to
be
a
point
to
bring
it
up
or
maybe
a
separate.
F
You
know,
I
don't
have
the
deepest
experience
with
what's
going
on
on
the
no
dl
side
of
things,
so
that
what
the
work
that
I've
done
there
has
been.
You
know
specifically
from
where
the
initial
issue
was
put
in,
which
was
we've
got
way
too
much
stuff
in
one
class.
Here
we
want
that
to
be
broken
out
and
you've
gone
through
several
issues
with
the
through
several
iterations,
with
a
couple
of
the
guys
who've
been
giving
feedback
haven't,
started
any
implement
any
implementation.
F
A
F
E
Maybe
it
would
be
good,
I
mean,
I
think
we
all
have
to
read
it
closer
before
like
diving
in
too
much
into
it.
But
I
don't
know
if
ted
is
around.
E
It
seems
that,
like
he
has
been
following
the
launch
thing
as
well,
it
would
be
good
if
we
could
get
like
a
small
get
together
to
like
just
catch
up
on
what
you
guys
have
been
doing
on
that
issue
and
the
integration
of
new
dl
in
launch
to
see
how
this
all
fits
together
and
what
needs
or
doesn't
need
to
be
changed
in
order
to
improve
the
security
part.
D
That's
a
good
idea
how
about
so
so
ted
you're
right
it
heads
up
to
speed
on
it
and
the
the
rest
of
us
can
take
a
couple
days
to
read
up
on
it
and
then
maybe
we
can
set
up
sort
of
an
ad
hoc
meeting.
What
do
you
guys
think
it'd
be
good
time
all
for
it?
E
Well,
if
there
are
some
escrows
to
folks
around,
we've
been
trying
to
get
the
esros
2
stuff
to
pass
ci
for
a
long
time,
and
it's
still
like
a
bit
stuck.
So
if
anyone
there
is
a
couple
issues
assigned
to
the
raw
security
working
group
user,
I
looked
into
providing
a
better
way
to
parsing
that
than
the
github
search.
E
But
there
is
nothing
really
convenient
so
far,
but
I
would
love
to
chat
with
anyone
interested
in
maintaining
esros
2
to
like
assign
some
tasks
and
see
how
we
can
get
that
moving
like
a
couple
of
things
we
have
is
so
one
of
them
is
that
we
have
some
tests
that
are
failing,
sometimes,
and
not
always,
and
another
thing
I
would
like
to
look
into
is
by
following
up
on
the
work
sid
did
to
get
security
in
cyclone
bds,
because
that's.
E
Yeah,
but
it's
not
working
for
us,
so
we
need
to.
We
need
to
figure
out
why,
like,
basically,
it
was
working
at
the
when
it
was
early
stage,
development
and
and
how
we
can
actually
integrate
that.
E
That's
a
good
question.
I
don't
have
I
it
just
came
into
my
mind.
I
actually
don't
have
the
number
handy.
E
Sounds
good,
but
there
is.
There
is
basically
a
pull
request
on
on
system
test
that
was
basically
integrating
the
cyclone
dds
security
in
the
system
test
that
we
do
for
all
the
rest
of
the
security
and-
and
that
would
be
an
interesting
place
to
like
re-enable
the
test
and
see
what's
fading.
B
We
could,
we
could
also
add
the
cyclone
to
the
demo
now
installed
by
default.
E
No,
I
had
no,
I
I
don't
think
I
got
it
to
work.
I
mean
I
had
to.
I
had
to
change
a
couple
of
things
in
their
cmake
to
actually
get
it
to
compile
properly
with
all
the
security
options
we
needed.
E
E
I
don't
know
I
don't
remember
exactly
what
it
is
like
at
the
beginning.
It
was
like.
Basically,
a
bunch
of
variables
have
been
introduced
to
say:
hey
has
this
been
built
with
security
or
not,
but
this
bit
of
cmake
was
not
speaking
to
the
part
of
the
cmx.
That
was
enabling
the
bid
with
security,
and
so
I
think
that's
fixed
now,
but
I
still
had
issues,
but
I
think
it
was
only
like
it
was
on
ci.
A
Cool-
and
we
are
just
now
out
of
time-
we
should
have
more.
We
should
have
more
small
agenda
meetings,
because
this
has
a
this
led
to
a
really
great
discussion.
Actually,
maybe
that's
something
we
should
think
about-
maybe
every
every
few
of
them.
We
should
have
almost
a
open
discussion
type
agenda,
but
thank
you,
everybody
for
joining
the
call
and
have
a
great
rest
of
your
day.