►
From YouTube: SES-mtg: Chained Attenuation
Description
Recorded from the "Frozen Realms shim collaboration" meeting on Jan 22, 2019. See https://github.com/katelynsills/legacy-todo/blob/master/manifest.json
Unfortunately, we accidentally started recording well after this discussion started.
We discussed how the policy decisions expressing what authority should be provided to packages are expressed, who makes those policy decisions, and what the workflow is to make a new policy decision --- or raise an alarm --- when a new version demands more authority.
Resolution:
From outside an application, express and enforce policy on what authority is provided to an application as a whole. We call this the "aggregate authority", as it is aggregated over all packages that comprise the application.
The https://github.com/katelynsills/legacy-todo/blob/master/manifest.json is an example of an application's internal expression and enforcement of policy about how the authority provided to the application as a whole is to be further subdivided and attenuated among the individual packages that comprise the application.
Example: The outside policy may express that the "fs" module that the application as a whole sees is attenuated to providing access to example/*, whereas the application layers on this a further attenuated to provide a particular package with access only to example/log.txt
A
If
I
may
make
one
small
point,
I'm
looking
at
this
and
I'm
worried
about,
am
I
of
a
naming
issue.
As
I
mentioned
a
moment
ago,
bind
is
part
of
ACMA
script
and
now
we're
talking
about
introducing
a
bond
function.
No
double-oh-seven,
jokes,
please!
The
naming
is
so
similar
that
it
and
and
for
that
matter
the
purpose
of
the
functions
is
relatively
similar.
It
may
confuse
people
a
little
bit,
especially
I
mean
the
I
and
the
O
keys
on
my
keyboard
are
right.
Next
to
each
other.
You
know
typos
we're
just
waiting
to
happen.
Yeah.
B
So
so
I'd
like
to
get
other
reactions.
My
reaction
is
the
fact
that
it's
similar
and
different
is
actually
good
because
they're
sort
of
about
the
same
topic
so
having
the
names
you
remind
you
of
the
topic
so
that
you
know
that
it's
kind
of
about
the
same
thing
but
somehow
different
is
is
I.
Think
good
yeah.
C
C
So
let
me
try
to
take
this
from
a
different
perspective.
I
had
a
bound
function
that
basically
proxy
tried
an
object
so
that
any
method
I
call
from
that
object.
Returns
abound
instance
of
that
function.
To
that
particular
object,
it's
a
cheesy
way
to
not
write
a
lot
of
bind
statements.
Basically,
so
is
that
the
behavior
is
that
acting
on
the
object,
or
is
it
binding
a
particular
function?
At
that
point,
it's.
A
A
Further
for
the
reason
that
the
attack
that
we're
trying
to
avoid
is
when
you
create
an
object
or
an
array
in
Jessie
and
you
assign
a
function
to
one
of
the
properties,
are
one
of
the
indices
of
the
array
or
object.
You
can
count
for
this
from
Jessie.
So
if
you
Bond
the
fun,
if
you
bind
the
value
before
you
assign
it
to
the
index,
you're
guaranteed
not
to
capture
this,
and
then
it
will
just
behave.
Is
normal.
C
A
B
So
so,
I
like
this
in
the
alt
OS
and
similar
modules,
we
can
just
say,
for
example,
release
:.
Well,
actually
what
you
wrote
in
the
chat,
release,
:
bond
original
OS,
comma
quote,
release
unquote,
and
so
do
that
for
all
the
properties
that
we
see
the
original
access
that
should
typically
not
break
anything
and.
B
If
the
value
of
release
is
a
non
function,
then
it
doesn't
get
wrapped
at
all.
It
gets
used
directly
and
I.
Think
the
goal
for
for
these,
for
having
these
manifests
generated
from
tofu
should
only
be
that
that
the
that
tofu
generates
a
sufficient
approximation,
that
many
programs
work
and
also
a
nice
secondary
goal
would
be
when
there
is
some
reason
why
the
generated
manifest
did
not
preserve
functionality.
That
things
broke
in
a
noisy
manner
like
with
a
thrown
exception
which
you
get.
If
you
were
accessing
and
undefined,
when
you
expect
it
and
not
undefined.
B
B
C
A
B
B
Won't
process.
Okay,
so
it
takes
right
right
right.
It's
is
creating
record
saying,
use
this
the
result
of
attenuate
process
as
the
global
variable
named
process
for
things
that
should
get
a
global
variable
name
process
from
this
all
process
module,
which
is
then
what
the
manifest
says
to
get,
and
so
this
whole
manifest
processing
is
also
consistent
with
all
of
the
modules
being
evaluated
only
once.
E
So
I
do
have
some
concerns
here:
yeah
a
variety,
a
part
of
which
was
using
a
package
manager,
and
these
may
not
be
fatal,
but
they're
still
concerns
one
is
I.
Do
not
want
this
to
be
within
the
application
directory
ever
due
to
a
variety
of
attacks
in
the
common
case
scenario
of
leaving
your
application
directory
its
writable
file
systems.
So.
B
E
B
E
E
B
E
E
It
could
apply
to
this
manifest,
but
it's
already
a
manifest
file.
So
why
would
we
have
to
this
gets
into
my
next
point?
I,
don't
want
this
in
packaged
adjacent
for
another
reason
this
applies
great.
If
you
treat
packaged
Jason
is
only
for
the
top
level
of
your
application,
but
you
could
have
conflicting
forms
of
these
manifests
within
your
node
modules
directory.
That's.
A
E
A
E
E
D
B
E
B
E
B
I
didn't
understand
that,
but
before
I
ask
you
to
to
explain
again,
let
me
let
me
focus
in
on
a
question
or
observation.
I
think
we
might
be
solving
two
different
problems
that
are
related
and
need
to
be
chained
together,
but
they're
still
distinct
problems.
It
sounds
like
the
problems
that
you're
trying
to
address
is
giving
the
application
least
authority
by
some
policy
expressed
somehow
outside
the
application.
That
is
about
the
application,
and
that's
certainly
an
extremely
important
thing
to
do.
B
But
that's
not
what
I'm
trying
to
do
here,
the
and
and
it
would
not
have
been
adequate,
for
example,
in
the
event
stream
incident,
the
event
stream
incident,
the
application
as
a
whole
needed
the
authority
to
do
the
Bitcoin
wallet
thing.
What
I'm
trying
to
do
is
to
have
the
application
author
Express
and
maintain
a
policy
for
how
the
authority
granted
to
the
application
is
then
subdivided
among
the
modules
that
make
up
the
application.
B
E
A
C
D
That
exact
right
so
so
broadly
I
think
it's
not
that
this
example
is
meant
to
say
that
the
the
application
should
have
all
authority.
We
could
definitely
limit
that.
It's
just
that
this
example
only
focuses
on
given
the
authority
that
the
application
does
have.
How
do
we
attenuate
that
to
the
modules
that
it
wants
to
import
yeah.
E
B
E
My
skepticism
comes
down
to
roughly
the
auditability
of
this
in
the
event
stream
incident,
which
I
guess
is
our
canonical
incident.
We
would
have
seen
that
we
have
flat
map
stream
being
pulled
in
apply
event
stream,
I,
don't
think
that
would
have
been
a
red
flag
and
then
we
would
have
seen
that
flat
map
stream
actually
is
requesting
access
to
the
file
system.
It
doesn't
actually
request
access
to.
B
So
granting
you
know
the
the
if
the
tofu
tool
had
been
run
on
the
Bitcoin
wallet
before
a
flat
map
before
it
was
corrupted
by
the
adversary,
and
then
the
adversary
had
created
an
upgrade
of
the
event
stream,
as
they
did.
That
depends
on
flat
flat
map
or
whatever
it
is
flat
stream.
That,
in
turn
depends
on
the
file
system.
The
the
purpose
I
took
it
of
the
whole
tofu
policy
generation
thing
is
exactly
that
that
new
RIA
thority
request
would
get
flagged
in
if
it.
If
the
the
application
author
just
runs,
I.
B
E
D
B
There's
a
there's,
a
maintenance
problem
here.
That
really
scares
me
if
I
change
my
application,
so
that
the
application
as
a
whole
is
not
using
any
more
authority
than
it
used
to,
but
I
just
changed
my
internal
logic,
so
that
I've
just
refactor
my
application
internally
into
different
modules
that
are
wired
up
differently.
Then
in
the
system
Bradlee
that
I
think
you're,
describing
my
refactoring
of
my
application,
where
the
application
as
a
whole
is
not
using
anything
that
it
that
it
did
not
previously
use.
B
That
would
be
flagged
to
the
user
and
a
user
that
has
no
idea
what
the
meaning
is
of
internal
modules,
with
whom,
in
my
application,
he
just
wants
to
use
my
application.
As
a
Bitcoin
wallet.
He's
now
going
to
be
asked
to
make
a
policy
decision
about
which
modules
inside
my
application
should
be
getting,
which
Authority.
E
B
I
so
I
don't
have
said
the
user
experience
issue
and
the
maintenance
issue
to
me
are
inseparable.
It's
a
question
of
where
the
policy
decision
is
made,
I
think
having
the
user
make
a
policy
decision
with
regard
to
the
authorities
granted
to
the
application
as
a
whole
is
appropriate
and,
in
fact,
while
corresponds
to
the
user
experience
on
things
like
iOS
and
Android.
E
B
E
Expect
that
the
overall
authority
grant
is
the
same,
whatever
cascading
means
that
you
aggregate
it,
and
so
the
user
only
sees
the
top
level.
So
it
doesn't
matter
what
modules
are
using
FS.
It
just
knows
that
this
application
is
using
FS,
but
the
stored
values
do
correspond
with
the
exact
modules
that
are
granted
that
permission
so
who.
B
E
E
Anybody
who
is
wishing
to
run
in
a
more
restrictive
mode
than
the
average
user,
so
people
who
do
security
audits,
are
going
to
be
wanting
to
know
the
exact
changes
that
happened
within
your
application,
which
is
not
the
average
case
for
the
average
user
could
I
eat
person
who
does
a
security
audit
should
be
able
to
run
in
some
mode
that
sees
the
exact
changes
of
oh.
That
file
has
been
deleted.
That
file
does
not
use
this
Authority
anymore.
This
file
does
use
more
Authority.
Now,
okay,.
E
D
Think
I
think
we're
in
agreement.
There
I
think
there's
kind
of
there's
a
pipeline
that
trickles
down
like
Saleh
was
saying
of
authority
and
there
there's
the
site
that
the
user
gives
the
application.
Then
there's
the
set
that
the
application
gives
to
specific
modules
that
imports
and
it's
a
slate
Bradley
you're
focused
on
the
user
perspective
which
we
haven't
focused
on
yet,
but
that
really
needs
to
be
focused
on.
But.
C
Sorry
could
I
just
add
one
one
aspect
that
that
we
might
want
to
consider
if
it's
these
statements,
if
we,
if
we
keep
a
bit
like
a
record
of
the
occurrence
of
you,
know
authority
calls
like
calls
to
FS.
Not
only
do
we
keep
the
module
online,
we
actually
store
the
three
or
five
lines
surrounding
the
call
and
if,
if
even
if
it
moves
to
a
different
module,
the
flag
comes.
If
those
lines
change,
you
know
without
comments
and
white
spaces
change
drastically,
but.
B
E
A
E
B
So
we
so
we
are
in
agreement
on
that
being
what
the
user
should
say
now,
I,
don't
understand
what
scenario
you
have
in
mind
about
the
policy
file
that
is
under
the
users
control
not
under
the
applications.
Authors
control,
where
that
policy
file
is
expressing
Authority
regarding
individual
modules
within
the
application.
E
So
roughly
this
is
a
guard
against
exactly
the
rewrite
of
reed-solomon
encoder
jeaious.
So
it's
an
example
file
in
the
node
policy.
Cli,
roughly,
what
happens?
Is
you
get
into
a
situation
where
a
file
gets
marked
as
having
some
level
of
authority
and
if
it
gets
rewritten,
we
don't
want
it
to
get
more
authority,
and
so
we're
pinning
that
when
the
user
approves
hey,
I
want
to
give
lo
que
ssin
access
to
my
app
we're,
not
approving
pay.
All
future
versions
have
location
access
granted
to
all
possible
permutations.
E
E
B
So
so
so
so
when
you
say
so,
I'm
trying
to
understand
how
this
loop,
through
the
audit
works
from
the
users
perspective,
the
user
has
some
policy
file
that
came
from
the
auditor.
The
user
now
upgrades
a
particular
application.
The
application
is
internally
refactored,
but
it's
aggregate
Authority
is
the
same.
The
user
without
upgrading
its
policy
file,
now
gets
a
failure
and
hat,
and
the
user
now
has
to
go
back
to
the
auditors,
for
the
auditors
to
inspect
the
refactored
application.
Is
that
what
you
have
in
mind.
E
B
B
The
security
auditors
might
be
looking
at
the
new
code
as
well
as
the
new
Authority
grants.
The
fact
that
the
Authority
grants
are
in
a
manifest
that's
declarative
as
part
of
the
application,
helps
the
security
auditors,
but
the
what
that
distribution
of
internal
Authority
is
should
be
considered
part
of
the
process
of
authoring.
The
application.
D
So
there
could
be
a
decoupling
there
where,
if
the
user
doesn't
give
access
to
FS,
the
application
thinks
it's
getting
access
to
FS,
but
it
doesn't
actually
and
so
the
what
the
user
expresses
doesn't
have
to
be
expressed
exactly
in
the
application
manifest
there
could
be
a
disconnect
and
that's
okay.
So.
B
Kate
I'm
not
sure
when
you
the
when
you
say
the
application
manifest
we
now
have
because
of
these
two
different
scenarios,
two
different
things:
you
could
mean:
there's
something:
there's
something
authored
by
the
application
author
and
that's
the
manifest
that
you
and
I
have
been
working
with
and
then
there's
a
manifest
or
policy
file,
or
something
that
is
not
in
control
of
the
application
author,
that
is
in
control
of
these
security
auditors.
That
is
about
the
application
in
imposing
restrictions
on
the
application.
B
D
D
B
Good
that
all
makes
sense
to
me
and
thank
you
very
much
fits
with
what
I
have
in
mind
the
applet,
the
the
the
outer
virtualization
of
FS,
is
would
be
expressed
in
in
terms
of
I.
Think
you
know
corresponds
to
the
locus
of
responsibility
that
Bradley
is
talking
about
its
imposed
on
the
application
and
then
the
further
virtualization
of
that
fast
among
the
modules
of
the
application
would
be
virtualizing
the
fa
additional
virtualization
additional
attenuation.
That's
on
top
of
the
attenuation
of
the
FS.
That's
granted
to
the
application
as
a
whole.
D
B
Okay,
so,
okay,
so
good!
That's
that's
that's
the
mission
that
that
I
was
hoping.
We
were
on
that.
The
that
the
policy
imposed
on
the
application
from
the
outside
is
with
regard
to
the
Authority,
giving
it
to
the
application
as
a
whole,
including
virtualizing,
FS,
and
then
it's
part
of
the
authored
application
to
express
further
subdivisions
and
virtualizations
of
those
among
its
own
modules.
E
E
E
B
E
B
E
B
No
I
did
not
understand
that.
Let's
talk
about
this
particular
example,
the
idea
is
that
we
have
an
application
that
was
already
you
know,
together
with
a
set
of
modules
that
was
already
written,
that
uses
the
name
OS,
thinking
that
it's
accessing
the
powerful
OS
primitive,
but
the
tofu
tool
recognizes
that
OS
is
only
used
in
a
very
constrained
manner.
B
It's
only
used
as
the
on
the
left
side
of
the
dot,
and
then
it
generates
something
like
this
manifest
together
with
the
let's
say
these:
let's
take
the
entire
scenario
where
it
does
the
property
name
attenuation.
It
generates
this
to
where
the
the
author
of
the
Apple
patien
now
sees
this
as
something
generated
that
enables
the
author
to
impose
that
wins.
That
supports
color
still
uses
the
name
OS,
but
when
it
uses
that
name
what
it
sees
bound
to
OS
is
the
module
created
by
alt
OS
can.
E
B
We're
looking
at
I
would
say
the
author
of
the
application
sees
this
as
the
expression
of
the
internal
further
reduction
of
authority
within
the
application
and
then,
with
regard
to
the
policies
of
how
the
application
as
a
whole
has
its
authorities
reduced.
It
might
be
similar
to
this,
but
it
wouldn't
be
this
itself.
I.
D
E
B
So
so,
in
the
other,
the
sibling
repository
to
legacy
to
do
we,
we
went
and
did
the
invasive
rewriting
of
supports,
color
and
chalk
into
the
you
know,
wyvern
or
e
pure
style,
and
and
that's
what
we
would
prefer.
People
do
long-term,
but
it
involves
a
invasive
rewrite
of
basically
everything,
that's
not
pure,
and
for
that
one,
the
the
main
does
the
you
know,
calls
the
attenuators
itself
and
passes
things
through
as
parameters.