This is a talk that is you can tell from
the title is going to have some math and modeling
involved in it because it's talking about meta models.
Um but I will say more in a minute,
exactly what I'm hoping to convey and what I hope
you will get out of this talk. So here
is the obligatory kind of outline. First I wanted
to identify and make clear some ideas that are related
in general to information security and to talk about two
different approaches to that. And this is the one
this information flow control is the one that we're more
interested in in the research that we're doing. I
didn't want to introduce this idea about meta models and
talk about meta models for both of those forms of
confidentiality mechanisms, both for access control and for information
flow control. After we see those two meta models
make some observations and comparisons based on those meta models.
Talk about our future work and acknowledge some other
faculty that have been involved in this project. Now,
what are the expectations? As you'll see in
a minute? Because we're talking about meta models,
there's a lot of mathematical modeling in here using sort
of computational logic formalism. I'm not expecting you to
understand all of this. What I am trying to
accomplish what I'm trying to communicate and what I hope
you will take away from it is well, why
do we want to have such meta models to begin
with? What role do they play? What use
are they? And the short version of this talk
is there was another computer scientist who developed this meta
model framework for access control systems. And what we
are doing is building a parallel one for information flow
control systems. So that's the high level view of
what this work is all about. In presenting these two
models, I want to present them at a high
enough level that you could understand. Well what what's
the approach to building a model like this? What
does such a model look like? Um what are
some of its pieces? And how might I be
able to interpret some of those pieces? And how
in particular in this information flow model? How are
those parts organized? So it's gonna look very much
like something that's familiar to systems people if you think
about protocol stack, we're gonna show how all the
parts of this model are organized in some layered framework
so that you have some orientation in some sense about
what the model looks like. This part about comparison
and observations is giving some greater depth to the notion
of Ok, we built these things. So what
what are we going to do with them? How
do they help guide our thinking in some way.
Right, so that's the high level view of this
talk. I do want you if you have questions
during the talk to ask them because that will help
me why am I giving this talk? Because this
is my dry run for presenting the work that we've
been doing on this meta model at a conference later
this summer. So your questions are helping me to
sort of fine tune where the rough spots in this
talk are. Okay. So with that background and
with that introduction, let's get started. So what
is information security all about? And how does confidentiality
fit in here? So, information security has generally
talked about in terms of these three properties, the
C. I. A property's confidentiality, integrity and
accessibility. And each of these properties provides a different
sort of viewpoint on what security is all about.
So, for example, confidentiality is about ensuring that
only the right people see information okay, We don't
want information that's private to us being seen by people
that we don't know for example. So it's all
about who gets to see what and making sure that
only the right people see that information. So things
like identity theft are obviously attacks on confidentiality because you're
pretending to be someone and gaining access to something when
in fact you're not. And there are lots of
other attacks that you could pose integrity answers a different
question. It's let's make sure that the that the
information that people are seeing is the right information namely
that that information hasn't been corrupted by malicious parties.
So attacks on that are things like DNS attacks where
you think you're going to one website and a malicious
DNS servers actually routing your request to some other DNS
site. Alright. So that what you're seeing there
is not really the right information, it's posing as
the information that you want. But in fact it's
not correct availability means that even if we have the
right people and the right information, let's be sure
that that people can actually see the information when they
want to, that the information is accessible. So
denial of service attacks are a typical violation or a
typical way of attacking accessibility. What we're going to
focus on today is this question about confidentiality. How
do we ensure that only the right people see the
right information and there are two very high level frameworks
by which technical mechanisms have been organized in order to
provide confidentiality guarantees. one of them is access control
. And it answers the question about what information can
you access and how can you access that information.
And so it's usually framed in this way is a
particular principle principle being a person or an agent operating
on behalf of of some person is that principle allowed
to perform some action on some resource? That's the
way the question gets posed. And so the technical
mechanisms, I have to answer that question, given
an idea about a principle what the action is and
what the resources come back with a yes or no
answer. These access control mechanisms are all over the
place in our in the technical systems that we use
. So if you use um file systems on typical
Linux or other things, whether you do it through
the access permission bits and you're setting those for yourself
. World others in your group or you're using access
control lists on those file system mechanisms. Those are
all access control mechanism. If you don't have the
right settings, you can't get access to the information
. But if you have web page access you can
use various things that are interpreted by browsers to control
who can or cannot access a particular web page,
cryptographic based mechanisms. Our access control mechanisms, if
you have the key, you can access the information
. If you don't have the key you cannot.
So access control boils down to controlling that key and
who has access to that key. So if you
use things like https which has this transport layer um
service underneath. It's using a cryptographic method to control
access to the information. And In in all of
these cases there are many, many, many models
that have been developed over 30 or 40 years of
research. That's what all the faculty and graduate students
do. Alright, let's invent a new access control
model and our model will be different because it will
include some feature that nobody else has included before.
So you have models that have roles or context or
time or status or obligations or teams or promises or
hierarchies. You name it, you can probably find
a model out there that incorporates some or all of
those features. And if you want a new model
, just take any two of them that haven't been
combined yet and combine them together. And you have
a new model. So there are lots of those
kinds of models. Information flow control is a complementary
approach that really answers a very different question. It
says information that you're allowed to access. What are
you allowed to do with it? Okay. Because
the typical way to violate an access control mechanism is
you have an authorized user who gets the information and
gives it to somebody who's not authorized. And the
access control mechanism can't prevent that. And that's the
gap that information flow control tries to fill information that
you have. Where can it go? What can
you do with it? Ah So that's really about
looking at the flow of information, hence the name
from some source to some destination. So it is
very different orientation about the problem that it's trying to
solve. And as you can imagine that the mechanisms
that uh that are needed are considerably different. Okay
, well, um I told you that access control
mechanisms are all around and file systems, web pages
and so on. There are important places where systems
are trying to incorporate information flow controls as well.
So here's one a research system called High Star.
I wanted to approach the following problem. You all
have antivirus um software running on your machine. Your
antivirus software needs to be able to access every file
on your machine And it has to have access to
the network because it has to get updates and it
may have to give reports about viruses that it's found
in your machine. So here you have a piece
of software that has access to everything on your machine
and the network. How do you know that it's
not leaking everything on your machine out through the network
? And access control can't solve that problem because you
have to explicitly give it access to everything in your
machine and you have to give it access to the
network. And there have been cases about this like
this where free antivirus software has itself had deliberately um
malicious components embedded in it so that it could scan
systems, find things of interest and leak them out
through the network. A similar thing happens on smartphones
or handheld devices or tablets android devices in general.
So taint droid is a system that wants to help
you solve the problem of I've installed all these various
apps on my smartphone and some of them have access
to my address book. Some of them have access
to the network. Some of them have access to
my geolocation. How do I know the that these
apps aren't reporting this information to parties that I'm not
aware of. So taint droid looks at the flow
of information across apps to try and determine and provide
safeguards against the flow of information um that you deem
sensitive two apps that would leak it outside of your
control. So those are two examples of where information
flow control is really important. Yeah I said before
that that both of these forms of confidentiality control are
important. There's tons of access control models and there's
a wide variety of information flow control models as well
. So this um researcher from London steve barker responded
to a challenge that was raised in the technical community
um And he adopted the stance that that this is
a little quote from this paper that he wrote.
That's called the next 700 access control models or a
unifying meta model. And he takes the position that
What the research community should be doing at this point
is not populating 700 more access control models. Which
could easily be done just because we keep inventing new
factors or attributes that should be included in the model
or combining them in different ways. Because we really
don't know then if we have two models, how
are they different? How do they compare? Are
they is one really more powerful than the other.
So you've included this new feature, does that really
get you anywhere? How do you know? So
his notion was let's develop a meta model. Something
that is based on a few primitive notions that encapsulates
exactly what we mean by access control and such that
any particular model that you developed could then be obtained
by specializing the features of that meta model. So
then you can understand the comparison between specific models by
looking at whats the difference in their specializations. And
he called this paper in the next 700 access control
models because that's a reference to a paper from the
mid sixties that was facing the same issue at that
time. People were developing programming languages every week.
Every time you had a new application or a new
application domain, let's invent a new programming language with
features that are largely the same as other languages but
slightly different because our application domain has slightly different needs
. And at the time there was a computer scientist
Landon who wrote this paper about the next 700 programming
languages. Where he developed this philosophy about what we
should be doing is trying to look at the general
properties of programming languages and understand how these specific languages
fit into some bigger framework. So that's what barkers
set out to do. He set out to look
at all of these access control models and find out
whether a meta model could be developed. Something that
would encapsulate exactly and precisely all of the inherent critical
notions about what access control means. And this paper
was presented a few years ago at the sack matt
conference. And so it's appropriate that we're now trying
to bring the second piece to that um investigation by
looking at a similar question and developing a similar kind
of model for information flow control. So why would
you want this meta model? Well, first of
all, it's uh if nothing else, I mean
we're in an academic environment. What are we here
to do? We're here to learn about how things
work. And we're trying to understand what various aspects
of computing technology is all about. And so if
you could find this meta model, this meta model
would purport to be if you could find it a
distillation of the inherent features of access control. Right
? And that's useful to know because if you understand
that model, you understand all these 700 models you
don't understand the details but you understand the inherent basis
for them. So it provides a common basis for
uh specifying exactly what access control means. And for
understanding the relationship among different models, it could facilitate
sharing of access control policy information because if I have
this more general framework, if I have some policy
expressed in one model, I could look at what
that means in terms of the meta model framework and
then translated into the equivalent statement in some other model
. So there's ways of sharing policy constructs across models
or among applications. It's useful to policy administrators because
they don't have to start from the ground up.
And with the definition of a policy, All they
have to do is to say, well, I
have this piece of the meta model. I want
to specify my policy by specializing that in this way
and that's exactly what my policy is going to be
and it provides a rapid prototyping mechanism? You don't
have uh you don't necessarily have to worry about providing
the entire framework for the access control mechanism because that
might be built into whatever support you have for the
meta model. And then you could develop policy languages
. So there are lots of languages that people have
attempted to develop, but it's unclear in many cases
whether they have a precise semantics or not. So
it's possible now with this meta model to use that
as the basis for building a language. And if
the meta model is precisely specified in a mathematical way
, the language that is derived from that will have
a strong semantic basis as well. So there's lots
of valuable both sort of theoretical properties like these as
well as pragmatic properties like these for developing this notion
of a meta model. So what does it look
like? What kind of formalism could we resort to
in order to build a meta model for things like
access control. And so this is the approach that
that barker took, which is pretty straightforward. The
thing I want to convince you of is that you
could go read barker's paper and it would be entirely
sensible there. You you um you don't need to
um the mathematics that's used can be viewed in a
very approachable way. Maybe that's the best way to
frame this message. So what are the elements here
? They're just countable sets. How hard is the
set? Alright. Set notations are pretty straightforward,
so it's all based on having sets and what's in
the sets and what what can you infer about the
contents of these sets? So he defines a set
of things that he calls categories. And these categories
just represent elements that you're trying to model. So
there might be classes of users that all have a
similar kind of attributes or it might be all of
the um files that have a particular kind of security
clearance. So these categories are just ways of grouping
similar things together and what what's similar about them may
vary widely from one model to the other and you
need all of these things, we saw them earlier
because this is the foundation for the questions that need
to be answered. Can this principle undertake this action
on this resource? So we need to be able
to model those elements but that's all we need.
Now, I should say if you read barker's paper
there are some other things in there because he wants
to include other capabilities. So I'm trimming this down
just a little bit um but not much. Alright
, so that's what we have to work with and
how do we put this all together? So here
is what the core axiom in barker's model looks like
and his um contribution is that that core axiom says
exactly what access control is and every access control model
can be derived from this simply by specializing its operations
. Right. And that's pretty cool because it's one
line long. Ah here's the antivirus software leaking information
from my machine and interfering with the talk. So
what does this line mean? Well, first of
all, let's look at the graphical form because it's
easier to see. So what we need to do
is to figure out whether this is something that we
would allow. Can this principle perform that action on
a given resource and let me just kill this thing
. Thank you. Right. Alright. So we
want to know whether we should allow that or not
. And that triple of things that's called an authorization
that is Do we want to authorize this? Seriously
? I can't kill this thing. Come on.
And now I've lost my mouse too. There it
is. Go away. Okay. Let's hope that
holds for a while. So do we want to
allow that authorization or not? And the answer is
well, look to see if this principle is in
some category. And if you can find a subset
in that category which contains this pair which is referred
to as a permission. It's a binding of an
action and a resource together. If you can find
that permission in some subset, then you would allow
this authorization. Right? So the more linear way
of looking at that is And you can read this
perfectly well, as a prologue statement. Is is
this allowed. Is that true in our system?
It is provided we could find bindings that satisfy these
constraints. So if we can find that P is
a member of some category C. And that's what
this pc a relationship tells us whether P is in
some category. And if that category contains some other
category C. Prime. And if that category C
prime contains this pair, then this is true in
our system. And in this paper barker shows,
okay, you're familiar with this access model. Here's
how you specialize our operations in order to get it
. If you're familiar with some other access control model
, here's how you specify the operation. So just
to um so I'm not going to spend much time
on this. But just to give you a sense
that the mathematics is not particularly complicated, but it
is precise. Here's what this say this pc a
relationship is all about, right. This is a
relationship that says uh this pair. Some principle in
some category is in this relation. If and only
if that P happens to be assigned to this category
. Right. So this is just a way of
asking is pee in that category. Right. And
this is just a way of asking is this pair
in that category. So it's based on very simple
things. You have countable sets and you have relations
that talk about elements of those sets. And on
the basis of that you get this core axiom,
which is sort of the distillation of what access control
means. Now, can you do anything with that
? Well, here's a really trivial example, suppose
we have a system where we have three files,
A. B and C. We have three principles
. Alice, bob and craig. And we want
to express some access control relationships about which of those
files are accessible to those principles and in which ways
. So here it's done very generically. I didn't
actually have great names for these things. So we
make up several categories. So here are the categories
are C. Zero through C. Four. And
here's Alice, we put Alice in category C1.
So what is Alice able to do according to that
core axiom? What we have to be able to
find is some permission that is in C. One
or a subset of C. One. So here
we see that read A is a permission that is
in a category which is a subset of C.
One. So we could for example allow Alice to
read L. A. And in a similar way
Alice could read file be and could write to file
A. This writing to file A is allowed not
only to Alice, but it's also allowed to bob
because this permission is also in another category. Principles
and permissions can be in multiple categories all at the
same time because you might want to be able to
express different kinds of constraints. We see here,
for example that craig is able to read both of
the files that Alice can read A and B but
cannot write to A. Because we are not able
to find the right relationship between this principle and that
permission because that would not satisfy our core axiom.
So you could probably imagine taking an access control models
that you're familiar with on file protection systems and imagine
how you could put them in this framework and that
should give you some confidence that yes, this better
model is really capturing concretely and realistically and precisely something
that I'm familiar with. Well, great. So
that's part of the problem solved. We now have
a way of um developing a very precise understanding about
what access control means and that's one of the two
major categories of mechanisms that we're using to ensure confidentiality
. What about the other mechanism about information flow control
and that's where our contribution is coming in. We
want to be able to take barker's framework and see
if we could develop an information flow models. So
our motivation for doing that is all of the same
motivations that barker had because everything that was true about
being able to compare access control models in his framework
, we could compare information flow models in our framework
but in addition we wanted to know is that possible
because he developed that framework for a particular kind of
perspective. Is that framework also adequate to define information
flow control. Can we use categories and relations or
as information flows somehow different and you need a different
kind of underpinning it also allows us if we could
develop this other meta model, we would now have
to meta models for the critical confidentiality mechanisms and we
might want to know how they compare to each other
and to explore possible combinations. What do you get
if you take some of this and some of that
and put it together? Do you get new and
useful things? So that's what our motivation was.
Okay, so what I want to do is is
go through a very simple information flow scenario just because
it helps to um give you some intuition if you're
not familiar with information flow control ideas but also it
will give us a set of basic requirements that our
model needs to include. So here in this uh
this this simple file sharing example. We have are
two principles Alice and bob and there are three files
, A, B and C. And the policy
that we want to enforce is that bob should only
be able to see public information. But Alice could
see information that's either public or private and the contents
of files and whether it's public or private is given
by this simple little color coding. So in one
scenario, imagine that Alice reads from file A and
that's possible because our policy allows Alice to access either
kind of information and Alice may then write that information
to file C. Which is fine because file C
. Is able to contain public information and then bob
could read that information. Okay. So what that
means is in this scenario, bob is able to
read what Alice wrote, bob is able to read
the contents of file C. And implicitly bob is
able to understand or infer something about the contents of
file A because the original information that Alice read was
from filet and it is implicitly being transferred perhaps even
directly and immediately being transferred to bob. But that's
fine because it's all within the it's seen as valid
within our policy framework. Well, here's a different
scenario suppose that Alice reads file b which is private
information and Alice is now in possession of something that
is not public. And so we should really change
our view of Alice's status to reflect the fact that
she now holds private information. If Alice writes that
information to see, we would similarly need to change
. File sees our sense about the sensitivity of what's
in file. See in a similar way. And
in this case bob would not be able to read
from file C. Because bob is not supposed to
have access to private information, bob would not be
able to read what Alice wrote because we don't want
bob to be able to infer anything about the contents
of this file be that has private information in.
So what is that telling us? That's telling us
that in some situations, bob can do certain actions
and in other cases? Not Alright. So in
the first scenario, bob could read the contents of
file, see in the second he could not,
In the first scenario he could read what Alice wrote
in the second scenario. Not in the first scenario
, Alice never really changed her status. She was
always a blue circle. In the second scenario,
she started out being a blue slicker and wound up
being a red circle and the same thing for file
C. Because we were trying to keep track of
whether something held private or public information. So that's
telling us what we need is something that's dynamic as
the system is operating. We need to dynamically determine
whether something is accessible or not. That means we
need some labeling here, we're using this color coding
, but we need some way to label what kind
of information anything is holding at a particular time.
And as we saw here with Alice, we need
at least two different kinds of things to keep track
of in order to express a policy like this.
Right? Because Alice is allowed to read over some
range bob has a more restricted range and where Alice
is in that range at any particular time, changes
over time. So we need at least two things
we need to keep track of. What kind of
information do you hold now and what kind of information
uh might you be able to hold? Are you
allowed to hold? So for Alice we would say
, well uh Alice starts out holding public but could
read private information as well. For bob we would
say he's at the public level and he can only
read public information. Now, one of the things
you might imagine is that different information flow control models
are going to vary widely based on how many levels
there are, what these clearances really look like,
what the space of labels is and how you manage
them. But that's all going to be details.
So how do we build this meta model? What
does that mean? And when you have to have
a dynamic mechanism that keeps track of things like these
labels that change dynamically and you need to have things
like levels and clearances in order to be able to
express the policy probably attributes that you need. Well
, the information flow meta model is more complicated.
So there is a single core axiom that sits at
the top below that. We need something to account
for the fact that there's dynamic things going on.
Right? So what is permitted at this point?
Depends on what's happened before. So we need to
keep track of history. Right? Because remember that
in scenario one Bob was able to do something because
the prior history didn't interfere with that In scenario two
Bob was not able to read from file. See
because what had happened before that reconfigured the system in
such a way that his access to file C should
now not be granted. So we need that history
. Well on top of that history we need to
keep track of okay in this history as it's evolving
what's happening with these levels and clearances. How are
the how is the color coding in that diagram changing
? And if you have information at this level and
information at that level and they flow together, what
do you get as a result? And finally down
at the bottom there's this initialization which is how you
actually specify a particular policy, you give the initial
conditions for the model. Okay. Now what happens
after this is much more selective um on my part
because I want to give you a sense, this
is really the important thing. This is how the
model is organized and what are the challenges this model
has to deal with and how are you, how
are all the relations that are defined to express this
model organized. And so if you want to put
on your systems hat for a minute you can think
about this is this is just a stack. Okay
, this is like a protocol stack, we've got
something at the top that we need to decide and
that thing is going to use all of the relations
that we define here. That thing is going to
use the relations we define here and that thing is
gonna depend on these initialization. Alright. So it's
just it's a you can think about it as a
layered architecture in a very pragmatic way. So what
is the core axiom? The core axiom in this
case reflects the nature of the problem that information flow
control is trying to address. So this core axiom
. So I'll talk about its picture first. The
picture says, should we authorize P to perform some
action on resource are Well, we can if we
can find these relationships if he happens to be in
some category, this category is like a label.
So if he has a particular label. So Alice
had a label like public and the Resource has a
label. So file C had a label like public
. And there is some relation that tells us if
you're doing this action, Does our system allow a
flow of information from one from an entity having this
label to an entity having the other label. And
whichever way this flow goes depends on what this operation
is. If it's a read operation, the flow
goes this way. If it's a write operation of
Flow goes that way. So that's all the core
axiom says. It says if the principal has a
certain label and the resource has a certain label and
it's allowed that an information flow between those labels is
permitted based on the direction implied by a then it's
fine. So if bob is in the category public
and the file C is in the category of public
. And we say that it's allowable for public information
to flow to public information, then fine, bob
can read file a So that part is pretty straightforward
and you can immediately see if you can remember back
to what the core axiom for access control. Was
. This is a very different formulation, right?
It still uses the basic underpinnings. We have categories
and we've got relations. We just added one new
category here. This set of labels and we have
a different set of relations, but we have the
same basic sort of mathematical underpinning to it. But
because it's answering a different question, those relations are
really organized in a very different way. Alright.
Well, how do we keep track of history?
We have to know because what Alice is doing is
going to influence what bob is capable of doing in
the future. How do we keep track of the
history? And it's visually, it's easy to see
what we have to do. Well, we have
to know what happened. So, we need some
formal way of reasoning about what happened and the things
that we are interested in is what did we allow
to happen previously? Because all of that history influences
the decision that we have to make now. So
here, at time. T the critical question is
if I'm looking at a principal, what label does
that principle have? If I'm looking at Alice,
is Alice at that point in time, is Alice's
label public? Or is Alice's label private? Because
that's going to make a difference to what Alice can
do. And similarly, for the Resource, we
need to be able to argue the same thing for
the resource. So what do we do? Well
, we just have a timeline and every time we
allow something to happen This granted means that we allowed
at time T one P which has this label to
access our where are had that label. That was
something that we authorized in the past. And we
just keep track of all the things that we've authorized
. So, if we want to know what's true
here, what label does Alice have? Well,
we just have to look backward in time and find
out well, what's affecting what what what has Alice
done previously. Right. So, in this history
, we would look back and say, well,
this doesn't matter because this is something that we did
for some other principles can't affect Alice. Well,
earlier Alice, we allowed Alice to do this,
and more recently, we allowed Alice to do this
. So between those two, the ones that we
obviously want to use is the more recent ones.
In fact, what we want to do is to
start from this point and go backward and find the
most recent thing that we allowed Alice to do and
ask when we allowed Alice to do that, what
label did Alice have as a result of being able
to do that? Because whatever label Alice had after
this operation, if that was the last operation,
that's the label that Alice had now, because nothing
else the system did would affect the label that Alice
had. How do you do that mathematically? Well
, you get a bunch of stuff like this.
It's just being careful and precise about what does it
mean? So, I only want to show you
the tip of the iceberg on what's here. So
what we want to know is what's the label associated
with a principal? What label does Alice have?
Well, what we really want to know is I
want to look back into history and look at what
label Alice had at different points in time. And
then what I'm interested in is the current time.
That's what I really want to know. And so
we can start looking back through that history and when
somebody develops a policy while they have to tell us
what's true at time zero, they have to give
us some initial label for Alice. And the rest
of this in between is just saying, well,
okay, if you really want to know what label
Alice has at time. T here's how you find
out, right? And there are different cases,
depending on what what kind of operation Alice did.
Um just to be very quick about this. What
this one means is look back in that history of
what's happened about things you've granted earlier and find a
point in time where you allowed Alice to do something
that's the closest to the current time. And if
what Alice was doing was a mutate operation. That
is an operation that was flowing information out from Alice
then, oh and this is the most recent time
then the label that Alice has now is the same
as the one that Alice had then. Because this
mutate operation wouldn't have changed her label if she did
. And another kind of operation, then you've got
to figure out what her new label is based on
the labels that she had then and whatever she read
from. So that's how we deal with the history
. The next layer down is um to be able
to see for example that here we have used an
operation combining because when Alice is currently remembering that scenario
, Alice had a public label. She read from
a private file. And her her label then changed
to be private to reflect the fact that she's holding
private information. Right? That's what this operation does
right? If I'm if I'm public now and I'm
reading this private thing, what's my new label?
Well in that case it's easy, it's private.
But we haven't defined this operation because that's an operation
that involves how do we combine these labels And that's
what our next layer down is what we have to
deal with labels levels and clearances. And so there's
a bunch of stuff to do that. And so
um what does one of this mean? So these
two things are just different because There's two types of
operations that information flow really focuses on. It really
focuses on whether the information flow is going from the
principal to the resource or from the resource of the
princess. There's lots of operations that can do either
one of those. So you just have to change
who you think is the source and who you think
is the destination depending on which way the flow is
going. What is the operator imply? And then
once you figured out the flow then you just have
to ask, well is it okay for there to
be a flow from here to there, depending on
different cases, ignore the details. This is the
combined operation that we looked at earlier. How do
we take to labels and combine them together when we
want each label to be have A level and it
also has a clearance. How do we work that
out? Well, we just kind of combined them
together but it depends on another undefined operation. This
joint operation, it says, if you have two
things like this, what does it mean to put
them together. Alright. And so here is our
model again. Right. And here's the various operations
or relations that we've seen at these various layers.
So here's the core axiom that's sitting up at the
top here, this history involved knowing whether the time
is the current time, what happened in the history
, whether this was the most recent event that happened
these time dependent versions of the labels for a principal
and a resource that allowed us then to figure these
things out. This thing depended on this combined operation
that we saw. That combined operation depends on this
joint operation. Right. And so if you wanted
to find a policy, what you have to do
is to specify all of these things, what does
that mean? It means you have to define,
well, what are my categories of levels and clearances
? How do I join them together when information with
these different levels and clearances combined? How do I
, what's the result of that? If I have
things with two different labels, can information flow from
one to the other? Yes or no. I
mean, tell me what's legitimate in this system,
describe your operations and tell me which one's which way
the flow goes for this particular operation. And tell
me what the initial assignment of labels is. Once
you have that, then the rest of this mechanism
kicks in and everything sort of happened. So that's
the model structure And here is our little example with
with bob and Alice and the files. This is
what it would look like to define a policy that
we used before. We have to define our principles
. So it's Alice and bob, we have to
define our resources, A, B and C.
We have two actions. Read and write. The
write operation is a mutate, which means that the
flow goes from the principal to the resource. The
read is an inspect operation where the flow goes from
the resource to the principal. And here we are
defining what are the legitimate flows. It's fine for
public to flow to public. Public to flow to
private and private to flow to private. Note The
missing one is you cannot have a flow that goes
from private to public. Here's how you combine these
various labels of public source and a public destination.
Well, the result is public right and so on
. So when Alice who is currently labeled public reads
private information analysis label must change to private. Why
? Well, because that's the policy we're defining,
we're just saying this is the way our system works
. Alright. So what do we get by having
done this work? So what um Well we've satisfied
our academic obligation. We published a paper have we
advanced the state of knowledge? Well that's what maybe
this is. So first of all, the framework
that barker developed is perfectly adequate for information flow as
well. We're just using categories and relations and it's
very closely modeled whenever possible on the framework that he
built for Access control. We can see some interesting
differences between access control and information flow control. Access
control is very explicit about the permission it gives,
you says you can write to that file but you
may not be able to append to that file because
that's a different operation if you want to append to
that file, I need a different permission. Information
flow doesn't care there's information if it's going to flow
into that file, I don't care how you do
it, I'm going to tell you whether you can
do it or not and how you do it and
I don't care, use whatever operation you want and
that's what this idea is about action. Granularity.
Okay, The information flow only cares about the direction
. It really doesn't care about the specific operation that's
implied. So, another way of saying that is
you can define an information flow model with only two
operations. Inspector mutate because you just it's one flow
or the other. Uh Information flow control is a
much more complex thing. We need a lot more
machinery to express information flow control. Remember access control
is one axiom. one core axiom in the information
flow case we need all of this stuff. Although
there's an interesting question about what is the meta model
exactly. And we don't quite know that yet is
the meta model. Just this and the rest of
this is some specialization is the meta model really.
This including the history and this is just specialization and
maybe there are alternative specializations that this layer. We
don't quite know yet. So we don't really have
a firm answer yet to what is the meta model
? that's part of the work to do. History
is definitely required for information flow control. You've got
to have some sort of history because it's dynamic.
Access control is not you don't need that. Here
are here's some hypothesis. This is telling you kind
of more what we don't know. So we want
to know how access control and information flow control compared
to each other. I think this so this is
hypothesis is what I think if you just look at
the core axioms and you discard everything else, they're
the same. They're just different formulations of the same
thing. You can't really tell at that level that
there's any difference. It's only when you add in
the history and begin to interpret some of those operations
that you get some differentiation. Now, what this
picture is suggesting over here is another model that barker
developed was a thing called status based access control where
he included a history but it was it was a
history that was only about the principle. They only
kept track of a history for principles because they wanted
to keep track of the status of those principles.
Did they have a particular status at some point in
time and that was definitely a specific kind of access
control but you needed to add a history mechanism to
it. Well with information flow control, the way
we've defined it is you get a history not only
of principles but of resources. So it should be
the case that this is more powerful than that because
we're keeping track of more stuff. We could express
policies over here that refer to the history of resources
that can't be expressed over there. But anything you
could express over here we should be able to do
. That's a hypothesis. What about these other things
right now that you start to see these pieces?
What other ways could those pieces be combined? So
what if you took access control and put a resource
history along with it? Is that interesting? You
could always come up with some cockamamie policy but is
it interesting? Does that fill some gap that we've
always had but didn't know how to deal with or
if you took information flow control and only did a
history of resources not principles. What would you get
right? Because it's not as powerful as this,
but it's more powerful than this. But what is
it exactly? Is it useful? Does it give
us our next 700 papers? Right. Because we
just keep combining these things in different ways and writing
writing papers about the combination or this is just this
is the core axiom for the access control. Here's
what it is and here is the core axiom for
information Flow control. So what happens if we now
think about adding those two things together? Alright,
because confidentiality is not just about what you can access
, it's about what you can do with it.
So you need a little bit of both. You
need some access control to say can you look at
this thing and some information flow control to say once
you've looked at it, what can you do with
it? Who could you share it with? So
what do we get if we try to combine those
things? We don't know. Right? I'm not
sure we've been in a position to really ask that
question yet, because we haven't been in a position
to see really clearly, oh this is what that
is, and this is what this is. And
now how do we combine them? And you?
And you can see there are perfectly compatible because you
could say the only time you could do something,
the only time you're authorized to do something is if
this says you can and this says it's also allowed
. Alright. So it's conceptually at the high level
, easy to combine them. But you get other
interesting questions. So here it's talking about open versus
closed systems. So a closed system is one that
says you cannot do anything unless I explicitly say you
can, an open system is one that says you
can do anything that you want unless I say you
can't. So a library is like an open system
, right? You can go into the library and
do anything you want, you can look at any
book you want except you can't go into the reserve
collection because I explicitly said you can't go in there
because I put a locked door closed systems are like
UNIX file systems. You can't access this file unless
I explicitly say you can one way or the other
. Well what happens if you try and combine a
closed access control system in an open information flow control
system or an open access control system in a closed
information flow control systems? Do you get interesting policies
, Are there things that we want to be able
to build for android devices for smartphones? For cloud
computing? For all of the new information share for
facebook or google circles? Are there policies that we
want to express about the confidentiality of information that this
now gives us some perspective or being able to identify
. Okay, so future work um we want to
play with the stuff that we've developed. Alright,
so we want to develop specializations for different kinds of
information flow models to see if did we get it
right. That is if there are six information flow
models. Can we see how to specialize our model
for each one of them? Um Can we develop
extensions to our model to incorporate other things. One
of the things we're interested in is community oriented control
. How would that look like in this model?
I want to be able to do continues comparisons with
Access control, explore this design space that I've talked
a little bit about. Um We want to develop
computational realization. So this is all in a computational
logic sort of framework. So can we take some
tools build our model into those tools and use that
to explore properties of policies or systems or to serve
as a prototyping mechanism for systems that we want to
build. And we want to use this as a
continuing guide for this um privacy project that we have
that deals with a community oriented perspective on privacy.
So these are the various people who have collaborated in
this larger project. So Denis Grachev and in his
mug shot here, he didn't give me a better
one. So uh is really the collaborator that I've
been working with on this um on this information flow
control meta model. Um but other faculty and and
other students have worked on other parts of this bigger
project, which is about privacy in a community setting
. Where um so the way in which we came
to to define this meta model was because we had
a proposal about studying community privacy where the reviewers kept
saying why isn't this just access control? So he
said fine, I'll tell you why it's not because
we're going to develop this freaking model and that's what
we're doing and you see it's really not that Okay
, so this is the time for questions, the
most important of which is where is the sign up
sheet? Where is it? Okay, so there
it is? Alright, so I've answered that question
for you, are there other questions that I can
answer for you? First of all I should say
in my part. Thanks for coming. The last
, the way you define friendship is in two ways
. One is if you agree fourth to give the
last seminar of the year for someone you're their friend
and if you come to the last seminar of the
year, you're my friend. Alright, so thank
you very much, I applaud you for coming.
So are there questions or do we want to just
go to lunch? Yeah. Right. I'll get
a better sense of this later in the summer.
But um it certainly hasn't stopped people from defining new
models. Um but at least it may cause them
to at least have to write that paragraph that says
why are we defining yet a different model? And
how does it relate to other models? It's just
like Landon's paper didn't stop people from inventing new programming
languages, other questions, thoughts remember as always there'll
be an opportunity for the meet the speaker later today
, out in Knowledge Works. Uh In fact,
we remember that there is the usual reception at Barbara's
house this evening. Thank you