1
00:00:00,090 --> 00:00:02,430
The following content is
provided under a Creative

2
00:00:02,430 --> 00:00:03,820
Commons license.

3
00:00:03,820 --> 00:00:06,050
Your support will help
MIT OpenCourseWare

4
00:00:06,050 --> 00:00:10,150
continue to offer high-quality
educational resources for free.

5
00:00:10,150 --> 00:00:12,700
To make a donation or to
view additional materials

6
00:00:12,700 --> 00:00:16,600
from hundreds of MIT courses,
visit MIT OpenCourseWare

7
00:00:16,600 --> 00:00:17,260
at ocw.mit.edu.

8
00:00:27,280 --> 00:00:28,940
PROFESSOR: All right.

9
00:00:28,940 --> 00:00:30,760
Let's get started.

10
00:00:30,760 --> 00:00:33,670
So today we're going to talk
about Android security, which

11
00:00:33,670 --> 00:00:36,180
is-- you can sort of think
of it as an interesting case

12
00:00:36,180 --> 00:00:39,170
study of a system
that was designed

13
00:00:39,170 --> 00:00:41,150
with quite a bit
of attention paid

14
00:00:41,150 --> 00:00:42,720
to security in the first place.

15
00:00:42,720 --> 00:00:45,750
So this is perhaps in contrast
to many of the systems

16
00:00:45,750 --> 00:00:47,930
we've looked at
so far, like Unix,

17
00:00:47,930 --> 00:00:51,570
or the web, browsers,
where security

18
00:00:51,570 --> 00:00:54,260
was in many ways bolted
on after the fact

19
00:00:54,260 --> 00:00:57,290
and wasn't really designed
in quite the same way

20
00:00:57,290 --> 00:01:00,127
as you see in this paper,
where these guys who

21
00:01:00,127 --> 00:01:01,710
designed the Android
were very worried

22
00:01:01,710 --> 00:01:03,660
about particular
classes of attacks,

23
00:01:03,660 --> 00:01:05,500
and constructive mechanisms.

24
00:01:05,500 --> 00:01:08,765
Then figured out a better way
of structuring applications

25
00:01:08,765 --> 00:01:12,210
that is going to allow us
to enforce security policies

26
00:01:12,210 --> 00:01:15,790
in a better way in Android.

27
00:01:15,790 --> 00:01:18,355
And the cool thing about
it is that it's actually

28
00:01:18,355 --> 00:01:20,620
a pretty widely used system.

29
00:01:20,620 --> 00:01:22,115
So unlike some
research papers that

30
00:01:22,115 --> 00:01:24,520
might propose a
new architecture,

31
00:01:24,520 --> 00:01:26,020
this actually gets
used in practice.

32
00:01:26,020 --> 00:01:28,311
And there's lots and lots of
Android devices out there.

33
00:01:28,311 --> 00:01:31,050
And we can talk about how well
some things have worked out,

34
00:01:31,050 --> 00:01:34,690
how well some things
didn't pan out.

35
00:01:34,690 --> 00:01:38,990
But we will, I
guess, look at what

36
00:01:38,990 --> 00:01:41,000
parts of the design they
thought were important,

37
00:01:41,000 --> 00:01:44,140
what did they miss, what,
in practice, turns out

38
00:01:44,140 --> 00:01:46,192
to matter or not.

39
00:01:46,192 --> 00:01:47,400
But it's kind of interesting.

40
00:01:47,400 --> 00:01:49,661
In some ways, it also
uses existing systems

41
00:01:49,661 --> 00:01:50,660
that we've talked about.

42
00:01:50,660 --> 00:01:53,660
So Android is built
on top of Unix.

43
00:01:53,660 --> 00:01:58,010
It's just a Linux kernel running
underneath the entire phone.

44
00:01:58,010 --> 00:02:01,240
So in many ways, they use some
of the familiar mechanisms

45
00:02:01,240 --> 00:02:03,330
you guys have seen
in Lab 2 already,

46
00:02:03,330 --> 00:02:07,040
where you use Unix user IDs
and groups and all these things

47
00:02:07,040 --> 00:02:09,579
to separate applications
from one another.

48
00:02:09,579 --> 00:02:12,210
But in Android's case, they
have a very different way

49
00:02:12,210 --> 00:02:15,960
of setting up user IDs
and file permissions,

50
00:02:15,960 --> 00:02:20,540
et cetera, than in a
typical Linux system.

51
00:02:20,540 --> 00:02:23,420
So I guess let's
start out by talking

52
00:02:23,420 --> 00:02:25,093
about what is the threat level?

53
00:02:25,093 --> 00:02:28,820
What are these guys
worried about on a phone?

54
00:02:28,820 --> 00:02:29,780
What's going on?

55
00:02:29,780 --> 00:02:31,480
What are they trying
to protect against?

56
00:02:31,480 --> 00:02:34,344
What's the threat model?

57
00:02:34,344 --> 00:02:34,844
Yeah.

58
00:02:34,844 --> 00:02:37,326
AUDIENCE: Applications that
want to do malicious things?

59
00:02:37,326 --> 00:02:37,992
PROFESSOR: Yeah.

60
00:02:37,992 --> 00:02:39,090
So they worry
about-- I guess there

61
00:02:39,090 --> 00:02:41,506
was these applications that
are going to run on the phone.

62
00:02:41,506 --> 00:02:44,910
And they might be malicious.

63
00:02:44,910 --> 00:02:48,810
And I guess there's-- well,
that there's outright malicious

64
00:02:48,810 --> 00:02:51,680
applications that are
just out to get you,

65
00:02:51,680 --> 00:02:53,540
maybe steal your private data.

66
00:02:53,540 --> 00:02:56,440
So things you might worry
about-- there's data,

67
00:02:56,440 --> 00:02:58,290
there's things that
might cost money,

68
00:02:58,290 --> 00:03:02,030
like sending an SMS message
maybe, or making a phone call.

69
00:03:02,030 --> 00:03:06,461
There's maybe using the
internet, et cetera.

70
00:03:06,461 --> 00:03:07,960
So these are the,
presumably, things

71
00:03:07,960 --> 00:03:10,820
you want to guard against
or protect on your phone.

72
00:03:10,820 --> 00:03:12,544
And then there's
things that go wrong.

73
00:03:12,544 --> 00:03:14,460
So presumably, there's
malicious applications,

74
00:03:14,460 --> 00:03:18,200
because these guys want to
allow users to install apps

75
00:03:18,200 --> 00:03:20,620
written by developers
that Google has never

76
00:03:20,620 --> 00:03:22,210
heard of themselves.

77
00:03:22,210 --> 00:03:26,035
Or it might be that apps just
have bugs themselves, that you

78
00:03:26,035 --> 00:03:28,570
have a well-meaning
developer, but they

79
00:03:28,570 --> 00:03:29,550
forget to do something.

80
00:03:29,550 --> 00:03:31,270
And it would be nice
to help these guys

81
00:03:31,270 --> 00:03:34,650
as well to build applications
that remain secure

82
00:03:34,650 --> 00:03:37,150
despite the fact that
the app developer isn't

83
00:03:37,150 --> 00:03:40,680
an expert in exactly every
kind of vulnerability

84
00:03:40,680 --> 00:03:45,580
that might be exploited
in their application.

85
00:03:45,580 --> 00:03:48,350
So one thing we could
do is, actually, we

86
00:03:48,350 --> 00:03:50,250
can-- because Android
is what we use,

87
00:03:50,250 --> 00:03:53,520
we can look at various
vulnerability reports.

88
00:03:53,520 --> 00:03:55,840
So there's this
database called CVE

89
00:03:55,840 --> 00:03:58,330
that catalogs lots of
common vulnerabilities

90
00:03:58,330 --> 00:04:00,900
in software systems.

91
00:04:00,900 --> 00:04:02,590
And it's actually
kind of interesting.

92
00:04:02,590 --> 00:04:07,598
There is a number of reports,
of course, of bugs in Android.

93
00:04:07,598 --> 00:04:09,960
And many of them are of the
flavor you guys have already

94
00:04:09,960 --> 00:04:10,900
seen in the class.

95
00:04:10,900 --> 00:04:12,274
So there's still
buffer overflows

96
00:04:12,274 --> 00:04:13,610
in some parts of Android.

97
00:04:13,610 --> 00:04:15,960
There's bad default
choices for crypto systems.

98
00:04:15,960 --> 00:04:18,600
People forget to initialize
the random number

99
00:04:18,600 --> 00:04:21,089
generator sometimes and
generate predictable keys.

100
00:04:21,089 --> 00:04:23,240
So all these things
do still happen.

101
00:04:23,240 --> 00:04:23,960
It's software.

102
00:04:23,960 --> 00:04:26,370
It's not immune from any
of the other problems

103
00:04:26,370 --> 00:04:27,613
we've seen so far.

104
00:04:27,613 --> 00:04:30,020
But one cool thing
is that there doesn't

105
00:04:30,020 --> 00:04:31,790
seem to be a huge
number of these issues.

106
00:04:31,790 --> 00:04:33,550
So they crop up
from time to time.

107
00:04:33,550 --> 00:04:36,780
But by large, can
fix these issues.

108
00:04:36,780 --> 00:04:39,360
And the system remains
reasonably secure

109
00:04:39,360 --> 00:04:41,290
after you fix these bugs.

110
00:04:41,290 --> 00:04:44,280
So in many ways,
this, I think, design

111
00:04:44,280 --> 00:04:46,620
is working reasonably well.

112
00:04:46,620 --> 00:04:49,590
So we'll look at it, I guess,
in more details later on as

113
00:04:49,590 --> 00:04:52,790
to which parts of the design
are working to various degrees.

114
00:04:52,790 --> 00:04:58,570
But it seems to be a reasonably
well thought out design.

115
00:04:58,570 --> 00:05:03,160
Or at least much more so than
desktop Unix applications

116
00:05:03,160 --> 00:05:05,750
that you've seen so far.

117
00:05:05,750 --> 00:05:06,480
All right.

118
00:05:06,480 --> 00:05:10,110
So maybe one way to approach
this is to figure out

119
00:05:10,110 --> 00:05:12,880
how we're going to protect
data and various services

120
00:05:12,880 --> 00:05:14,530
that might cost you
money, et cetera,

121
00:05:14,530 --> 00:05:17,740
from malicious applications
is first to understand

122
00:05:17,740 --> 00:05:21,940
what does an application look
like in an Android system.

123
00:05:21,940 --> 00:05:24,990
And then we'll talk about
how various permissions

124
00:05:24,990 --> 00:05:30,940
or privileges are configured in
that application and enforced.

125
00:05:30,940 --> 00:05:34,860
So Android applications are
quite different from what

126
00:05:34,860 --> 00:05:38,050
you've seen so far in terms
of desktop apps or web

127
00:05:38,050 --> 00:05:39,100
applications.

128
00:05:39,100 --> 00:05:41,375
So instead of being
a monolithic piece

129
00:05:41,375 --> 00:05:43,980
of code with a main function
that you start running,

130
00:05:43,980 --> 00:05:46,160
and you just keep
going forever, they're

131
00:05:46,160 --> 00:05:47,640
actually much more modular.

132
00:05:47,640 --> 00:05:52,275
And the application, in the
case of Android, is-- actually,

133
00:05:52,275 --> 00:05:55,340
you can think of it as a
collection of components.

134
00:05:55,340 --> 00:05:59,090
And the paper talks about
four kinds of components

135
00:05:59,090 --> 00:06:03,440
that the Android
framework provides to you

136
00:06:03,440 --> 00:06:05,870
or gets the developer
to think in terms of.

137
00:06:05,870 --> 00:06:08,550
And the components
are roughly-- there's

138
00:06:08,550 --> 00:06:10,969
something called an activity.

139
00:06:10,969 --> 00:06:12,510
You might have an
activity component.

140
00:06:12,510 --> 00:06:16,350
And this is just a thing
that has a user interface.

141
00:06:16,350 --> 00:06:18,790
So these are things that
actually display things

142
00:06:18,790 --> 00:06:22,450
to the user, or take
user input, touches,

143
00:06:22,450 --> 00:06:23,920
key presses, et cetera.

144
00:06:23,920 --> 00:06:26,660
In terms of security,
the Activity thing

145
00:06:26,660 --> 00:06:28,910
has an interesting security
property that you probably

146
00:06:28,910 --> 00:06:30,920
want to make sure your
user input is going

147
00:06:30,920 --> 00:06:33,260
to one activity at a time.

148
00:06:33,260 --> 00:06:36,190
So the framework-- I believe
[? an ?] Android actually

149
00:06:36,190 --> 00:06:39,137
ensures that there is only
one activity that's getting

150
00:06:39,137 --> 00:06:40,220
your user input at a time.

151
00:06:40,220 --> 00:06:43,550
So if you are running
your bank application,

152
00:06:43,550 --> 00:06:45,610
you can be reasonably
confident that there's not

153
00:06:45,610 --> 00:06:49,530
other applications in the
background grabbing the screen

154
00:06:49,530 --> 00:06:53,390
presses corresponding to your
PIN number in your bank app.

155
00:06:53,390 --> 00:06:58,410
So having the framework be aware
of these different activities

156
00:06:58,410 --> 00:07:01,690
helps enforce some security
properties with respect

157
00:07:01,690 --> 00:07:03,970
to user input.

158
00:07:03,970 --> 00:07:04,650
All right.

159
00:07:04,650 --> 00:07:07,780
So these guys are the
user interface components

160
00:07:07,780 --> 00:07:08,790
of an application.

161
00:07:08,790 --> 00:07:11,280
And then there's
three other types

162
00:07:11,280 --> 00:07:14,870
of components that mostly
help an application

163
00:07:14,870 --> 00:07:19,240
structure its own sort
of logic and interaction

164
00:07:19,240 --> 00:07:21,180
with other components.

165
00:07:21,180 --> 00:07:25,650
So there is something
called a service component.

166
00:07:25,650 --> 00:07:28,220
And this guy just runs
in the background.

167
00:07:28,220 --> 00:07:29,990
So you might have
a service component

168
00:07:29,990 --> 00:07:33,250
that monitors your location,
like in the application

169
00:07:33,250 --> 00:07:36,089
these guys describe
in the paper.

170
00:07:36,089 --> 00:07:37,880
Or you might have
services that pull things

171
00:07:37,880 --> 00:07:42,020
from the network in the
background, et cetera.

172
00:07:42,020 --> 00:07:44,415
These guys have a content
provider component.

173
00:07:47,500 --> 00:07:52,580
And you can think of
these guys as just SQL

174
00:07:52,580 --> 00:07:54,000
database you can define.

175
00:07:54,000 --> 00:07:55,880
Or you can define
a couple of tables

176
00:07:55,880 --> 00:07:56,980
with a schema, et cetera.

177
00:07:56,980 --> 00:07:59,456
And you can run SQL
queries all over the data

178
00:07:59,456 --> 00:08:00,580
stored in that application.

179
00:08:00,580 --> 00:08:03,020
And having it be a
component is going

180
00:08:03,020 --> 00:08:05,800
to allow the framework
to control access

181
00:08:05,800 --> 00:08:08,070
to this database to say
who's allowed to run queries

182
00:08:08,070 --> 00:08:09,700
against it.

183
00:08:09,700 --> 00:08:14,160
And then there's
something kind of unusual

184
00:08:14,160 --> 00:08:16,580
that hasn't shown up in other
systems-- something called

185
00:08:16,580 --> 00:08:18,189
a broadcast receiver.

186
00:08:22,780 --> 00:08:26,660
And this guy is going to be
used for receiving messages

187
00:08:26,660 --> 00:08:28,010
from other parts of the system.

188
00:08:28,010 --> 00:08:30,520
So we'll talk about how
applications interact with one

189
00:08:30,520 --> 00:08:34,040
other in terms of messages.

190
00:08:34,040 --> 00:08:34,539
All right.

191
00:08:34,539 --> 00:08:38,200
So this is some very
high-level logical view

192
00:08:38,200 --> 00:08:40,549
of how you can think of
an Android application.

193
00:08:40,549 --> 00:08:46,550
But in reality, all these are
just Java classes or Java code

194
00:08:46,550 --> 00:08:48,920
that the developer writes.

195
00:08:48,920 --> 00:08:51,340
And there's just some standard
interface for an activity,

196
00:08:51,340 --> 00:08:53,006
for a service, for a
broadcast receiver,

197
00:08:53,006 --> 00:08:55,700
for a content provider
that you implement.

198
00:08:55,700 --> 00:08:57,490
But clearly, this is
all just Java code.

199
00:08:57,490 --> 00:09:02,870
And this application box is
really just a Java runtime

200
00:09:02,870 --> 00:09:06,790
that runs on top of your phone.

201
00:09:06,790 --> 00:09:10,270
And it's just a single
process on the Linux

202
00:09:10,270 --> 00:09:12,130
kernel running on your phone.

203
00:09:12,130 --> 00:09:13,820
And all these
components are just

204
00:09:13,820 --> 00:09:17,310
different classes or pieces
of code running inside

205
00:09:17,310 --> 00:09:19,375
of this Java runtime process.

206
00:09:19,375 --> 00:09:20,865
That make sense?

207
00:09:20,865 --> 00:09:24,590
That's how it sort of translates
to traditional processes

208
00:09:24,590 --> 00:09:27,380
that you might
understand otherwise.

209
00:09:27,380 --> 00:09:31,360
And the other thing that sort
of shifts with an application

210
00:09:31,360 --> 00:09:32,730
is what's called a manifest.

211
00:09:32,730 --> 00:09:36,010
So this is code that the
application developer

212
00:09:36,010 --> 00:09:37,450
writes or compiles.

213
00:09:37,450 --> 00:09:39,940
But there's also
this manifest that

214
00:09:39,940 --> 00:09:44,240
sits on the side, which
is a text or an XML file,

215
00:09:44,240 --> 00:09:46,540
really, that describes
all these components

216
00:09:46,540 --> 00:09:49,980
and how other
parts of the system

217
00:09:49,980 --> 00:09:51,630
should interact with
this application.

218
00:09:51,630 --> 00:09:53,550
So in particular,
this manifest is

219
00:09:53,550 --> 00:09:56,280
going to talk about
things called labels

220
00:09:56,280 --> 00:09:58,650
that we'll talk about
in a second that

221
00:09:58,650 --> 00:10:02,820
define both the privileges
of this application in terms

222
00:10:02,820 --> 00:10:04,580
of what it should
be allowed to do

223
00:10:04,580 --> 00:10:08,200
as well as the
restrictions on who else

224
00:10:08,200 --> 00:10:10,590
should be able to interact
with the different components

225
00:10:10,590 --> 00:10:13,210
of this application.

226
00:10:13,210 --> 00:10:15,456
That make sense?

227
00:10:15,456 --> 00:10:18,100
Questions about how that works?

228
00:10:18,100 --> 00:10:20,480
AUDIENCE: Is the
label something like,

229
00:10:20,480 --> 00:10:24,194
this app cannot do the phone
call, or this app can send--

230
00:10:24,194 --> 00:10:24,860
PROFESSOR: Yeah.

231
00:10:24,860 --> 00:10:26,670
So these labels are
going to be things

232
00:10:26,670 --> 00:10:29,560
like, well, this application
can dial a phone,

233
00:10:29,560 --> 00:10:33,190
or can send an SMS message,
or can use the internet.

234
00:10:33,190 --> 00:10:35,205
So there's really
two kinds of labels.

235
00:10:35,205 --> 00:10:36,960
So we can draw them out here.

236
00:10:36,960 --> 00:10:41,690
So each application
has a list of labels

237
00:10:41,690 --> 00:10:45,560
that describe the privileges
that the application has.

238
00:10:45,560 --> 00:10:48,690
So these are something
like maybe DIAL PERMISSION

239
00:10:48,690 --> 00:10:54,700
for dialing a phone,
maybe INTERNET, et cetera.

240
00:10:54,700 --> 00:10:57,710
So we'll talk about how they're
described in a little bit.

241
00:10:57,710 --> 00:10:59,980
So these are privileges
that the application has.

242
00:10:59,980 --> 00:11:01,790
But then you can
also stick labels

243
00:11:01,790 --> 00:11:03,670
on top of individual components.

244
00:11:03,670 --> 00:11:06,320
And there, they have
a different meaning.

245
00:11:06,320 --> 00:11:09,294
So these are privileges
that the application has.

246
00:11:09,294 --> 00:11:11,030
If you have a label
[? on a ?] component,

247
00:11:11,030 --> 00:11:13,410
it's a requirement
on anyone that

248
00:11:13,410 --> 00:11:16,420
talks with the component to
have the corresponding label.

249
00:11:16,420 --> 00:11:20,220
So in their example,
maybe you have some sort

250
00:11:20,220 --> 00:11:25,090
of a FRIEND VIEW privilege.

251
00:11:25,090 --> 00:11:29,805
So you are able to view the
locations of your friends.

252
00:11:29,805 --> 00:11:33,290
So that's like a privilege you
might have in an application.

253
00:11:33,290 --> 00:11:34,630
So you're allowed to do this.

254
00:11:34,630 --> 00:11:37,110
But then in order to
enforce this privilege,

255
00:11:37,110 --> 00:11:40,130
you might actually put
this FRIEND VIEW label

256
00:11:40,130 --> 00:11:41,920
onto a particular component.

257
00:11:41,920 --> 00:11:45,130
So you might say, well, my
content provider, the database

258
00:11:45,130 --> 00:11:47,280
storing the location
of all my friends,

259
00:11:47,280 --> 00:11:50,330
might have the FRIEND
VIEW label attached to it.

260
00:11:50,330 --> 00:11:52,630
And what this means
is that anyone that

261
00:11:52,630 --> 00:11:54,410
wants to access
this database better

262
00:11:54,410 --> 00:11:57,400
have this label in
their privilege set.

263
00:11:57,400 --> 00:12:00,470
So that's how you
specify permissions.

264
00:12:00,470 --> 00:12:04,440
You can think these are as like
generalized user IDs or group

265
00:12:04,440 --> 00:12:06,160
IDs from Unix, except
they're arbitrary

266
00:12:06,160 --> 00:12:08,160
strings, which make them
slightly more flexible.

267
00:12:08,160 --> 00:12:09,493
You don't run out of these guys.

268
00:12:09,493 --> 00:12:11,000
You don't worry
so much about who

269
00:12:11,000 --> 00:12:14,510
gets the number 25 or
silly things like that.

270
00:12:14,510 --> 00:12:15,470
AUDIENCE: [INAUDIBLE].

271
00:12:19,594 --> 00:12:20,260
PROFESSOR: Yeah.

272
00:12:20,260 --> 00:12:24,190
So turns out these guys
aren't-- at least in the design,

273
00:12:24,190 --> 00:12:27,400
weren't super careful in
scoping these guys out.

274
00:12:27,400 --> 00:12:29,650
So you could totally have
two applications that decide

275
00:12:29,650 --> 00:12:32,170
to introduce the same label.

276
00:12:32,170 --> 00:12:35,370
So these labels are
application-defined, partly.

277
00:12:35,370 --> 00:12:37,400
And you could have
two applications,

278
00:12:37,400 --> 00:12:39,050
like Facebook and Google+.

279
00:12:39,050 --> 00:12:41,785
They say, oh, we
want to both create

280
00:12:41,785 --> 00:12:46,262
a new permission string that's
View Your Friends In A Social

281
00:12:46,262 --> 00:12:47,070
Network.

282
00:12:47,070 --> 00:12:47,570
All right.

283
00:12:47,570 --> 00:12:49,110
Well, they're the same string.

284
00:12:49,110 --> 00:12:51,217
So by convention,
what happens is

285
00:12:51,217 --> 00:12:52,800
that these strings
are actually longer

286
00:12:52,800 --> 00:12:53,924
than what I am drawing out.

287
00:12:53,924 --> 00:12:56,940
And they have the domain
of the Java-style domain

288
00:12:56,940 --> 00:12:59,640
of the application
defining it in the string.

289
00:12:59,640 --> 00:13:01,944
So DIAL PERM, I
think, is actually

290
00:13:01,944 --> 00:13:03,735
something like
com.google.android.dialperm.

291
00:13:10,920 --> 00:13:13,600
I might have slightly
screwed this up.

292
00:13:13,600 --> 00:13:15,460
But roughly, these are
the kinds of strings

293
00:13:15,460 --> 00:13:16,626
that show up in permissions.

294
00:13:16,626 --> 00:13:19,550
So if you have
well-meaning applications,

295
00:13:19,550 --> 00:13:23,577
then they won't collide in terms
of these permission strings.

296
00:13:23,577 --> 00:13:25,160
But it turns out
that nothing actually

297
00:13:25,160 --> 00:13:27,300
enforces this,
unfortunately, in Android.

298
00:13:27,300 --> 00:13:29,035
So you do have some
potential problem

299
00:13:29,035 --> 00:13:32,940
that arise as a result
of this, that-- I don't

300
00:13:32,940 --> 00:13:34,590
know why they weren't fixed.

301
00:13:34,590 --> 00:13:36,370
It's a little bit
tricky to fix them.

302
00:13:36,370 --> 00:13:38,420
Maybe these guys
thought, well, let's

303
00:13:38,420 --> 00:13:40,140
do them now, [? for ?]
maybe they weren't

304
00:13:40,140 --> 00:13:40,950
thinking of these issues.

305
00:13:40,950 --> 00:13:41,450
Anyway.

306
00:13:41,450 --> 00:13:43,270
So we'll see what
arises if you have

307
00:13:43,270 --> 00:13:47,889
two applications that conflict
on the label names that we get.

308
00:13:47,889 --> 00:13:48,735
All right.

309
00:13:48,735 --> 00:13:50,930
Make sense?

310
00:13:50,930 --> 00:13:51,770
All right.

311
00:13:51,770 --> 00:13:54,900
So this is what a single
application looks like.

312
00:13:54,900 --> 00:13:57,480
It's a bunch of Java code,
a manifest describing

313
00:13:57,480 --> 00:13:59,930
the permissions for
the application,

314
00:13:59,930 --> 00:14:03,500
and the required restrictions
on all the components.

315
00:14:03,500 --> 00:14:06,590
And then in order to communicate
between applications,

316
00:14:06,590 --> 00:14:09,730
for the most part, it's
done through what's

317
00:14:09,730 --> 00:14:11,950
called an intent,
which is an Android

318
00:14:11,950 --> 00:14:15,240
thing that the developers of
this framework introduced.

319
00:14:15,240 --> 00:14:21,000
And an intent-- you can think
of it as a structured message

320
00:14:21,000 --> 00:14:24,366
that-- we'll see how these
components of an intent

321
00:14:24,366 --> 00:14:25,740
are going to be
used in a second.

322
00:14:25,740 --> 00:14:28,650
But roughly, the intent
has three important things.

323
00:14:28,650 --> 00:14:30,320
There's other fields, of course.

324
00:14:30,320 --> 00:14:33,910
But the main thing is the name
of a component to which you

325
00:14:33,910 --> 00:14:36,020
want to send a message.

326
00:14:36,020 --> 00:14:40,590
There's the action that you
want the component to take

327
00:14:40,590 --> 00:14:45,601
and the data, along
with a MIME type,

328
00:14:45,601 --> 00:14:49,310
that you want to send
to this other component.

329
00:14:49,310 --> 00:14:51,770
So just as an example--
this is a little abstract--

330
00:14:51,770 --> 00:14:55,140
but what you can imagine is
that this component is maybe--

331
00:14:55,140 --> 00:15:04,670
you could imagine
com.android.dialer/Dial

332
00:15:04,670 --> 00:15:05,660
or something.

333
00:15:05,660 --> 00:15:09,070
So this is how you name
a component in Android.

334
00:15:09,070 --> 00:15:12,120
You specify the name
of the application,

335
00:15:12,120 --> 00:15:15,030
which is kind of like this
Java inverted domain name.

336
00:15:15,030 --> 00:15:17,343
Like, com.android.dialer
is the name

337
00:15:17,343 --> 00:15:18,926
of an overall
application to which you

338
00:15:18,926 --> 00:15:20,260
want to send an intent.

339
00:15:20,260 --> 00:15:22,570
And then you write
something like /Dial.

340
00:15:22,570 --> 00:15:24,459
And Dial is the
name of a component.

341
00:15:24,459 --> 00:15:26,500
Would [? lend ?] that
target application to which

342
00:15:26,500 --> 00:15:29,600
you are sending this message.

343
00:15:29,600 --> 00:15:30,210
OK.

344
00:15:30,210 --> 00:15:33,729
So that's how you name
the particular component

345
00:15:33,729 --> 00:15:35,020
where you want to send the guy.

346
00:15:35,020 --> 00:15:38,815
The action, there's a
predefined set of actions.

347
00:15:38,815 --> 00:15:41,090
You could stick in your
own things as well.

348
00:15:41,090 --> 00:15:44,717
But you might have
something like, I think,

349
00:15:44,717 --> 00:15:45,550
android.intent.DIAL.

350
00:15:50,030 --> 00:15:54,460
So this is a pre-defined string
or, by convention, a string

351
00:15:54,460 --> 00:15:57,530
that applications put
on the Action field

352
00:15:57,530 --> 00:16:01,370
if they want the phone dialer
to dial a phone number for them.

353
00:16:01,370 --> 00:16:03,194
So this is how you
stick something in here.

354
00:16:03,194 --> 00:16:04,110
There's other actions.

355
00:16:04,110 --> 00:16:06,320
Like, if you want
to view a document,

356
00:16:06,320 --> 00:16:10,240
you will stick something.view
in the Action field.

357
00:16:10,240 --> 00:16:11,970
This'll tell the
receiving component

358
00:16:11,970 --> 00:16:13,950
that you just want to
view this object instead

359
00:16:13,950 --> 00:16:17,670
of dialing the phone number
that's in the object, perhaps.

360
00:16:17,670 --> 00:16:20,500
And finally, the
data is basically

361
00:16:20,500 --> 00:16:24,540
an arbitrary URI
or URL for the data

362
00:16:24,540 --> 00:16:28,630
that you want to send
along with this message.

363
00:16:28,630 --> 00:16:32,600
So it could be something like
a telephone, colon, some digits

364
00:16:32,600 --> 00:16:34,215
to dial the phone number.

365
00:16:34,215 --> 00:16:40,245
It could be an actual HTTP URL
that you want to view or open.

366
00:16:40,245 --> 00:16:42,070
It might be any
other applications

367
00:16:42,070 --> 00:16:44,725
you find URI as well.

368
00:16:44,725 --> 00:16:47,080
So this is how you
send these messages.

369
00:16:47,080 --> 00:16:50,150
And the way these
messages are actually

370
00:16:50,150 --> 00:16:55,120
routed through the system is
with the help of the Android

371
00:16:55,120 --> 00:16:57,650
runtime itself that
sits underneath all

372
00:16:57,650 --> 00:16:59,320
these applications.

373
00:16:59,320 --> 00:17:02,070
So you can think of
the Android runtime

374
00:17:02,070 --> 00:17:06,500
as being somewhere between the
applications and the kernel.

375
00:17:06,500 --> 00:17:08,069
It's not quite
correct, but maybe

376
00:17:08,069 --> 00:17:11,220
let's try to draw some
picture to clarify

377
00:17:11,220 --> 00:17:14,750
what the architecture of
this thing looks like.

378
00:17:14,750 --> 00:17:20,400
So you have one application
that's running on Android.

379
00:17:20,400 --> 00:17:23,079
Perhaps you have
another application.

380
00:17:23,079 --> 00:17:24,920
These are all boxes
that are basically

381
00:17:24,920 --> 00:17:27,800
these guys-- a
separate application

382
00:17:27,800 --> 00:17:29,880
with a bunch of
components internally.

383
00:17:29,880 --> 00:17:32,720
Of course, these guys
are all processes running

384
00:17:32,720 --> 00:17:36,352
on top of the Linux kernel.

385
00:17:36,352 --> 00:17:38,185
So that's providing
some degree of isolation

386
00:17:38,185 --> 00:17:39,840
between the applications.

387
00:17:39,840 --> 00:17:45,100
And then there's what the paper
calls the reference monitor.

388
00:17:45,100 --> 00:17:47,440
And this guy is
going to mediate all

389
00:17:47,440 --> 00:17:51,650
the intent-level interactions
between the different apps

390
00:17:51,650 --> 00:17:52,150
here.

391
00:17:52,150 --> 00:17:55,920
So if App 1 wants to
send a message to App 2,

392
00:17:55,920 --> 00:17:58,600
they actually are going to
send a message to the reference

393
00:17:58,600 --> 00:17:59,842
monitor first.

394
00:17:59,842 --> 00:18:01,800
So this is how you send
all intents in Android,

395
00:18:01,800 --> 00:18:04,440
is that you create one
of these intent messages.

396
00:18:04,440 --> 00:18:08,400
And you basically send it over
some pipe to this reference

397
00:18:08,400 --> 00:18:09,335
monitor.

398
00:18:09,335 --> 00:18:11,590
So Android basically has
its own implementation

399
00:18:11,590 --> 00:18:16,010
of pipes for sending these
kinds of intents, called binder.

400
00:18:16,010 --> 00:18:19,020
And every Android
application, by convention,

401
00:18:19,020 --> 00:18:22,460
is going to open a
binder connection over

402
00:18:22,460 --> 00:18:24,580
to the reference monitor,
so the reference monitor

403
00:18:24,580 --> 00:18:27,040
can get intents from
this application

404
00:18:27,040 --> 00:18:30,050
as well as send messages
over to this application.

405
00:18:30,050 --> 00:18:35,110
So in our case, if App 1
writes an intent for App 2

406
00:18:35,110 --> 00:18:37,120
to the reference monitor,
the reference monitor

407
00:18:37,120 --> 00:18:40,790
is going to figure out where
this intent should go and relay

408
00:18:40,790 --> 00:18:43,540
it over here to App 2.

409
00:18:43,540 --> 00:18:47,320
So Application 2 can
maybe start an activity,

410
00:18:47,320 --> 00:18:52,365
or receive a message, or
do a SQL query, et cetera,

411
00:18:52,365 --> 00:18:53,727
for App 1.

412
00:18:53,727 --> 00:18:56,185
Does that make sense, roughly,
in terms of what's going on?

413
00:18:56,185 --> 00:18:57,155
Yeah, question.

414
00:18:57,155 --> 00:18:59,095
AUDIENCE: Does
the label checking

415
00:18:59,095 --> 00:19:00,550
happen once it gets to that,
or does the reference monitor?

416
00:19:00,550 --> 00:19:01,030
PROFESSOR: Ah, yeah, yeah, yeah.

417
00:19:01,030 --> 00:19:03,330
So the reference monitor,
hugely, importantly,

418
00:19:03,330 --> 00:19:07,650
is in charge of checking
all the permissions that are

419
00:19:07,650 --> 00:19:09,650
represented by these labels.

420
00:19:09,650 --> 00:19:12,310
So you could imagine
different things

421
00:19:12,310 --> 00:19:16,150
going on in terms of
checking the permissions

422
00:19:16,150 --> 00:19:18,890
in the apps themselves.

423
00:19:18,890 --> 00:19:21,830
So why do these guys
actually do the checking

424
00:19:21,830 --> 00:19:26,002
in the reference monitor
instead of in the applications?

425
00:19:26,002 --> 00:19:28,085
Would it make sense to do
the checking in the app?

426
00:19:30,790 --> 00:19:35,479
Suppose we stuck the
label checks into App 1.

427
00:19:35,479 --> 00:19:36,520
Would that be reasonable?

428
00:19:36,520 --> 00:19:36,900
Yeah?

429
00:19:36,900 --> 00:19:38,699
AUDIENCE: Well, that
seems like a bad idea,

430
00:19:38,699 --> 00:19:41,537
because if someone
compromises the [INAUDIBLE]

431
00:19:41,537 --> 00:19:45,684
and is able to its behavior
and get past the checking.

432
00:19:45,684 --> 00:19:46,350
PROFESSOR: Yeah.

433
00:19:46,350 --> 00:19:46,620
Right.

434
00:19:46,620 --> 00:19:48,770
So you probably don't want
to stick it in the sender,

435
00:19:48,770 --> 00:19:50,350
because you don't really
want to trust the sender.

436
00:19:50,350 --> 00:19:52,558
So if you install a particular
malicious application,

437
00:19:52,558 --> 00:19:54,320
if you want to be
able to handle,

438
00:19:54,320 --> 00:19:55,860
that application
isn't going to be

439
00:19:55,860 --> 00:19:58,925
guaranteed to do the
correct checks for us.

440
00:19:58,925 --> 00:20:00,600
So that seems a
little unfortunate.

441
00:20:00,600 --> 00:20:04,740
So we're not allowed to do
the checks on the sender site.

442
00:20:04,740 --> 00:20:09,350
What about doing the checks
on the receive side in App 2?

443
00:20:09,350 --> 00:20:11,220
What about that?

444
00:20:11,220 --> 00:20:12,110
Yeah?

445
00:20:12,110 --> 00:20:14,359
AUDIENCE: You could, but
it would need crypto,

446
00:20:14,359 --> 00:20:15,400
and you would need a PKI.

447
00:20:15,400 --> 00:20:17,007
So it would be much
more [INAUDIBLE].

448
00:20:17,007 --> 00:20:17,590
PROFESSOR: OK.

449
00:20:17,590 --> 00:20:19,970
So you're thinking this would
have to be crypto and have

450
00:20:19,970 --> 00:20:21,510
to have a PKI involved.

451
00:20:21,510 --> 00:20:23,740
So I'm not sure you
have to have crypto,

452
00:20:23,740 --> 00:20:26,880
because the kernel can tell
you exactly where things

453
00:20:26,880 --> 00:20:27,736
are coming from.

454
00:20:27,736 --> 00:20:30,670
So you could still have the
reference monitor telling you,

455
00:20:30,670 --> 00:20:32,260
oh, this is coming from App 1.

456
00:20:32,260 --> 00:20:34,914
So you don't really need
the PKI in that sense.

457
00:20:34,914 --> 00:20:36,455
It doesn't have to
be crypto-related.

458
00:20:36,455 --> 00:20:37,825
I think you need
crypto generally

459
00:20:37,825 --> 00:20:40,241
when you're talking over the
network, when there's nothing

460
00:20:40,241 --> 00:20:41,690
common that you can trust.

461
00:20:41,690 --> 00:20:44,736
Here, I think it's not
so much about crypto.

462
00:20:44,736 --> 00:20:47,299
Any other reasons why you
would actually maybe want it

463
00:20:47,299 --> 00:20:47,998
in that reference monitor?

464
00:20:47,998 --> 00:20:48,464
Yeah?

465
00:20:48,464 --> 00:20:49,706
AUDIENCE: You might want
to shift the burden away

466
00:20:49,706 --> 00:20:51,289
from the developer,
who ends up making

467
00:20:51,289 --> 00:20:52,772
a lot of mistakes [INAUDIBLE].

468
00:20:52,772 --> 00:20:53,480
PROFESSOR: Right.

469
00:20:53,480 --> 00:20:55,650
I think a huge part
of it is app bugs.

470
00:20:55,650 --> 00:20:57,910
If you don't really
want silly bugs

471
00:20:57,910 --> 00:20:59,630
that the application
developer makes

472
00:20:59,630 --> 00:21:01,070
to compromise the security.

473
00:21:01,070 --> 00:21:02,610
So to the extent
possible, I think

474
00:21:02,610 --> 00:21:05,930
you want to factor out common
functionality into code

475
00:21:05,930 --> 00:21:09,260
that the developer doesn't
have to worry about so much,

476
00:21:09,260 --> 00:21:11,960
or doesn't even have a
chance of screwing up.

477
00:21:11,960 --> 00:21:14,280
So this seems like partially
a good reason for sticking

478
00:21:14,280 --> 00:21:15,100
to the reference monitor.

479
00:21:15,100 --> 00:21:15,520
Yeah?

480
00:21:15,520 --> 00:21:17,103
AUDIENCE: It could
also be because you

481
00:21:17,103 --> 00:21:20,400
want to minimize the trusted
surface of the entire system.

482
00:21:20,400 --> 00:21:22,490
So you want to make the
reference monitor so small

483
00:21:22,490 --> 00:21:24,531
that it can actually be
[? orbited ?] on its own,

484
00:21:24,531 --> 00:21:27,340
or have some component that
deals with the actual label

485
00:21:27,340 --> 00:21:29,072
checking that can be
checked on its own.

486
00:21:29,072 --> 00:21:29,780
PROFESSOR: Right.

487
00:21:29,780 --> 00:21:29,796
Yeah.

488
00:21:29,796 --> 00:21:31,680
So that seems like a
financially reasonable plan

489
00:21:31,680 --> 00:21:33,480
as well, because the
security of the role system

490
00:21:33,480 --> 00:21:35,100
depends on the reference
monitor being correct.

491
00:21:35,100 --> 00:21:36,850
Well, you could see
this going either way.

492
00:21:36,850 --> 00:21:39,058
Actually putting the logic
into the reference monitor

493
00:21:39,058 --> 00:21:40,670
makes the reference
monitor bigger.

494
00:21:40,670 --> 00:21:42,890
So you could make the
RM smaller by delegating

495
00:21:42,890 --> 00:21:44,460
some work to the apps.

496
00:21:44,460 --> 00:21:46,751
Although, then there is some
library you have to audit.

497
00:21:46,751 --> 00:21:48,990
So it's not exactly clear.

498
00:21:48,990 --> 00:21:51,489
I think the one other
example I came up

499
00:21:51,489 --> 00:21:54,030
with for why to do this-- well,
I guess there was two things.

500
00:21:54,030 --> 00:21:54,790
One is just simplicity.

501
00:21:54,790 --> 00:21:56,290
I think it's easier
to do the checks

502
00:21:56,290 --> 00:21:59,420
all in one place in many ways.

503
00:21:59,420 --> 00:22:02,005
So you can sort of-- as you were
saying, that you could really

504
00:22:02,005 --> 00:22:04,380
look at this and say, oh, yup,
the checks are being done.

505
00:22:04,380 --> 00:22:06,510
They're always being
done on every message.

506
00:22:06,510 --> 00:22:10,090
So that's convincing or good
from a software engineering

507
00:22:10,090 --> 00:22:11,480
perspective, perhaps.

508
00:22:11,480 --> 00:22:13,620
Another thing is
that these intents

509
00:22:13,620 --> 00:22:17,010
have two addressing modes.

510
00:22:17,010 --> 00:22:18,440
In particular, in
the paper, they

511
00:22:18,440 --> 00:22:22,225
describe what are called
implicit and explicit intents.

512
00:22:22,225 --> 00:22:24,980
So explicit intents
are ones where

513
00:22:24,980 --> 00:22:26,210
you specify some component.

514
00:22:26,210 --> 00:22:27,730
And you actually
say it has to go

515
00:22:27,730 --> 00:22:29,920
to this particular component.

516
00:22:29,920 --> 00:22:32,994
So for these explicit intents,
it's actually totally fine

517
00:22:32,994 --> 00:22:34,660
to do the checking
on the receiver side,

518
00:22:34,660 --> 00:22:36,780
because well, you know where
you're going to send it.

519
00:22:36,780 --> 00:22:37,696
You can send it there.

520
00:22:37,696 --> 00:22:40,450
And if it doesn't want to
allow you to send the message,

521
00:22:40,450 --> 00:22:43,350
it'll drop it on the floor
or reject it somehow.

522
00:22:43,350 --> 00:22:45,770
But then there's also
implicit intents in Android,

523
00:22:45,770 --> 00:22:48,590
where you don't
know, as a sender,

524
00:22:48,590 --> 00:22:52,420
exactly which application you
want to receive your message.

525
00:22:52,420 --> 00:22:55,140
So this might happen if you
just want to view a picture

526
00:22:55,140 --> 00:22:56,985
or you want to dial
a phone number,

527
00:22:56,985 --> 00:22:58,610
but you don't actually
know which phone

528
00:22:58,610 --> 00:23:00,430
dialer the user has installed.

529
00:23:00,430 --> 00:23:03,735
Maybe it has a Google Voice,
Voice-over IP dialer, or Skype,

530
00:23:03,735 --> 00:23:05,630
or who knows what.

531
00:23:05,630 --> 00:23:07,990
So in those case, these
implicit intents actually

532
00:23:07,990 --> 00:23:09,910
skip the component
name and just say,

533
00:23:09,910 --> 00:23:12,860
I want this action to be
handled with this data

534
00:23:12,860 --> 00:23:15,170
by some application out there.

535
00:23:15,170 --> 00:23:17,870
And in this case, it's the
job of the reference monitor

536
00:23:17,870 --> 00:23:20,450
to find an application
that's suitable for handling

537
00:23:20,450 --> 00:23:23,040
that kind of message--
dialing a phone number,

538
00:23:23,040 --> 00:23:26,556
viewing a PDF, or a JPEG
image, or what have you.

539
00:23:26,556 --> 00:23:28,180
And in that case,
the reference monitor

540
00:23:28,180 --> 00:23:30,480
can actually take
permissions into account

541
00:23:30,480 --> 00:23:33,160
when choosing a
suitable application.

542
00:23:33,160 --> 00:23:36,844
So it might be that there are
some very sensitive PDF viewer

543
00:23:36,844 --> 00:23:38,510
application you have
installed, and it's

544
00:23:38,510 --> 00:23:40,550
capable of viewing
PDFs, but you don't want

545
00:23:40,550 --> 00:23:42,180
it accessible to most apps.

546
00:23:42,180 --> 00:23:44,970
So maybe the permissions on it
don't allow that application

547
00:23:44,970 --> 00:23:49,000
to receive PDF View messages
from the rest of the system.

548
00:23:49,000 --> 00:23:51,580
So in this case, the reference
monitor will look at this

549
00:23:51,580 --> 00:23:52,390
and say, well,
you're not allowed

550
00:23:52,390 --> 00:23:54,640
to send your request there,
but maybe another application

551
00:23:54,640 --> 00:23:56,080
is willing to
handle your request.

552
00:23:56,080 --> 00:23:59,010
So this sort of simplifies
the user interface or user

553
00:23:59,010 --> 00:24:03,680
interaction here by matching
an available system,

554
00:24:03,680 --> 00:24:06,420
including and considering
the permissions that

555
00:24:06,420 --> 00:24:08,495
are available to the sender.

556
00:24:08,495 --> 00:24:09,850
That make sense?

557
00:24:09,850 --> 00:24:11,730
Does that make sense?

558
00:24:11,730 --> 00:24:14,047
Any questions?

559
00:24:14,047 --> 00:24:15,045
Yeah.

560
00:24:15,045 --> 00:24:18,039
AUDIENCE: Would the reference
monitor ever be a bottleneck?

561
00:24:18,039 --> 00:24:19,260
PROFESSOR: It could be, yeah.

562
00:24:19,260 --> 00:24:21,990
So a lot of these messages
are sent through the reference

563
00:24:21,990 --> 00:24:22,520
monitor.

564
00:24:22,520 --> 00:24:25,870
And I don't know whether it's
actually currently multi-thread

565
00:24:25,870 --> 00:24:26,450
or not.

566
00:24:26,450 --> 00:24:28,116
You probably could
make it multi-thread.

567
00:24:28,116 --> 00:24:29,830
I think the logic
it's implementing

568
00:24:29,830 --> 00:24:32,880
doesn't involve maintaining
a lot of shared state.

569
00:24:32,880 --> 00:24:35,260
So you could probably process
many of intent messages

570
00:24:35,260 --> 00:24:37,360
in parallel if need be.

571
00:24:37,360 --> 00:24:38,750
I suspect that
you could probably

572
00:24:38,750 --> 00:24:40,050
avoid it being a bottleneck.

573
00:24:40,050 --> 00:24:43,745
For bulk things, Android
has an RPC mechanism

574
00:24:43,745 --> 00:24:45,120
that the paper
talks about, where

575
00:24:45,120 --> 00:24:46,990
if you want to send
a lot of operations

576
00:24:46,990 --> 00:24:48,650
to another application,
you actually

577
00:24:48,650 --> 00:24:52,190
send what's called a bind
intent to the reference monitor,

578
00:24:52,190 --> 00:24:54,870
saying, I want a direct
connection to this application.

579
00:24:54,870 --> 00:24:57,150
And if you send a bind intent
to the reference monitor

580
00:24:57,150 --> 00:24:58,900
and it [? forwards the app ?]
to this app,

581
00:24:58,900 --> 00:25:02,291
then you're going to establish
this sort of bound channel

582
00:25:02,291 --> 00:25:03,790
between these two
apps and then send

583
00:25:03,790 --> 00:25:05,950
lots of messages
directly [INAUDIBLE].

584
00:25:05,950 --> 00:25:08,410
So if some
application is worried

585
00:25:08,410 --> 00:25:10,470
about an interface which
is performance-critical,

586
00:25:10,470 --> 00:25:12,580
they'll probably do this.

587
00:25:12,580 --> 00:25:13,862
Yeah, question?

588
00:25:13,862 --> 00:25:15,826
AUDIENCE: Why does
the [INAUDIBLE]?

589
00:25:15,826 --> 00:25:20,250
Because every single label
needs to match [INAUDIBLE].

590
00:25:20,250 --> 00:25:21,950
PROFESSOR: Ah.

591
00:25:21,950 --> 00:25:24,890
So here, it's not
the case that you get

592
00:25:24,890 --> 00:25:27,760
direct access inside of App 2.

593
00:25:27,760 --> 00:25:30,240
It's not that you can directly
manipulate all the stuff

594
00:25:30,240 --> 00:25:33,650
in the address space or
the objects of App 2.

595
00:25:33,650 --> 00:25:36,320
You just get a channel
that the other application

596
00:25:36,320 --> 00:25:39,670
is willing to look
at messages of

597
00:25:39,670 --> 00:25:43,540
and do something sensible
with these messages.

598
00:25:43,540 --> 00:25:47,560
So it's up to the Application 2
here to look at these messages

599
00:25:47,560 --> 00:25:49,080
and do something
sensible with them,

600
00:25:49,080 --> 00:25:52,850
not to allow arbitrary code
execution or arbitrary access.

601
00:25:52,850 --> 00:25:56,210
But in this application, I think
they have two operations where

602
00:25:56,210 --> 00:25:59,560
you can add a new friend or
enable or disable tracking

603
00:25:59,560 --> 00:26:01,140
through this interface.

604
00:26:01,140 --> 00:26:03,480
So there's well-defined
messages that you define.

605
00:26:03,480 --> 00:26:04,660
And you're going to
implement probably

606
00:26:04,660 --> 00:26:06,180
one of these [? surface ?]
components that's

607
00:26:06,180 --> 00:26:07,554
responsible for
taking a message,

608
00:26:07,554 --> 00:26:11,411
and checking that it's sensible,
and executing that operation.

609
00:26:11,411 --> 00:26:11,910
Question?

610
00:26:11,910 --> 00:26:14,860
AUDIENCE: Well, so
I guess intents are

611
00:26:14,860 --> 00:26:16,826
usually human-initiated, right?

612
00:26:16,826 --> 00:26:18,326
PROFESSOR: Oftentimes yeah.

613
00:26:18,326 --> 00:26:18,950
AUDIENCE: Yeah.

614
00:26:18,950 --> 00:26:20,330
And humans are pretty slow.

615
00:26:20,330 --> 00:26:22,960
So it's unlikely that the
reference monitor is going

616
00:26:22,960 --> 00:26:24,169
to be any kind of bottleneck.

617
00:26:24,169 --> 00:26:25,709
PROFESSOR: Yes,
that's probably true.

618
00:26:25,709 --> 00:26:26,520
Yeah.

619
00:26:26,520 --> 00:26:29,141
It depends on exactly, yeah, I
guess how you're using intents.

620
00:26:29,141 --> 00:26:30,390
It's a little bit of a bummer.

621
00:26:30,390 --> 00:26:33,130
In the paper, they say
that the permissions

622
00:26:33,130 --> 00:26:35,711
add [? buying ?] time are
checked by the reference

623
00:26:35,711 --> 00:26:36,210
monitor.

624
00:26:36,210 --> 00:26:38,001
But the permissions on
individual RPC calls

625
00:26:38,001 --> 00:26:39,456
between these
applications are not

626
00:26:39,456 --> 00:26:40,830
checked by the
reference monitor,

627
00:26:40,830 --> 00:26:42,829
because you have this
direct channel between two

628
00:26:42,829 --> 00:26:44,110
applications.

629
00:26:44,110 --> 00:26:47,150
So presumably, actually,
I don't know exactly why

630
00:26:47,150 --> 00:26:48,530
they chose to do it this way.

631
00:26:48,530 --> 00:26:52,300
Perhaps it's to get away from
having a reference monitor be

632
00:26:52,300 --> 00:26:55,690
any kind of bottleneck for
[? handy ?] communication.

633
00:26:55,690 --> 00:27:00,050
But it means that the
permissions for individual RPC

634
00:27:00,050 --> 00:27:02,270
operations between
the applications

635
00:27:02,270 --> 00:27:04,920
have to be done in software
inside of the application

636
00:27:04,920 --> 00:27:08,805
logic, which is a little bit
unfortunate if we want to avoid

637
00:27:08,805 --> 00:27:11,370
the application developer
making these kinds of mistakes

638
00:27:11,370 --> 00:27:14,596
and maybe forgetting to check
the permissions on some RPC

639
00:27:14,596 --> 00:27:16,370
calls.

640
00:27:16,370 --> 00:27:18,835
So in some ways, if you are
purely worried about security,

641
00:27:18,835 --> 00:27:21,430
it might have been nicer
to forward all the RPCs

642
00:27:21,430 --> 00:27:23,690
through the reference
monitor as well,

643
00:27:23,690 --> 00:27:26,310
because then the reference
monitor is going to make sure

644
00:27:26,310 --> 00:27:29,040
that it checks permissions
on every RPC call

645
00:27:29,040 --> 00:27:31,560
instead of just at
the time you establish

646
00:27:31,560 --> 00:27:34,717
a channel for future RPC
calls between two apps.

647
00:27:34,717 --> 00:27:38,629
That make sense?

648
00:27:38,629 --> 00:27:39,840
All right.

649
00:27:39,840 --> 00:27:40,340
OK.

650
00:27:40,340 --> 00:27:44,025
So let's try to figure out-- one
interesting thing [? to do ?]

651
00:27:44,025 --> 00:27:48,670
to try to contrast is, why
did these guys-- before we

652
00:27:48,670 --> 00:27:50,170
dive into a little
bit more details,

653
00:27:50,170 --> 00:27:52,700
why did these guys
design a whole new app

654
00:27:52,700 --> 00:27:57,180
model for Android applications
as opposed to-- we've

655
00:27:57,180 --> 00:27:57,850
seen already.

656
00:27:57,850 --> 00:28:00,497
There's desktop applications,
there's web applications.

657
00:28:00,497 --> 00:28:02,205
Why did these guys
invent a whole new way

658
00:28:02,205 --> 00:28:03,300
of writing software?

659
00:28:03,300 --> 00:28:05,760
Because in some ways, this is
confusing for the developer,

660
00:28:05,760 --> 00:28:08,140
because I am used to
writing my nice little C

661
00:28:08,140 --> 00:28:09,727
program with a main function.

662
00:28:09,727 --> 00:28:11,560
I look at this and say,
well, what the hell?

663
00:28:11,560 --> 00:28:13,175
I mean, what am I
going to do with-- I

664
00:28:13,175 --> 00:28:14,790
have to define four
kinds of components,

665
00:28:14,790 --> 00:28:16,206
and I have to send
intents instead

666
00:28:16,206 --> 00:28:18,280
of just having a C
struct and writing

667
00:28:18,280 --> 00:28:20,520
[? straight line ?] code.

668
00:28:20,520 --> 00:28:24,390
So what are the pros or
cons of existing app models?

669
00:28:24,390 --> 00:28:33,140
So we have, I guess,
desktop apps and web apps.

670
00:28:33,140 --> 00:28:36,647
Why do we need a third
column, so to say?

671
00:28:36,647 --> 00:28:38,730
Because what are the nice
things about these guys?

672
00:28:38,730 --> 00:28:39,229
Yeah?

673
00:28:39,229 --> 00:28:41,940
AUDIENCE: Well, the model has
completely changed now, right?

674
00:28:41,940 --> 00:28:43,677
Because I think on
desktop apps, you

675
00:28:43,677 --> 00:28:45,510
don't put as much
trust in the developers

676
00:28:45,510 --> 00:28:48,460
as you put in mobile apps.

677
00:28:48,460 --> 00:28:51,810
And you have a bunch of
more users that are less

678
00:28:51,810 --> 00:28:54,902
[? inexperienced ?] than the
desktop users who end up having

679
00:28:54,902 --> 00:28:57,360
a bunch of apps that really
want to [? isolate ?] from each

680
00:28:57,360 --> 00:28:58,000
other.

681
00:28:58,000 --> 00:28:58,960
PROFESSOR: It could be.

682
00:28:58,960 --> 00:29:00,335
So you think in
the desktop case,

683
00:29:00,335 --> 00:29:02,251
we don't have to trust
the developers as much?

684
00:29:02,251 --> 00:29:03,430
AUDIENCE: Of course you do.

685
00:29:03,430 --> 00:29:07,256
But it seems that there's always
like your son or your cousin

686
00:29:07,256 --> 00:29:10,567
that you take care of their
desktop if it goes bad.

687
00:29:10,567 --> 00:29:11,513
PROFESSOR: [LAUGHS]

688
00:29:11,513 --> 00:29:12,657
AUDIENCE: But with
your phone, there's

689
00:29:12,657 --> 00:29:13,440
a different problem altogether.

690
00:29:13,440 --> 00:29:15,280
PROFESSOR: I guess it's cool
that the phones don't need

691
00:29:15,280 --> 00:29:16,560
a cousin to take care of them.

692
00:29:16,560 --> 00:29:18,954
So that's great, right?

693
00:29:18,954 --> 00:29:21,910
But in terms of security,
one thing on the desktop apps

694
00:29:21,910 --> 00:29:24,300
is that you can't
install-- or it's

695
00:29:24,300 --> 00:29:32,390
really hard to install
new apps or maybe-- well,

696
00:29:32,390 --> 00:29:36,360
probably not quite exactly
true, because you can always

697
00:29:36,360 --> 00:29:38,830
click an executable and install
an app on a desktop case.

698
00:29:38,830 --> 00:29:42,200
But I guess people don't install
apps regularly sort of tend to

699
00:29:42,200 --> 00:29:43,840
maybe-- because it
depends on the usage

700
00:29:43,840 --> 00:29:44,798
model of a desktop app.

701
00:29:44,798 --> 00:29:47,400
But typically, you have
a fixed set of software

702
00:29:47,400 --> 00:29:49,780
you are running as
opposed to on a web app,

703
00:29:49,780 --> 00:29:53,910
one cool thing is that it's
very easy to run new apps.

704
00:29:56,880 --> 00:29:59,405
You just visit a website,
and there's nothing really

705
00:29:59,405 --> 00:30:01,155
you have to do other
than click on a link.

706
00:30:01,155 --> 00:30:05,760
And off you are on some new site
running some new Application.

707
00:30:05,760 --> 00:30:07,705
So that's a pretty nice
property of web apps.

708
00:30:07,705 --> 00:30:11,120
One bummer about desktop
apps is that there's actually

709
00:30:11,120 --> 00:30:16,170
no isolation at all
between applications.

710
00:30:16,170 --> 00:30:18,266
That's perhaps somewhat
related to the fact

711
00:30:18,266 --> 00:30:19,640
that it's hard to
install an app,

712
00:30:19,640 --> 00:30:21,990
because you really
are trusting it

713
00:30:21,990 --> 00:30:23,820
fully with all the
data on your machine

714
00:30:23,820 --> 00:30:24,903
when you're installing it.

715
00:30:24,903 --> 00:30:27,150
There is no isolation
between one app

716
00:30:27,150 --> 00:30:30,096
that you install in your laptop
and probably any other thing

717
00:30:30,096 --> 00:30:31,470
running there, or
any of the data

718
00:30:31,470 --> 00:30:33,450
that you are storing
on that computer.

719
00:30:33,450 --> 00:30:35,410
Whereas in the web
app case, there's

720
00:30:35,410 --> 00:30:38,020
some reasonable isolation.

721
00:30:38,020 --> 00:30:41,489
As long as you believe the
same origin policy is correctly

722
00:30:41,489 --> 00:30:44,030
[INAUDIBLE] by the browser, then
you're in pretty good shape.

723
00:30:44,030 --> 00:30:47,100
It's reasonably safe to probably
go to some arbitrary website

724
00:30:47,100 --> 00:30:49,282
and start using
their application.

725
00:30:49,282 --> 00:30:51,240
It's not going to
tamper with other sites

726
00:30:51,240 --> 00:30:53,274
that you have open
in your browser,

727
00:30:53,274 --> 00:30:55,190
assuming they don't
exploit some browser bugs.

728
00:30:58,830 --> 00:31:01,980
So far, it looks like the web
apps are the winning plan.

729
00:31:01,980 --> 00:31:04,410
They're easy to use,
they have isolation.

730
00:31:04,410 --> 00:31:07,651
Why don't these guys use
web apps for Android?

731
00:31:07,651 --> 00:31:08,150
Yeah?

732
00:31:08,150 --> 00:31:09,820
AUDIENCE: So web
apps are starting

733
00:31:09,820 --> 00:31:12,280
to become like an operating
system in themselves, right?

734
00:31:12,280 --> 00:31:18,480
So you have Firefox OX, which is
basically just a web mobile OS.

735
00:31:18,480 --> 00:31:19,450
PROFESSOR: Right.

736
00:31:19,450 --> 00:31:19,950
OK.

737
00:31:19,950 --> 00:31:22,324
So you're arguing that actually
these guys were mistaken.

738
00:31:22,324 --> 00:31:24,840
They shouldn't have built
a new Android stack.

739
00:31:24,840 --> 00:31:28,100
They should have just
done a giant web browser

740
00:31:28,100 --> 00:31:29,750
as your phone.

741
00:31:29,750 --> 00:31:32,843
AUDIENCE: Well, at least Mozilla
has shown that it's possible.

742
00:31:32,843 --> 00:31:33,551
PROFESSOR: Right.

743
00:31:33,551 --> 00:31:35,443
OK, fair enough.

744
00:31:35,443 --> 00:31:38,030
So it's at least more reasonable
to go with the web apps

745
00:31:38,030 --> 00:31:41,190
route rather than the desktop
route, at least for phone.

746
00:31:41,190 --> 00:31:41,690
Yeah?

747
00:31:41,690 --> 00:31:45,458
AUDIENCE: [INAUDIBLE]
phone call from a web apps,

748
00:31:45,458 --> 00:31:48,519
you need [? an entire new ?]
API for the web app interface

749
00:31:48,519 --> 00:31:49,342
with the phone.

750
00:31:49,342 --> 00:31:50,050
PROFESSOR: Right.

751
00:31:50,050 --> 00:31:53,746
So the one limitation that
might be fixable, of course,

752
00:31:53,746 --> 00:31:58,922
but is still there
is maybe there's

753
00:31:58,922 --> 00:32:03,200
no APIs for some of the devices.

754
00:32:03,200 --> 00:32:04,970
This is increasingly
becoming less so.

755
00:32:04,970 --> 00:32:08,270
Like, for a camera or for
a GPS, these are slowly

756
00:32:08,270 --> 00:32:10,090
being added to the web case.

757
00:32:10,090 --> 00:32:12,170
But there is probably
not quite an API

758
00:32:12,170 --> 00:32:15,360
for accessing your phone
yet, or sending an SMS

759
00:32:15,360 --> 00:32:18,450
message, and things like that.

760
00:32:18,450 --> 00:32:22,000
Another bummer in web apps
is there is actually limited

761
00:32:22,000 --> 00:32:24,490
sharing that you can do.

762
00:32:24,490 --> 00:32:27,029
So we were just talking
about implicit intents

763
00:32:27,029 --> 00:32:28,820
in Android, where you
could just say, well,

764
00:32:28,820 --> 00:32:30,197
I want to view
this JPEG picture,

765
00:32:30,197 --> 00:32:32,280
but who knows what
application's going to open it?

766
00:32:32,280 --> 00:32:34,020
Or I want to view this PDF file.

767
00:32:34,020 --> 00:32:36,235
Or I want to share
this picture I just

768
00:32:36,235 --> 00:32:38,530
took with my camera with
a friend through email,

769
00:32:38,530 --> 00:32:40,860
but I don't know what email
application you're using.

770
00:32:40,860 --> 00:32:43,390
Let's just ask the
reference monitor

771
00:32:43,390 --> 00:32:45,722
to find me some
email program that's

772
00:32:45,722 --> 00:32:47,460
going to send this picture out.

773
00:32:47,460 --> 00:32:49,501
So it's something you can
actually do in Android.

774
00:32:49,501 --> 00:32:51,697
But it's kind of hard
to do in a web app case,

775
00:32:51,697 --> 00:32:53,155
because every
interaction, you have

776
00:32:53,155 --> 00:32:55,110
to refer to a particular URL.

777
00:32:55,110 --> 00:32:57,730
So if you don't know what
PDF viewer someone is using,

778
00:32:57,730 --> 00:33:01,110
you might not know
what URL to open

779
00:33:01,110 --> 00:33:05,583
to ask it to view the PDF
[? potentially. ?] Question?

780
00:33:05,583 --> 00:33:08,068
AUDIENCE: [INAUDIBLE].

781
00:33:08,068 --> 00:33:11,384
But JavaScript is very
hard to read [INAUDIBLE].

782
00:33:11,384 --> 00:33:12,050
PROFESSOR: Yeah.

783
00:33:12,050 --> 00:33:16,160
So one bummer is that yeah,
this is all JavaScript. [LAUGHS]

784
00:33:16,160 --> 00:33:17,775
So it's potentially unfortunate.

785
00:33:17,775 --> 00:33:20,640
But it's maybe not as good
in terms of performance.

786
00:33:20,640 --> 00:33:24,440
Maybe it's hard to
understand what it's doing.

787
00:33:24,440 --> 00:33:29,894
It might be hard to compile
efficiently, et cetera.

788
00:33:29,894 --> 00:33:31,286
Yeah.

789
00:33:31,286 --> 00:33:33,610
Because one nice thing about
the desktop [INAUDIBLE]

790
00:33:33,610 --> 00:33:36,250
is that sharing is easy.

791
00:33:36,250 --> 00:33:39,990
So one side effect of having
all your files be accessible

792
00:33:39,990 --> 00:33:42,810
in every app is that,
well, you just share.

793
00:33:42,810 --> 00:33:45,330
It's very easy to access
any data you have.

794
00:33:45,330 --> 00:33:48,525
And in some ways, if you
really want a lot of sharing,

795
00:33:48,525 --> 00:33:49,390
this is great.

796
00:33:49,390 --> 00:33:52,532
Like, I probably could-- it
might be a little bit tricky

797
00:33:52,532 --> 00:33:54,365
to implement some things
on Android that are

798
00:33:54,365 --> 00:33:55,830
easy to do in the desktop case.

799
00:33:55,830 --> 00:33:56,810
So in the desktop
case, if I want

800
00:33:56,810 --> 00:33:59,310
to compile a piece of software,
I'm going to run [? Make. ?]

801
00:33:59,310 --> 00:34:04,030
That's going to run GCC
and maybe other programs.

802
00:34:04,030 --> 00:34:06,520
And they're all collaborating
on the same C source

803
00:34:06,520 --> 00:34:08,090
code in the single directory.

804
00:34:08,090 --> 00:34:09,746
They're all building it.

805
00:34:09,746 --> 00:34:11,120
It might be a
little bit trickier

806
00:34:11,120 --> 00:34:14,969
to do in the Android case,
where data is kind of associated

807
00:34:14,969 --> 00:34:17,077
with a primary
application, but storing it

808
00:34:17,077 --> 00:34:18,884
in a [? quantum ?] provider.

809
00:34:18,884 --> 00:34:20,300
So it might be a
little bit tricky

810
00:34:20,300 --> 00:34:23,650
to have an Android world where
I have my source code stored

811
00:34:23,650 --> 00:34:25,600
somewhere, and then I
install a C compiler,

812
00:34:25,600 --> 00:34:28,865
and [? a Make ?] program, and
an assembler, and other things.

813
00:34:28,865 --> 00:34:30,380
And they all sort
of work together.

814
00:34:30,380 --> 00:34:32,111
It's a little bit harder to do.

815
00:34:32,111 --> 00:34:34,035
You probably could
do it somehow.

816
00:34:34,035 --> 00:34:37,114
AUDIENCE: [INAUDIBLE].

817
00:34:37,114 --> 00:34:37,780
PROFESSOR: Yeah.

818
00:34:37,780 --> 00:34:40,159
So you could probably work
around it in some ways.

819
00:34:40,159 --> 00:34:42,580
So I think Android is certainly
general purpose enough

820
00:34:42,580 --> 00:34:44,989
to let you somehow do it.

821
00:34:44,989 --> 00:34:49,150
But it's probably not quite as
natural to do this in Android

822
00:34:49,150 --> 00:34:51,480
as it would be in
a desktop case.

823
00:34:51,480 --> 00:34:53,090
Not that I'm arguing
the desktop case.

824
00:34:53,090 --> 00:34:54,840
But it's not quite as secure.

825
00:34:54,840 --> 00:34:56,169
But yeah.

826
00:34:56,169 --> 00:34:56,960
Any other comments?

827
00:34:56,960 --> 00:34:57,846
Yeah?

828
00:34:57,846 --> 00:35:00,693
AUDIENCE: Another
thing might be the case

829
00:35:00,693 --> 00:35:02,680
that we're optimizing
for different web

830
00:35:02,680 --> 00:35:05,772
apps [INAUDIBLE] constrained.

831
00:35:05,772 --> 00:35:08,718
I'm not sure what [INAUDIBLE]
tend to be constrained by.

832
00:35:08,718 --> 00:35:10,682
But [? web apps ?]
tend to be constrained

833
00:35:10,682 --> 00:35:13,137
by both RAM and processing.

834
00:35:13,137 --> 00:35:16,279
And much more so than either
desktop or web apps, certainly.

835
00:35:16,279 --> 00:35:16,945
PROFESSOR: Yeah.

836
00:35:16,945 --> 00:35:19,230
So it might be that solid
engineering decisions

837
00:35:19,230 --> 00:35:21,067
around how to
optimize these things

838
00:35:21,067 --> 00:35:22,150
are going to be different.

839
00:35:22,150 --> 00:35:23,905
I guess one unfortunate
thing about web apps,

840
00:35:23,905 --> 00:35:26,196
at least at the time these
guys were designing Android,

841
00:35:26,196 --> 00:35:28,600
is that it was difficult
to run a web app offline.

842
00:35:28,600 --> 00:35:32,560
If your phone doesn't have
strong enough cellphone

843
00:35:32,560 --> 00:35:35,535
reception, then it might be hard
for you to run the application

844
00:35:35,535 --> 00:35:37,780
if some parts of it
fell out of the cache.

845
00:35:37,780 --> 00:35:39,935
I think slowly, as
you were pointing out,

846
00:35:39,935 --> 00:35:42,400
the web app world is
catching up to Android.

847
00:35:42,400 --> 00:35:44,780
But many of these
limitations are getting

848
00:35:44,780 --> 00:35:48,620
fixed or sort of improved.

849
00:35:48,620 --> 00:35:50,857
So it might be that
these days, web

850
00:35:50,857 --> 00:35:53,950
apps are a reasonable model for
starting a new phone platform.

851
00:35:53,950 --> 00:35:56,310
But five years ago,
this Android world

852
00:35:56,310 --> 00:35:59,800
was necessary, because the
web apps weren't quite there.

853
00:35:59,800 --> 00:36:03,230
Probably not quite there
still yet, but nowadays,

854
00:36:03,230 --> 00:36:05,310
it might be easier
to push the web apps

855
00:36:05,310 --> 00:36:10,300
all the way to where Android is
rather than start from scratch.

856
00:36:10,300 --> 00:36:11,240
All right.

857
00:36:11,240 --> 00:36:17,190
So I guess we can still
talk about what Android

858
00:36:17,190 --> 00:36:19,716
did even though maybe
today you wouldn't

859
00:36:19,716 --> 00:36:21,720
have done it the same way.

860
00:36:21,720 --> 00:36:24,275
But I guess in
terms of isolation,

861
00:36:24,275 --> 00:36:28,600
we can start talking maybe about
security a little bit more.

862
00:36:28,600 --> 00:36:30,125
Android relies on
the Linux kernel,

863
00:36:30,125 --> 00:36:33,540
as I mentioned, to isolate
these apps from one another.

864
00:36:33,540 --> 00:36:38,330
So what happens is that the
Android framework actually

865
00:36:38,330 --> 00:36:45,230
sets user IDs so that this
application has perhaps

866
00:36:45,230 --> 00:36:47,270
UID 1,001.

867
00:36:47,270 --> 00:36:49,930
This application
runs as UID 1,002.

868
00:36:49,930 --> 00:36:53,990
And the reference monitor
is basically [INAUDIBLE].

869
00:36:53,990 --> 00:36:55,860
So I think it
might run as UID 0,

870
00:36:55,860 --> 00:36:57,840
although I forget the detail.

871
00:36:57,840 --> 00:37:01,860
But I think it does run
as UID 0 on Android.

872
00:37:01,860 --> 00:37:04,330
So the Linux kernel is largely
responsible for keeping

873
00:37:04,330 --> 00:37:08,030
the apps separate
from one another.

874
00:37:08,030 --> 00:37:10,740
And mostly, interactions
between user IDs

875
00:37:10,740 --> 00:37:13,172
happens through these intents.

876
00:37:13,172 --> 00:37:15,630
And then there's a little bit
of details in terms of things

877
00:37:15,630 --> 00:37:17,420
that the Linux kernel
actually enforces

878
00:37:17,420 --> 00:37:22,220
in terms of which UID is allowed
to do which operation as well.

879
00:37:22,220 --> 00:37:24,592
So we'll talk about
that in a second.

880
00:37:24,592 --> 00:37:28,820
One interesting question is
why did these guys choose Java?

881
00:37:28,820 --> 00:37:32,640
Like, what's the role
of Java in Android?

882
00:37:32,640 --> 00:37:36,199
Why is Java there at all?

883
00:37:36,199 --> 00:37:37,240
Is it enforcing anything?

884
00:37:37,240 --> 00:37:37,720
Yeah.

885
00:37:37,720 --> 00:37:39,803
AUDIENCE: I think it
enforces [? text messaging ?]

886
00:37:39,803 --> 00:37:40,942
and [? downstreaming. ?]

887
00:37:40,942 --> 00:37:41,650
PROFESSOR: Right.

888
00:37:41,650 --> 00:37:42,150
OK.

889
00:37:42,150 --> 00:37:43,460
So what do we get out of it?

890
00:37:43,460 --> 00:37:45,533
Is it like for security,
for probability?

891
00:37:50,394 --> 00:37:52,560
One other way to think of
it is suppose we took away

892
00:37:52,560 --> 00:37:55,446
Java and made all the
apps written in C,

893
00:37:55,446 --> 00:37:57,320
or, like, Assembly, or
don't require anything

894
00:37:57,320 --> 00:37:58,430
at all for that matter.

895
00:37:58,430 --> 00:37:59,753
Would anything break?

896
00:37:59,753 --> 00:38:00,253
Yeah.

897
00:38:00,253 --> 00:38:02,185
AUDIENCE: You have
vulnerabilities [INAUDIBLE]

898
00:38:02,185 --> 00:38:03,851
override these important values.

899
00:38:03,851 --> 00:38:04,600
PROFESSOR: Uh-huh.

900
00:38:04,600 --> 00:38:05,790
Yeah, it could be.

901
00:38:05,790 --> 00:38:08,880
So like an app could have
some buffer overflow in it.

902
00:38:08,880 --> 00:38:11,219
So how bad would that be?

903
00:38:11,219 --> 00:38:13,690
AUDIENCE: It could
override with permissions.

904
00:38:13,690 --> 00:38:15,700
PROFESSOR: Which permissions?

905
00:38:15,700 --> 00:38:17,694
AUDIENCE: Like the latency.

906
00:38:17,694 --> 00:38:18,360
PROFESSOR: Yeah.

907
00:38:18,360 --> 00:38:19,520
Well, actually, let's see.

908
00:38:19,520 --> 00:38:22,220
So as we were talking
about, the reference monitor

909
00:38:22,220 --> 00:38:25,100
is the thing that does all
the label checking for us.

910
00:38:25,100 --> 00:38:26,650
And the reference
monitor actually,

911
00:38:26,650 --> 00:38:31,220
in Android, stores a list of
all the installed applications

912
00:38:31,220 --> 00:38:33,730
along with the labels
that correspond

913
00:38:33,730 --> 00:38:35,810
to all those applications.

914
00:38:35,810 --> 00:38:37,310
So it's probably
true that you don't

915
00:38:37,310 --> 00:38:40,270
want any kinds of bugs
in the reference monitor

916
00:38:40,270 --> 00:38:42,549
regardless of what
language it's written in.

917
00:38:42,549 --> 00:38:44,090
So having the
reference monitor being

918
00:38:44,090 --> 00:38:45,881
written in a type-safe
language is probably

919
00:38:45,881 --> 00:38:46,930
a good thing in general.

920
00:38:46,930 --> 00:38:48,400
And I like Java.

921
00:38:48,400 --> 00:38:50,850
I can sense that it's
a type-safe language

922
00:38:50,850 --> 00:38:53,000
and has all these
nice properties.

923
00:38:53,000 --> 00:38:55,320
But if an application
were to be written in C

924
00:38:55,320 --> 00:38:57,170
and had a buffer
overflow, it wouldn't

925
00:38:57,170 --> 00:39:00,050
be able to corrupt directly the
labels stored in the reference

926
00:39:00,050 --> 00:39:01,150
monitor here.

927
00:39:01,150 --> 00:39:03,860
So that wouldn't be
as big of a deal.

928
00:39:03,860 --> 00:39:04,360
Yeah.

929
00:39:04,360 --> 00:39:05,296
AUDIENCE: [INAUDIBLE].

930
00:39:08,110 --> 00:39:09,800
PROFESSOR: It could be.

931
00:39:09,800 --> 00:39:12,190
So why would that be helpful?

932
00:39:12,190 --> 00:39:15,950
AUDIENCE: There's some
system [INAUDIBLE] that it

933
00:39:15,950 --> 00:39:18,574
can actually override C?

934
00:39:18,574 --> 00:39:19,240
PROFESSOR: Yeah.

935
00:39:19,240 --> 00:39:21,276
So in principle, it
might be nice to avoid

936
00:39:21,276 --> 00:39:23,130
the applications talking
directly to the Linux kernel.

937
00:39:23,130 --> 00:39:25,004
[INAUDIBLE] in Android,
this is not the case.

938
00:39:25,004 --> 00:39:26,690
So actually,
Android applications

939
00:39:26,690 --> 00:39:29,890
can make arbitrary system
calls if they want to.

940
00:39:29,890 --> 00:39:31,520
And in fact,
applications I should say

941
00:39:31,520 --> 00:39:33,480
can shift with
arbitrary components

942
00:39:33,480 --> 00:39:35,870
written in C or Assembly
for performance reasons.

943
00:39:35,870 --> 00:39:39,200
So some games [? shift ?] with
the computationally intensive

944
00:39:39,200 --> 00:39:41,050
parts written in
C. And they sort of

945
00:39:41,050 --> 00:39:44,254
talk to it from Java as well.

946
00:39:44,254 --> 00:39:45,844
AUDIENCE: So I
guess part of it is

947
00:39:45,844 --> 00:39:47,902
being able to use all
of the stuff that's

948
00:39:47,902 --> 00:39:49,710
been written for Java.

949
00:39:49,710 --> 00:39:51,895
They wanted to make
it easy to build

950
00:39:51,895 --> 00:39:53,350
applications for developers.

951
00:39:53,350 --> 00:39:55,290
And one of the easy
ways of doing that

952
00:39:55,290 --> 00:39:57,876
is being able to take advantage
of the massive Java libraries

953
00:39:57,876 --> 00:39:58,462
out there.

954
00:39:58,462 --> 00:39:59,170
PROFESSOR: Mm-hm.

955
00:39:59,170 --> 00:39:59,670
Yeah.

956
00:39:59,670 --> 00:40:02,730
So I think one big reason for
using Java is the usability.

957
00:40:02,730 --> 00:40:05,820
They wanted to-- I think Java
has little to do with security

958
00:40:05,820 --> 00:40:09,960
and mostly with programmability,
ease of development.

959
00:40:09,960 --> 00:40:11,875
One other thing that
I think is going on

960
00:40:11,875 --> 00:40:15,190
is that-- well, to contrast
with iPhones, for example.

961
00:40:15,190 --> 00:40:17,510
iPhones also really want
ease of development.

962
00:40:17,510 --> 00:40:21,450
But they use Objective C, which
has buffer overflows if you

963
00:40:21,450 --> 00:40:22,350
try hard enough.

964
00:40:22,350 --> 00:40:25,340
And it is specific to
a particular hardware.

965
00:40:25,340 --> 00:40:27,540
It doesn't maybe have
all the same libraries.

966
00:40:27,540 --> 00:40:29,835
I think the main reason
why the Android guys

967
00:40:29,835 --> 00:40:31,320
went with Java is
probably the fact

968
00:40:31,320 --> 00:40:34,290
that they weren't manufacturing
devices at the same time.

969
00:40:34,290 --> 00:40:35,735
So the iPhones
knew exactly it was

970
00:40:35,735 --> 00:40:37,860
going to be this ARM
processor running their phone.

971
00:40:37,860 --> 00:40:40,780
So they could compile to
ARM and be done with it.

972
00:40:40,780 --> 00:40:43,460
And it's more efficient,
because battery

973
00:40:43,460 --> 00:40:45,770
matters a lot on a phone.

974
00:40:45,770 --> 00:40:48,270
And the Android guys use Java,
which probably is slightly

975
00:40:48,270 --> 00:40:51,120
less power-efficient or
CPU-efficient, because it

976
00:40:51,120 --> 00:40:53,056
involves this JRE, et cetera.

977
00:40:53,056 --> 00:40:54,430
But the cool thing
about it, it's

978
00:40:54,430 --> 00:40:56,200
actually portable
between architectures.

979
00:40:56,200 --> 00:40:58,750
So if you have a phone that
has a MIPS processor, or an ARM

980
00:40:58,750 --> 00:41:02,280
processor, or an x86
processor, the Java application

981
00:41:02,280 --> 00:41:05,280
can be run on all three
of these kinds of devices.

982
00:41:05,280 --> 00:41:07,420
And the Android guys
wanted their platform

983
00:41:07,420 --> 00:41:11,550
to be usable on any kind
of hardware or phone.

984
00:41:11,550 --> 00:41:13,305
So that's probably
one big reason

985
00:41:13,305 --> 00:41:15,695
for why they use Java
in all these cases,

986
00:41:15,695 --> 00:41:18,120
and probably less so in
terms of [? staying ?]

987
00:41:18,120 --> 00:41:21,360
security consideration for Java.

988
00:41:21,360 --> 00:41:24,450
So in fact, it turns out that
the Java runtime doesn't really

989
00:41:24,450 --> 00:41:28,190
provide any security purpose
for the application and is just

990
00:41:28,190 --> 00:41:30,430
sort of a nice
convenience thing,

991
00:41:30,430 --> 00:41:33,532
as well as providing all the
abstractions that the developer

992
00:41:33,532 --> 00:41:34,573
should think in terms of.

993
00:41:34,573 --> 00:41:36,156
But in terms of
isolation, it's mostly

994
00:41:36,156 --> 00:41:38,090
up to the kernel and
the reference monitor

995
00:41:38,090 --> 00:41:41,300
to keep these guys in line.

996
00:41:41,300 --> 00:41:43,030
That make sense?

997
00:41:43,030 --> 00:41:45,938
Any questions?

998
00:41:45,938 --> 00:41:47,854
AUDIENCE: Doesn't the
ease of development also

999
00:41:47,854 --> 00:41:49,895
kind of translate into
some security [INAUDIBLE]?

1000
00:41:49,895 --> 00:41:52,634
Because if you write that
reference monitor in C,

1001
00:41:52,634 --> 00:41:54,800
I can see much more
ways to make a mistake.

1002
00:41:54,800 --> 00:41:55,466
PROFESSOR: Yeah.

1003
00:41:55,466 --> 00:41:57,966
So you're absolutely right.

1004
00:41:57,966 --> 00:42:00,320
Actually, I shouldn't have
said that ease of development

1005
00:42:00,320 --> 00:42:01,520
has nothing to do with security.

1006
00:42:01,520 --> 00:42:03,061
This is completely
silly, because you

1007
00:42:03,061 --> 00:42:07,290
want to make it as easy as
possible to write correct code.

1008
00:42:07,290 --> 00:42:08,870
And it's all about
covering mistakes.

1009
00:42:08,870 --> 00:42:12,560
So in some ways,
having a system where

1010
00:42:12,560 --> 00:42:15,400
it's easy to write correct code
is the most important security

1011
00:42:15,400 --> 00:42:16,680
consideration to have.

1012
00:42:16,680 --> 00:42:20,240
So in some sense, you're
right, that it avoids the bugs.

1013
00:42:20,240 --> 00:42:22,840
But you don't want your
application written in C.

1014
00:42:22,840 --> 00:42:25,200
Or I don't know why Apple has
Objective C. It's actually

1015
00:42:25,200 --> 00:42:26,780
a little bit of a
problem in this regard,

1016
00:42:26,780 --> 00:42:27,670
because you could
easily have buffer

1017
00:42:27,670 --> 00:42:28,930
overflows in your application.

1018
00:42:28,930 --> 00:42:31,230
And if that application
matters a lot,

1019
00:42:31,230 --> 00:42:33,540
then it's vulnerable
potentially.

1020
00:42:33,540 --> 00:42:36,935
Not with respect to compromising
other applications, but you're

1021
00:42:36,935 --> 00:42:38,518
[? all like, ?] bank
app, I don't want

1022
00:42:38,518 --> 00:42:39,662
that bank app written in C.

1023
00:42:39,662 --> 00:42:40,328
AUDIENCE: Right.

1024
00:42:40,328 --> 00:42:40,990
Yeah.

1025
00:42:40,990 --> 00:42:44,000
AUDIENCE: Is the reference
monitor written in Java or C?

1026
00:42:44,000 --> 00:42:46,560
PROFESSOR: So in Android, the
reference monitor is largely

1027
00:42:46,560 --> 00:42:47,610
written in Java, yes.

1028
00:42:47,610 --> 00:42:50,510
There are some native hooks
that it needs in order

1029
00:42:50,510 --> 00:42:53,546
to be able to talk to these
intent interface-- pipes,

1030
00:42:53,546 --> 00:42:54,920
basically, to talk
to the binder,

1031
00:42:54,920 --> 00:42:56,380
they need some native code.

1032
00:42:56,380 --> 00:42:58,295
They need some native code
to spawn these applications

1033
00:42:58,295 --> 00:42:59,544
in the first place, et cetera.

1034
00:42:59,544 --> 00:43:02,955
But by and large, most of
the logic is written in Java.

1035
00:43:02,955 --> 00:43:06,674
So it's actually a reasonably
safe plan, I think.

1036
00:43:06,674 --> 00:43:10,090
Any other questions about this?

1037
00:43:10,090 --> 00:43:11,974
All right.

1038
00:43:11,974 --> 00:43:16,020
So I guess let's try to figure
out what are these application

1039
00:43:16,020 --> 00:43:19,170
UIDs used for other than
to keep applications

1040
00:43:19,170 --> 00:43:22,700
separate from another in
terms of their processes?

1041
00:43:22,700 --> 00:43:24,890
So I guess the main
thing that applications

1042
00:43:24,890 --> 00:43:29,240
need to use the UID for or
that we need to somehow support

1043
00:43:29,240 --> 00:43:33,430
is the ability to share access
to shared resources and shared

1044
00:43:33,430 --> 00:43:35,570
data in the system.

1045
00:43:35,570 --> 00:43:37,560
And we already saw one
mechanism for doing it,

1046
00:43:37,560 --> 00:43:40,910
which is to send intents
to the reference monitor.

1047
00:43:40,910 --> 00:43:44,230
But there's a bunch of things
that, in Android, are not

1048
00:43:44,230 --> 00:43:48,250
done through intents to
the reference monitor.

1049
00:43:48,250 --> 00:43:51,780
And they have to do
probably with performance,

1050
00:43:51,780 --> 00:43:54,564
or why-- basically, why isn't
everything sent through intents

1051
00:43:54,564 --> 00:43:56,480
is probably because there
are some performance

1052
00:43:56,480 --> 00:43:57,860
considerations.

1053
00:43:57,860 --> 00:43:59,540
You don't want to
invoke the reference

1054
00:43:59,540 --> 00:44:02,490
monitor in every single
thing you do in the system.

1055
00:44:02,490 --> 00:44:05,200
And there's a couple of things
that an Android are like this.

1056
00:44:05,200 --> 00:44:07,200
The simplest one is
probably network access.

1057
00:44:10,151 --> 00:44:11,775
So if you want to
talk to the internet,

1058
00:44:11,775 --> 00:44:14,730
you just open a
socket, very much

1059
00:44:14,730 --> 00:44:17,340
like you would on a standard
Linux application today.

1060
00:44:17,340 --> 00:44:19,715
The application can just ask
the kernel, I want a socket,

1061
00:44:19,715 --> 00:44:21,310
I want to connect
to this machine.

1062
00:44:21,310 --> 00:44:22,806
Go for it.

1063
00:44:22,806 --> 00:44:26,350
So network access
happens to work this way.

1064
00:44:26,350 --> 00:44:28,420
Access to removable storage.

1065
00:44:28,420 --> 00:44:30,940
So if you have an SD
card in your phone,

1066
00:44:30,940 --> 00:44:33,420
that also directly goes
through the kernel.

1067
00:44:33,420 --> 00:44:37,810
Or more generally, any
kind of file system access

1068
00:44:37,810 --> 00:44:40,116
or direct access to the
file system, at least,

1069
00:44:40,116 --> 00:44:41,490
goes directly
through the kernel,

1070
00:44:41,490 --> 00:44:43,020
because there is already
a file system there.

1071
00:44:43,020 --> 00:44:45,430
And you want to avoid probably
[INAUDIBLE] performance

1072
00:44:45,430 --> 00:44:48,920
overheads on that.

1073
00:44:48,920 --> 00:44:54,610
And also, for most
devices that are hardware,

1074
00:44:54,610 --> 00:44:58,610
Android allows the application
to directly talk to the device

1075
00:44:58,610 --> 00:45:02,100
instead of mediating the access
through the reference monitor.

1076
00:45:02,100 --> 00:45:07,280
So this is things like probably
your camera, your GPS device,

1077
00:45:07,280 --> 00:45:08,160
compass, et cetera.

1078
00:45:08,160 --> 00:45:12,490
And these guys just show up in
Android in Linux as something

1079
00:45:12,490 --> 00:45:15,526
like /dev/camera.

1080
00:45:15,526 --> 00:45:18,750
And this is just
a Linux device you

1081
00:45:18,750 --> 00:45:21,478
could open, and get the
camera data out, and control

1082
00:45:21,478 --> 00:45:23,970
the camera in whatever
ways you want, et cetera.

1083
00:45:23,970 --> 00:45:26,870
And the cool thing is that if
you want to do some specialized

1084
00:45:26,870 --> 00:45:29,045
things to this device,
you're not restricted

1085
00:45:29,045 --> 00:45:31,220
to what Java allows you to do.

1086
00:45:31,220 --> 00:45:33,750
You can always
write C code or even

1087
00:45:33,750 --> 00:45:35,780
Assembly that directly
talks to the kernel

1088
00:45:35,780 --> 00:45:38,810
and performs the necessary
operations on this Linux

1089
00:45:38,810 --> 00:45:41,380
device, making
arbitrary system calls.

1090
00:45:41,380 --> 00:45:45,060
And you could wrap this up
in a Java native interface

1091
00:45:45,060 --> 00:45:49,018
to expose it to the rest of your
Java-based application here.

1092
00:45:49,018 --> 00:45:49,518
Yeah.

1093
00:45:49,518 --> 00:45:52,101
AUDIENCE: But you still have the
checks in these calls, right?

1094
00:45:52,101 --> 00:45:54,409
So when you open
a socket, someone

1095
00:45:54,409 --> 00:45:56,950
has to check if they're allowed
to open a socket [INAUDIBLE].

1096
00:45:56,950 --> 00:45:57,160
PROFESSOR: Yeah.

1097
00:45:57,160 --> 00:45:58,500
So this is an interesting thing.

1098
00:45:58,500 --> 00:46:01,010
Now these things are outside
our intent-based model.

1099
00:46:01,010 --> 00:46:03,740
So how are we going
to protect these guys?

1100
00:46:03,740 --> 00:46:06,485
So this sort of boils
down to doing something

1101
00:46:06,485 --> 00:46:07,860
very similar to
what you guys did

1102
00:46:07,860 --> 00:46:10,900
in Lab 2, which is
you [INAUDIBLE] you

1103
00:46:10,900 --> 00:46:13,940
want to enforce it using UIDs.

1104
00:46:13,940 --> 00:46:15,850
Basically, the
Android framework is

1105
00:46:15,850 --> 00:46:19,440
responsible for carefully
orchestrating the UIDs and GIDs

1106
00:46:19,440 --> 00:46:22,200
of the applications
and of these things

1107
00:46:22,200 --> 00:46:28,340
to enforce whatever policy was
specified in terms of labels.

1108
00:46:28,340 --> 00:46:31,970
So the way this works
out is that for every one

1109
00:46:31,970 --> 00:46:35,950
of these resources, there
is a pre-defined label

1110
00:46:35,950 --> 00:46:39,100
string that defines
the privilege

1111
00:46:39,100 --> 00:46:40,515
to access this resource.

1112
00:46:40,515 --> 00:46:41,890
So for this network
access thing,

1113
00:46:41,890 --> 00:46:45,430
for example, I think
there's a string, something

1114
00:46:45,430 --> 00:46:47,570
like
android.permissions.INTERNET.

1115
00:46:55,590 --> 00:47:00,410
So this is a label that an
application can ask for.

1116
00:47:00,410 --> 00:47:06,405
And if an application has this
label in its set of privileges,

1117
00:47:06,405 --> 00:47:08,600
then it should be able
to access the network.

1118
00:47:08,600 --> 00:47:10,930
And the way this is
enforced-- so the label

1119
00:47:10,930 --> 00:47:12,714
is the policy side of this.

1120
00:47:12,714 --> 00:47:14,450
How do you specify
what should happen?

1121
00:47:14,450 --> 00:47:17,850
And the enforcement
mechanism is a small change

1122
00:47:17,850 --> 00:47:20,420
to the Linux kernel in
Android, where in order

1123
00:47:20,420 --> 00:47:23,260
to make any network-related
system calls,

1124
00:47:23,260 --> 00:47:25,520
you have to be a member
of some magic group.

1125
00:47:25,520 --> 00:47:28,540
This is not at all how things
work in Linux traditionally.

1126
00:47:28,540 --> 00:47:31,804
But in Android, there is
some magic group [INAUDIBLE]

1127
00:47:31,804 --> 00:47:35,610
I think it's GID 3003.

1128
00:47:35,610 --> 00:47:38,530
And the kernel has this
number hard-coded in it.

1129
00:47:38,530 --> 00:47:45,315
And if the process has this
group ID in its group list,

1130
00:47:45,315 --> 00:47:48,059
then it's allowed to use a
network-related system call.

1131
00:47:48,059 --> 00:47:50,350
And if it doesn't have this
group ID in its group list,

1132
00:47:50,350 --> 00:47:53,030
then it's not allowed to make
any network-related system

1133
00:47:53,030 --> 00:47:53,980
calls at all.

1134
00:47:53,980 --> 00:47:58,250
So this is how Android is able
to translate these label--

1135
00:47:58,250 --> 00:48:02,480
sort of maintain a single,
coherent policy system that's

1136
00:48:02,480 --> 00:48:05,482
in terms of these label
screens, but enforce it

1137
00:48:05,482 --> 00:48:06,240
in different ways.

1138
00:48:06,240 --> 00:48:09,310
So sometimes it gets enforced
by the reference monitor.

1139
00:48:09,310 --> 00:48:11,150
And other times,
it gets enforced

1140
00:48:11,150 --> 00:48:15,000
by setting GIDs or
UIDs appropriately.

1141
00:48:15,000 --> 00:48:16,990
The same thing actually
happens with SD cards.

1142
00:48:16,990 --> 00:48:20,150
There's another GID that
corresponds to having access

1143
00:48:20,150 --> 00:48:21,120
with the SD card.

1144
00:48:21,120 --> 00:48:24,220
And there's a string that
gets translated into this GID,

1145
00:48:24,220 --> 00:48:25,320
effectively.

1146
00:48:25,320 --> 00:48:27,884
And same for the file system.

1147
00:48:27,884 --> 00:48:29,300
I guess in the
file system, things

1148
00:48:29,300 --> 00:48:30,460
are a little bit trickier.

1149
00:48:30,460 --> 00:48:32,263
I guess the SD card
is in the file system

1150
00:48:32,263 --> 00:48:36,720
and has a specific GID for
accessing the entire SD card.

1151
00:48:36,720 --> 00:48:42,250
Another sort of other files
in the phone's file system--

1152
00:48:42,250 --> 00:48:45,450
there, the policy isn't
so much controlled

1153
00:48:45,450 --> 00:48:49,340
by labels, but rather
by Android's design,

1154
00:48:49,340 --> 00:48:52,380
which is that each application
has a private directory

1155
00:48:52,380 --> 00:48:55,060
that it can use to store
whatever files it wants.

1156
00:48:55,060 --> 00:48:57,770
And in particular,
the content provider,

1157
00:48:57,770 --> 00:49:00,580
the SQL database that you're
going to use as an application,

1158
00:49:00,580 --> 00:49:03,140
is stored in your
private directory.

1159
00:49:03,140 --> 00:49:05,660
And the policy is only the
application's UID can access

1160
00:49:05,660 --> 00:49:07,650
that private directory,
and no one else

1161
00:49:07,650 --> 00:49:10,216
can access it directly.

1162
00:49:10,216 --> 00:49:12,620
And then for
devices, there's also

1163
00:49:12,620 --> 00:49:15,220
a plan very similar to
network access, where

1164
00:49:15,220 --> 00:49:19,540
there's a permission string
for accessing GPS, the camera,

1165
00:49:19,540 --> 00:49:20,570
et cetera.

1166
00:49:20,570 --> 00:49:22,345
And for each one
of these, there's

1167
00:49:22,345 --> 00:49:27,850
a GID that is used in the
permissions on that device.

1168
00:49:27,850 --> 00:49:31,970
So for example, dev/camera
is owned by some magic GID.

1169
00:49:31,970 --> 00:49:35,064
And any application that should
have access to that camera

1170
00:49:35,064 --> 00:49:37,450
has that GID in its [INAUDIBLE].

1171
00:49:37,450 --> 00:49:38,395
All make sense?

1172
00:49:38,395 --> 00:49:44,350
It was hopefully fairly similar
to what you guys did in Lab 2.

1173
00:49:44,350 --> 00:49:47,992
Well, not the label part,
but the using UIDs and GIDs

1174
00:49:47,992 --> 00:49:50,357
to get somewhere [INAUDIBLE].

1175
00:49:50,357 --> 00:49:52,249
Make sense?

1176
00:49:52,249 --> 00:49:54,630
All right.

1177
00:49:54,630 --> 00:49:56,850
So one interesting question
is why do these guys

1178
00:49:56,850 --> 00:50:01,070
have such a course-grained
plan for handling the SD card?

1179
00:50:01,070 --> 00:50:04,455
Why don't they
have different apps

1180
00:50:04,455 --> 00:50:06,520
act [? with ?] different
parts of the SD card?

1181
00:50:06,520 --> 00:50:08,815
I probably have lots
of stuff in my SD card

1182
00:50:08,815 --> 00:50:11,520
that I don't want
applications to-- you know,

1183
00:50:11,520 --> 00:50:14,012
to have access to all of it.

1184
00:50:14,012 --> 00:50:14,900
Make sense?

1185
00:50:14,900 --> 00:50:15,530
Yeah.

1186
00:50:15,530 --> 00:50:17,821
AUDIENCE: Maybe it has
something to do with [INAUDIBLE]

1187
00:50:17,821 --> 00:50:19,814
that a user has to
approve those permissions.

1188
00:50:19,814 --> 00:50:22,034
And the less of them you
have, the more likely

1189
00:50:22,034 --> 00:50:25,540
it is to actually [INAUDIBLE].

1190
00:50:25,540 --> 00:50:26,830
AUDIENCE: Could be.

1191
00:50:26,830 --> 00:50:30,310
Well, that's definitely a
problem in general in Android,

1192
00:50:30,310 --> 00:50:31,930
and we'll get to it in a minute.

1193
00:50:31,930 --> 00:50:35,380
But I think for the
SD card, it's actually

1194
00:50:35,380 --> 00:50:36,650
a slightly different concern.

1195
00:50:36,650 --> 00:50:38,920
It has to do with
the fact that you

1196
00:50:38,920 --> 00:50:40,421
want these SD cards
to inter-operate

1197
00:50:40,421 --> 00:50:41,545
with the rest of the world.

1198
00:50:41,545 --> 00:50:42,950
So this is like
one of the places

1199
00:50:42,950 --> 00:50:45,880
where Android isn't free to
make arbitrary decisions,

1200
00:50:45,880 --> 00:50:48,530
because you want these SD
cards to have a standard file

1201
00:50:48,530 --> 00:50:51,470
system, namely
FAT, because that's

1202
00:50:51,470 --> 00:50:54,300
the de facto standard for
storing data on an SD card

1203
00:50:54,300 --> 00:50:55,320
these days.

1204
00:50:55,320 --> 00:50:58,720
And as a result, you can't have
a sophisticated file system

1205
00:50:58,720 --> 00:51:01,589
there that stores
permissions for each file.

1206
00:51:01,589 --> 00:51:03,380
And as a result, it's
going to be difficult

1207
00:51:03,380 --> 00:51:06,500
for you to somehow
segregate these files

1208
00:51:06,500 --> 00:51:08,310
and give different
apps different access.

1209
00:51:08,310 --> 00:51:08,809
Yeah?

1210
00:51:08,809 --> 00:51:11,664
AUDIENCE: Do you still
think of [INAUDIBLE]?

1211
00:51:11,664 --> 00:51:12,330
PROFESSOR: Yeah.

1212
00:51:12,330 --> 00:51:14,455
So it might be that you
could give each application

1213
00:51:14,455 --> 00:51:17,870
a different subdirectory on
the SD card to have access to.

1214
00:51:17,870 --> 00:51:20,035
But then it would
mostly be a way

1215
00:51:20,035 --> 00:51:22,930
to give each application
additional storage and not

1216
00:51:22,930 --> 00:51:25,910
the ability for an
application to read existing

1217
00:51:25,910 --> 00:51:28,880
content from your SD card.

1218
00:51:28,880 --> 00:51:30,336
Because the existing
content might

1219
00:51:30,336 --> 00:51:31,460
be in some other directory.

1220
00:51:31,460 --> 00:51:31,935
So you're right.

1221
00:51:31,935 --> 00:51:34,310
It might be that you could
have more fine-grained things,

1222
00:51:34,310 --> 00:51:36,730
like well, you want access to
the entire SD card addressed

1223
00:51:36,730 --> 00:51:39,715
to a per app directory there.

1224
00:51:39,715 --> 00:51:42,770
And that probably has to
do with not overwhelming

1225
00:51:42,770 --> 00:51:47,420
the user with too many choices
in terms of these permissions.

1226
00:51:47,420 --> 00:51:50,152
But yeah, you're right,
you could probably

1227
00:51:50,152 --> 00:51:53,400
do some combination
of these two.

1228
00:51:53,400 --> 00:51:54,640
All right.

1229
00:51:54,640 --> 00:51:59,890
So I guess one
interesting [? thing to ?]

1230
00:51:59,890 --> 00:52:10,390
talk about is how do we decide
whether an application should

1231
00:52:10,390 --> 00:52:14,790
have a particular set of labels
that it should have access

1232
00:52:14,790 --> 00:52:15,901
to in this label set?

1233
00:52:15,901 --> 00:52:17,650
So where do these guys
actually come from?

1234
00:52:17,650 --> 00:52:20,375
Like, who decides that
this application should

1235
00:52:20,375 --> 00:52:23,470
have DIAL PERM and
INTERNET and FRIEND VIEW

1236
00:52:23,470 --> 00:52:26,310
permissions in Android?

1237
00:52:26,310 --> 00:52:27,103
Yeah.

1238
00:52:27,103 --> 00:52:28,603
AUDIENCE: The
developer [INAUDIBLE].

1239
00:52:31,294 --> 00:52:32,960
PROFESSOR: Yeah, it's
a little bit of a,

1240
00:52:32,960 --> 00:52:36,570
you know, well, I guess
an upfront system, where

1241
00:52:36,570 --> 00:52:38,111
the developer has
to, first of all,

1242
00:52:38,111 --> 00:52:40,360
enumerate all the things
it'll ever need in the future

1243
00:52:40,360 --> 00:52:42,910
or as their applications
going to run.

1244
00:52:42,910 --> 00:52:47,030
And then the user is responsible
for looking over this list

1245
00:52:47,030 --> 00:52:48,870
and deciding whether
it's OK, whether they

1246
00:52:48,870 --> 00:52:52,295
should allow these application
to be installed or not.

1247
00:52:52,295 --> 00:52:55,110
And this way, the user is
still an important part

1248
00:52:55,110 --> 00:52:58,090
of the system in
terms of security,

1249
00:52:58,090 --> 00:53:01,480
because the user
could almost always

1250
00:53:01,480 --> 00:53:03,105
approve any set of
permissions you want

1251
00:53:03,105 --> 00:53:06,020
or that the developer wants.

1252
00:53:06,020 --> 00:53:08,050
So in many ways, it's
actually quite flexible,

1253
00:53:08,050 --> 00:53:13,144
because unlike something like
iOS-- where it's actually

1254
00:53:13,144 --> 00:53:15,060
difficult to share between
apps, or it's hard,

1255
00:53:15,060 --> 00:53:17,455
for example, for a third-party
iPhone application,

1256
00:53:17,455 --> 00:53:21,090
I think, to access arbitrary
other components of the phone,

1257
00:53:21,090 --> 00:53:23,870
and dial a phone, or
send an SMS message,

1258
00:53:23,870 --> 00:53:26,720
or find a JPEG viewer,
et cetera-- here,

1259
00:53:26,720 --> 00:53:27,880
it's quite flexible.

1260
00:53:27,880 --> 00:53:31,960
But sort of the cost
to it is that you

1261
00:53:31,960 --> 00:53:34,510
have to get the
developer or the user

1262
00:53:34,510 --> 00:53:36,930
to check that the
developer is asking

1263
00:53:36,930 --> 00:53:39,160
for a sensible set of
permissions or the user

1264
00:53:39,160 --> 00:53:41,686
trusts this developer
with these privileges.

1265
00:53:41,686 --> 00:53:43,060
So it's a little
bit unfortunate.

1266
00:53:43,060 --> 00:53:44,851
It's probably one of
the biggest, actually,

1267
00:53:44,851 --> 00:53:46,900
security problems in
practice with Android,

1268
00:53:46,900 --> 00:53:49,550
which is that users are
quite willing to give away

1269
00:53:49,550 --> 00:53:52,786
these permissions if they
really want an application.

1270
00:53:52,786 --> 00:53:56,010
I search for some application,
and I click Install.

1271
00:53:56,010 --> 00:53:58,177
And if it doesn't look like
a particularly long list

1272
00:53:58,177 --> 00:54:00,051
and there's nothing that
pops out right away,

1273
00:54:00,051 --> 00:54:01,500
I'll probably click OK.

1274
00:54:01,500 --> 00:54:04,720
And I might not spend the
time to really understand

1275
00:54:04,720 --> 00:54:08,062
whether these permissions
are necessary.

1276
00:54:08,062 --> 00:54:11,855
The other slight bummer is that
[INAUDIBLE] the time this paper

1277
00:54:11,855 --> 00:54:15,300
was written, Android
decided that the user

1278
00:54:15,300 --> 00:54:17,310
had only two choices--
either install the app

1279
00:54:17,310 --> 00:54:19,300
or not install the app,
which is a little bit

1280
00:54:19,300 --> 00:54:20,136
of a binary choice.

1281
00:54:20,136 --> 00:54:22,510
And the user is presumably
going to just say, well, yeah,

1282
00:54:22,510 --> 00:54:23,230
I want the app.

1283
00:54:23,230 --> 00:54:25,110
What else am I going to do?

1284
00:54:25,110 --> 00:54:27,950
I need to do this thing.

1285
00:54:27,950 --> 00:54:32,480
And I think more recently, I
think some version of Android,

1286
00:54:32,480 --> 00:54:35,710
I think 4.3, introduced
a more fine-grain scheme,

1287
00:54:35,710 --> 00:54:40,120
where the user is actually
allowed to pick and choose

1288
00:54:40,120 --> 00:54:43,360
from these permissions where--
well, you are still presented

1289
00:54:43,360 --> 00:54:46,340
with a list of permissions
that the developer wants

1290
00:54:46,340 --> 00:54:47,620
for their application to have.

1291
00:54:47,620 --> 00:54:51,980
But the user can now, in a
more fine-grained manner,

1292
00:54:51,980 --> 00:54:54,870
remove some of these permissions
from the application.

1293
00:54:54,870 --> 00:54:58,440
And it's unclear how an average
user is supposed to use this,

1294
00:54:58,440 --> 00:55:01,263
because it's probably quite
hard to go through this list

1295
00:55:01,263 --> 00:55:02,980
and make decisions about this.

1296
00:55:02,980 --> 00:55:07,450
But at least the API is
starting to show up there.

1297
00:55:07,450 --> 00:55:10,940
I haven't seen any
significant uses of it so far.

1298
00:55:10,940 --> 00:55:14,780
But it might be nice.

1299
00:55:14,780 --> 00:55:16,220
All right.

1300
00:55:16,220 --> 00:55:17,160
[INAUDIBLE]

1301
00:55:17,160 --> 00:55:17,660
Yeah?

1302
00:55:17,660 --> 00:55:19,180
AUDIENCE: [INAUDIBLE].

1303
00:55:19,180 --> 00:55:21,702
it just lets you take away.

1304
00:55:21,702 --> 00:55:22,410
PROFESSOR: Sorry?

1305
00:55:22,410 --> 00:55:27,178
AUDIENCE: The [INAUDIBLE] just
lets you take away [INAUDIBLE].

1306
00:55:27,178 --> 00:55:27,844
PROFESSOR: Yeah.

1307
00:55:27,844 --> 00:55:30,900
So I think that's basically
what this new version of Android

1308
00:55:30,900 --> 00:55:33,730
lets you do, which is you can--
instead of taking away-- well,

1309
00:55:33,730 --> 00:55:34,990
it's not labelled strings.

1310
00:55:34,990 --> 00:55:36,615
It's descriptions of
these permissions.

1311
00:55:36,615 --> 00:55:38,600
But you can actually
now-- something, I think,

1312
00:55:38,600 --> 00:55:41,100
called Android Permission
Manager lets you,

1313
00:55:41,100 --> 00:55:44,416
for every app, list
all the labeled strings

1314
00:55:44,416 --> 00:55:46,430
that the app has permission for.

1315
00:55:46,430 --> 00:55:50,740
And you could, I think,
remove these things

1316
00:55:50,740 --> 00:55:53,740
on an individual basis if
you feel strongly about them.

1317
00:55:53,740 --> 00:55:57,035
I don't know how many
users [INAUDIBLE].

1318
00:55:57,035 --> 00:55:57,660
Yeah, question?

1319
00:55:57,660 --> 00:56:00,118
AUDIENCE: Whenever the labels
[? don't match up, ?] does it

1320
00:56:00,118 --> 00:56:03,540
hard-fail, or is it just that
doesn't work [INAUDIBLE]?

1321
00:56:03,540 --> 00:56:05,290
PROFESSOR: Well,
I think it depends

1322
00:56:05,290 --> 00:56:08,930
on exactly what
the application is

1323
00:56:08,930 --> 00:56:11,590
trying to do that is going
to require that label.

1324
00:56:11,590 --> 00:56:14,920
So if the application is
going to send an intent

1325
00:56:14,920 --> 00:56:18,000
and sending that intent requires
a particular label like DIAL

1326
00:56:18,000 --> 00:56:19,459
PERM, well, it
might be that you're

1327
00:56:19,459 --> 00:56:21,541
going to send the intent
to the reference monitor.

1328
00:56:21,541 --> 00:56:23,110
And the reference
monitor is going

1329
00:56:23,110 --> 00:56:25,260
to say, well, there's
no application that is

1330
00:56:25,260 --> 00:56:27,044
willing to accept your message.

1331
00:56:27,044 --> 00:56:28,710
So maybe then it's
up to the application

1332
00:56:28,710 --> 00:56:31,270
to do something
sensible in response.

1333
00:56:31,270 --> 00:56:34,130
Another possibility is that
maybe it's a network access,

1334
00:56:34,130 --> 00:56:35,990
and you don't have
access to that,

1335
00:56:35,990 --> 00:56:38,550
and you're going to make
a socket system call,

1336
00:56:38,550 --> 00:56:40,720
or you're going to say,
connect to this IP address.

1337
00:56:40,720 --> 00:56:43,180
And the kernel says, E
PERM, you can't do that.

1338
00:56:43,180 --> 00:56:44,040
And who knows what
the application

1339
00:56:44,040 --> 00:56:45,206
is going to do in that case?

1340
00:56:45,206 --> 00:56:48,660
Maybe it'll throw a null
pointer exception somehow.

1341
00:56:48,660 --> 00:56:52,690
So one argument
against doing this

1342
00:56:52,690 --> 00:56:56,830
is that Android applications,
at least originally,

1343
00:56:56,830 --> 00:56:59,660
weren't written to expect
some of their accesses

1344
00:56:59,660 --> 00:57:02,450
to fail, because they were told,
the manifest is all or nothing.

1345
00:57:02,450 --> 00:57:04,640
Either the user approves
your app, or they don't.

1346
00:57:04,640 --> 00:57:09,190
So application developers,
perhaps rightly so,

1347
00:57:09,190 --> 00:57:12,680
wrote code that
perhaps crashes or does

1348
00:57:12,680 --> 00:57:18,580
something not unexpected if
some access provision fails.

1349
00:57:18,580 --> 00:57:20,980
So it might be that by
taking away permissions,

1350
00:57:20,980 --> 00:57:24,700
you're going to cause the app to
crash if it needs that access.

1351
00:57:24,700 --> 00:57:27,075
So it's not like, well, you
know, you have this nice app,

1352
00:57:27,075 --> 00:57:28,900
and it needs access
to the camera.

1353
00:57:28,900 --> 00:57:31,480
But if you turn it off, it'll
just put on some dummy picture

1354
00:57:31,480 --> 00:57:31,880
instead.

1355
00:57:31,880 --> 00:57:33,171
Maybe it'll just crash instead.

1356
00:57:33,171 --> 00:57:34,670
So it's not great.

1357
00:57:34,670 --> 00:57:36,750
You might imagine much
more sophisticated systems

1358
00:57:36,750 --> 00:57:39,185
which, if you take away some
of the access to a camera,

1359
00:57:39,185 --> 00:57:41,185
are going to provide a
fake camera that just has

1360
00:57:41,185 --> 00:57:42,480
a black screen all the time.

1361
00:57:42,480 --> 00:57:44,323
So this is not
what Android does.

1362
00:57:44,323 --> 00:57:46,540
But you could imagine
[? alternate ?] situations

1363
00:57:46,540 --> 00:57:49,830
where this might happen.

1364
00:57:49,830 --> 00:57:50,330
All right.

1365
00:57:50,330 --> 00:57:53,360
Any other questions here?

1366
00:57:53,360 --> 00:57:54,160
All right.

1367
00:57:54,160 --> 00:57:55,740
So we've looked a
little bit at sort

1368
00:57:55,740 --> 00:58:00,280
of where these strings come from
in the label of an Android app.

1369
00:58:00,280 --> 00:58:02,520
But who defines these strings?

1370
00:58:02,520 --> 00:58:07,060
Like, where does the meaning
of a string come from?

1371
00:58:07,060 --> 00:58:10,420
You can list all kinds of
strings in your manifest file.

1372
00:58:10,420 --> 00:58:15,180
But how do you decide
which strings matter?

1373
00:58:15,180 --> 00:58:17,670
Where does this string
INTERNET or FRIEND VIEW

1374
00:58:17,670 --> 00:58:19,110
come from in the first place?

1375
00:58:19,110 --> 00:58:21,145
Who gives it meaning
in the system?

1376
00:58:30,320 --> 00:58:32,677
Any ideas?

1377
00:58:32,677 --> 00:58:34,135
Well, I think it's
mostly-- the way

1378
00:58:34,135 --> 00:58:38,800
to think of it is that
almost none of these strings

1379
00:58:38,800 --> 00:58:43,190
should be magic or
pre-defined ahead of time.

1380
00:58:43,190 --> 00:58:45,270
Almost all these
strings are basically

1381
00:58:45,270 --> 00:58:47,430
contracts between
two applications

1382
00:58:47,430 --> 00:58:51,720
so one application is
willing to export something

1383
00:58:51,720 --> 00:58:55,447
under the protection
of some label string.

1384
00:58:55,447 --> 00:58:57,780
And another application wants
to ask for that permission

1385
00:58:57,780 --> 00:59:01,020
to talk to the application
that defines this component.

1386
00:59:01,020 --> 00:59:03,632
So these labels
are typically-- you

1387
00:59:03,632 --> 00:59:06,010
can think of them
as being defined

1388
00:59:06,010 --> 00:59:09,900
by the application that
provides some protected service.

1389
00:59:09,900 --> 00:59:13,940
So if you have this
DIAL PERM permission,

1390
00:59:13,940 --> 00:59:16,040
it's presumably
something that has

1391
00:59:16,040 --> 00:59:19,900
to be defined by an application
that defines what it

1392
00:59:19,900 --> 00:59:21,340
means to dial a phone number.

1393
00:59:21,340 --> 00:59:23,930
So probably the dialer
application in your phone,

1394
00:59:23,930 --> 00:59:27,130
that's the thing that defines
the string and says that, yeah,

1395
00:59:27,130 --> 00:59:30,090
this thing, DIAL PERM,
exists, and my components

1396
00:59:30,090 --> 00:59:31,760
are going to be protected by it.

1397
00:59:31,760 --> 00:59:33,301
And then other
applications that want

1398
00:59:33,301 --> 00:59:35,970
to interact with this
guy, with the dialer,

1399
00:59:35,970 --> 00:59:42,210
can now request this DIAL PERM
permission for themselves.

1400
00:59:42,210 --> 00:59:44,094
And of course, there
are some built-in things

1401
00:59:44,094 --> 00:59:46,760
that we looked at here, like the
internet permission, the camera

1402
00:59:46,760 --> 00:59:47,890
permission, et cetera.

1403
00:59:47,890 --> 00:59:49,295
But you can sort
of think of them

1404
00:59:49,295 --> 00:59:53,520
as the Android framework being
the initial application that

1405
00:59:53,520 --> 00:59:56,900
is in charge of providing
access to this resource

1406
00:59:56,900 --> 00:59:58,930
and defining the string
that's going to protect

1407
00:59:58,930 --> 01:00:01,940
the resource as well.

1408
01:00:01,940 --> 01:00:02,690
What does it mean?

1409
01:00:02,690 --> 01:00:08,840
What's sort of associated with
a label string in Android other

1410
01:00:08,840 --> 01:00:13,304
than the fact that the string
goes into the application's

1411
01:00:13,304 --> 01:00:15,470
label here when they want
to ask for this permission

1412
01:00:15,470 --> 01:00:18,160
and in the component
label as well?

1413
01:00:18,160 --> 01:00:21,030
So there's a couple of
things that is associated

1414
01:00:21,030 --> 01:00:24,260
with the label in Android.

1415
01:00:24,260 --> 01:00:27,720
So a label, in
addition to a string,

1416
01:00:27,720 --> 01:00:30,870
also has a couple of
interesting properties.

1417
01:00:30,870 --> 01:00:35,420
So there's a type of a label.

1418
01:00:35,420 --> 01:00:39,600
And there's, at least in
sort of a modern Android,

1419
01:00:39,600 --> 01:00:42,290
there's three types
you might care about.

1420
01:00:42,290 --> 01:00:46,460
There's a normal type of a
label, or permission label.

1421
01:00:46,460 --> 01:00:49,320
There's dangerous and signature.

1422
01:00:55,410 --> 01:01:00,290
And the application that
defines this permission

1423
01:01:00,290 --> 01:01:03,270
in the first place gets
to choose the type or all

1424
01:01:03,270 --> 01:01:05,280
these other fields for
a label that we're going

1425
01:01:05,280 --> 01:01:07,360
to talk about in a second.

1426
01:01:07,360 --> 01:01:11,360
So what's the point
of a type of a label?

1427
01:01:11,360 --> 01:01:12,860
Why do labels have
types in Android?

1428
01:01:17,068 --> 01:01:17,568
Yeah.

1429
01:01:17,568 --> 01:01:20,794
AUDIENCE: [INAUDIBLE].

1430
01:01:20,794 --> 01:01:21,960
PROFESSOR: Yeah, I guess so.

1431
01:01:21,960 --> 01:01:22,140
Yeah.

1432
01:01:22,140 --> 01:01:23,950
So why not make everything
dangerous, I guess,

1433
01:01:23,950 --> 01:01:24,590
at that level?

1434
01:01:27,480 --> 01:01:28,330
Well, I guess, yeah.

1435
01:01:28,330 --> 01:01:29,360
So maybe the interesting
thing is like,

1436
01:01:29,360 --> 01:01:30,850
what are the semantics
of these types?

1437
01:01:30,850 --> 01:01:32,510
So if something is dangerous,
then you are right.

1438
01:01:32,510 --> 01:01:34,134
It actually warns
the users when you're

1439
01:01:34,134 --> 01:01:36,390
installing an application,
and the application

1440
01:01:36,390 --> 01:01:39,910
asks for access to a particular
label that's of type Dangerous.

1441
01:01:39,910 --> 01:01:42,787
Then the user has to
look at this message

1442
01:01:42,787 --> 01:01:45,245
and say, yes, I'm willing to
give this dangerous permission

1443
01:01:45,245 --> 01:01:47,440
to this new application.

1444
01:01:47,440 --> 01:01:51,530
For normal-type labels,
applications can ask for them,

1445
01:01:51,530 --> 01:01:53,660
and the user
doesn't get prompted

1446
01:01:53,660 --> 01:01:59,930
if the application requests
this normal type of permission.

1447
01:01:59,930 --> 01:02:01,880
Is this silly?

1448
01:02:01,880 --> 01:02:04,812
What's the point of a permission
if everyone just gets it?

1449
01:02:04,812 --> 01:02:07,090
Is there a reason why
we should have this?

1450
01:02:07,090 --> 01:02:09,590
Like, one example of a
normal permission in Android

1451
01:02:09,590 --> 01:02:10,674
is setting your wallpaper.

1452
01:02:10,674 --> 01:02:12,173
So if you have an
application that's

1453
01:02:12,173 --> 01:02:14,890
going to set your wallpaper,
I can, as an application

1454
01:02:14,890 --> 01:02:16,956
developer, say in
my manifest that I

1455
01:02:16,956 --> 01:02:18,080
want to set your wallpaper.

1456
01:02:18,080 --> 01:02:19,810
And if you click
Install, it's going

1457
01:02:19,810 --> 01:02:22,143
to say, well, there's nothing
interesting going on here.

1458
01:02:22,143 --> 01:02:24,198
You don't need to give
it any permissions.

1459
01:02:24,198 --> 01:02:24,698
Yeah.

1460
01:02:24,698 --> 01:02:26,912
AUDIENCE: Well, these
permissions usually require you

1461
01:02:26,912 --> 01:02:28,634
to [INAUDIBLE], right?

1462
01:02:28,634 --> 01:02:31,963
So if an application wants to
change your desktop wallpaper,

1463
01:02:31,963 --> 01:02:33,442
it will ask you.

1464
01:02:33,442 --> 01:02:36,227
The system will ask you, do you
want to change your wallpaper?

1465
01:02:36,227 --> 01:02:36,893
PROFESSOR: Nope.

1466
01:02:36,893 --> 01:02:37,386
AUDIENCE: No?

1467
01:02:37,386 --> 01:02:39,352
PROFESSOR: No, it'll just
change the wallpaper.

1468
01:02:39,352 --> 01:02:41,560
It's access to this API call
to change the wallpaper.

1469
01:02:41,560 --> 01:02:45,980
If I have this permission,
I can make this API call.

1470
01:02:45,980 --> 01:02:46,480
Yeah?

1471
01:02:46,480 --> 01:02:49,034
AUDIENCE: Maybe the application
developer wants to make sure

1472
01:02:49,034 --> 01:02:50,862
they don't do this accidentally?

1473
01:02:50,862 --> 01:02:53,506
PROFESSOR: Yes, I think that's
one reason why you might want

1474
01:02:53,506 --> 01:02:55,960
to have these permissions,
is to help the application

1475
01:02:55,960 --> 01:02:57,610
developer do the right thing.

1476
01:02:57,610 --> 01:03:01,150
So if you worry that your
application might accidentally

1477
01:03:01,150 --> 01:03:02,960
do something or it
might have bugs in it

1478
01:03:02,960 --> 01:03:06,230
that others will
exploit, knowing

1479
01:03:06,230 --> 01:03:08,630
that there's some
set of permissions

1480
01:03:08,630 --> 01:03:11,640
that you do or don't have
prevents your application

1481
01:03:11,640 --> 01:03:13,427
from being abused in these ways.

1482
01:03:13,427 --> 01:03:15,540
So if you have a
benign application that

1483
01:03:15,540 --> 01:03:16,960
never needs to
set the wallpaper,

1484
01:03:16,960 --> 01:03:19,084
you probably don't want to
ask for this permission,

1485
01:03:19,084 --> 01:03:21,094
because if a VLAN
gets compromised,

1486
01:03:21,094 --> 01:03:23,210
then it will be
better for the user,

1487
01:03:23,210 --> 01:03:26,440
on whose phone your
application's installed.

1488
01:03:26,440 --> 01:03:29,470
It's sort of a least
privilege property.

1489
01:03:29,470 --> 01:03:31,710
I guess another thing
is that it maybe

1490
01:03:31,710 --> 01:03:34,080
allows some sort of auditing,
both from a developer

1491
01:03:34,080 --> 01:03:35,756
standpoint, where
they can look and see,

1492
01:03:35,756 --> 01:03:38,214
well, what are the things I
should be concerned about here?

1493
01:03:38,214 --> 01:03:40,100
And as well as from
a user's perspective.

1494
01:03:40,100 --> 01:03:43,130
If your phone is flickering
with a wallpaper change

1495
01:03:43,130 --> 01:03:46,920
every second, you can go and
see who has this permission.

1496
01:03:46,920 --> 01:03:49,143
Even though I didn't
have to approve it,

1497
01:03:49,143 --> 01:03:51,310
I can at least go and
check who is potentially

1498
01:03:51,310 --> 01:03:54,340
doing this right now.

1499
01:03:54,340 --> 01:03:56,800
So these normal
permissions are kind of

1500
01:03:56,800 --> 01:04:01,220
like a good security
measure-- or probably more

1501
01:04:01,220 --> 01:04:03,870
of a good auditing measure.

1502
01:04:03,870 --> 01:04:06,800
And [? aren't ?] generally used
for really interesting things

1503
01:04:06,800 --> 01:04:11,880
like [INAUDIBLE] data or
accessing things like cameras

1504
01:04:11,880 --> 01:04:14,970
or things that cost money.

1505
01:04:14,970 --> 01:04:17,810
So there's also this third
thing, this signature

1506
01:04:17,810 --> 01:04:18,430
permission.

1507
01:04:18,430 --> 01:04:20,775
So one interesting
thing in Android

1508
01:04:20,775 --> 01:04:22,920
is that you can define
a permission that

1509
01:04:22,920 --> 01:04:26,110
is only accessible to
applications that are signed

1510
01:04:26,110 --> 01:04:30,830
with the same developer
key as the application that

1511
01:04:30,830 --> 01:04:33,570
defined the permission
in the first place.

1512
01:04:33,570 --> 01:04:36,850
So if I have, I guess in
the FRIEND VIEW example

1513
01:04:36,850 --> 01:04:42,060
in the paper, if the friend
tracker defined some permission

1514
01:04:42,060 --> 01:04:46,080
with this signature type,
then only other applications

1515
01:04:46,080 --> 01:04:48,200
signed by the same
developer key are

1516
01:04:48,200 --> 01:04:51,190
going to be able to get
this signature permission.

1517
01:04:51,190 --> 01:04:52,580
What's the point of this thing?

1518
01:04:52,580 --> 01:04:56,817
Why not just make them
dangerous or, I don't know,

1519
01:04:56,817 --> 01:04:57,471
something else?

1520
01:04:57,471 --> 01:05:01,030
Why do we need a third type?

1521
01:05:01,030 --> 01:05:01,893
Any reason?

1522
01:05:01,893 --> 01:05:02,392
Yeah?

1523
01:05:02,392 --> 01:05:05,224
AUDIENCE: Operations
[INAUDIBLE] same developer?

1524
01:05:05,224 --> 01:05:05,890
PROFESSOR: Yeah.

1525
01:05:05,890 --> 01:05:08,560
So it might be that
this developer has

1526
01:05:08,560 --> 01:05:11,070
some internal APIs that
they don't actually mean

1527
01:05:11,070 --> 01:05:13,080
to expose to the outside world.

1528
01:05:13,080 --> 01:05:16,380
But they just want to couple
their own applications

1529
01:05:16,380 --> 01:05:17,130
to each other.

1530
01:05:17,130 --> 01:05:20,040
So maybe Facebook,
hypothetically,

1531
01:05:20,040 --> 01:05:22,125
could write multiple
applications.

1532
01:05:22,125 --> 01:05:24,930
They might have one
application that's

1533
01:05:24,930 --> 01:05:27,160
pre-fetching content
from Facebook servers,

1534
01:05:27,160 --> 01:05:29,956
another application that
fuses, another application that

1535
01:05:29,956 --> 01:05:30,830
tracks your location.

1536
01:05:30,830 --> 01:05:32,246
And they want all
these components

1537
01:05:32,246 --> 01:05:33,820
to interact with one another.

1538
01:05:33,820 --> 01:05:35,920
And they can define the
signature permission

1539
01:05:35,920 --> 01:05:37,220
to do this.

1540
01:05:37,220 --> 01:05:40,655
And presumably, one reason why
you might not want to do this--

1541
01:05:40,655 --> 01:05:43,110
might not want to
tag this permission

1542
01:05:43,110 --> 01:05:46,910
as a dangerous permission is
for mostly the same reasons

1543
01:05:46,910 --> 01:05:49,230
as the [INAUDIBLE]
was talking about,

1544
01:05:49,230 --> 01:05:52,936
which is that if you really know
who should be allowed to get

1545
01:05:52,936 --> 01:05:55,110
this permission, you don't
want to allow the user

1546
01:05:55,110 --> 01:05:56,290
to screw this up.

1547
01:05:56,290 --> 01:05:59,510
So the user could always
be tricked by someone--

1548
01:05:59,510 --> 01:06:02,346
or could be tricked by
someone into accepting

1549
01:06:02,346 --> 01:06:07,000
a malicious application that
asks for some permission that's

1550
01:06:07,000 --> 01:06:07,770
really dangerous.

1551
01:06:07,770 --> 01:06:08,970
But [? it doesn't ?]
need to be dangerous,

1552
01:06:08,970 --> 01:06:10,511
you could just define
this signature.

1553
01:06:10,511 --> 01:06:12,200
And the user doesn't
even have a choice

1554
01:06:12,200 --> 01:06:14,210
of giving away
some application's

1555
01:06:14,210 --> 01:06:15,895
internal privileges.

1556
01:06:15,895 --> 01:06:20,255
That's one nice thing
about this permission type.

1557
01:06:20,255 --> 01:06:20,755
Make sense?

1558
01:06:23,330 --> 01:06:24,747
So there's other
stuff associated

1559
01:06:24,747 --> 01:06:29,020
with the label that mostly
has to do with describing

1560
01:06:29,020 --> 01:06:30,700
the permission to the user.

1561
01:06:30,700 --> 01:06:34,530
So there's some sort
of a description here

1562
01:06:34,530 --> 01:06:38,220
that is the sort of
English-level explanation

1563
01:06:38,220 --> 01:06:40,280
of what this permission entails.

1564
01:06:40,280 --> 01:06:43,310
And it's this
description that pops up

1565
01:06:43,310 --> 01:06:45,940
when you're asked to
install a new application.

1566
01:06:45,940 --> 01:06:49,190
So the Android framework will
look through all the label

1567
01:06:49,190 --> 01:06:51,470
strings in the manifest
of the application you're

1568
01:06:51,470 --> 01:06:55,060
about to install, and display
to the user the descriptions

1569
01:06:55,060 --> 01:06:57,180
for all those labeled
strings, saying, OK,

1570
01:06:57,180 --> 01:07:00,060
you're about to give away the
privileges to dial your phone,

1571
01:07:00,060 --> 01:07:02,500
or you're about to give this
application the permission

1572
01:07:02,500 --> 01:07:06,122
to send SMS messages on
your behalf, et cetera.

1573
01:07:06,122 --> 01:07:09,600
That make sense?

1574
01:07:09,600 --> 01:07:10,350
All right.

1575
01:07:10,350 --> 01:07:15,120
So one interesting
question is, what

1576
01:07:15,120 --> 01:07:18,590
happens if a malicious
application defines

1577
01:07:18,590 --> 01:07:22,200
a label for some other app?

1578
01:07:22,200 --> 01:07:26,498
These labels are just
free-form strings.

1579
01:07:26,498 --> 01:07:28,830
So what happens if you're
a malicious application

1580
01:07:28,830 --> 01:07:31,560
and you say, oh, I have
this new, great permission.

1581
01:07:31,560 --> 01:07:32,680
It's called DIAL PERM.

1582
01:07:32,680 --> 01:07:33,915
And [INAUDIBLE] dangerous.

1583
01:07:33,915 --> 01:07:37,406
And the description
does nothing.

1584
01:07:37,406 --> 01:07:39,676
Is it good or [INAUDIBLE]?

1585
01:07:39,676 --> 01:07:40,560
Yeah?

1586
01:07:40,560 --> 01:07:45,090
AUDIENCE: So [INAUDIBLE]
domains [INAUDIBLE].

1587
01:07:47,814 --> 01:07:48,480
PROFESSOR: Yeah.

1588
01:07:48,480 --> 01:07:50,760
So you hope so.

1589
01:07:50,760 --> 01:07:52,960
Unfortunately, it's
not actually enforced.

1590
01:07:52,960 --> 01:07:56,200
So by convention, all
these permission strings

1591
01:07:56,200 --> 01:07:59,410
should have Java-style
reversed domain names.

1592
01:07:59,410 --> 01:08:02,550
But there's no
strict association

1593
01:08:02,550 --> 01:08:06,470
between the labels that
an application defines

1594
01:08:06,470 --> 01:08:09,353
and the application's
own Java-style name.

1595
01:08:09,353 --> 01:08:10,852
And for that matter,
there's nothing

1596
01:08:10,852 --> 01:08:13,380
that enforces that an
application's Java-style name

1597
01:08:13,380 --> 01:08:16,899
be tied to anything, because
we have no way of knowing

1598
01:08:16,899 --> 01:08:19,700
whether the public
[INAUDIBLE] developer signing

1599
01:08:19,700 --> 01:08:21,200
a particular
application corresponds

1600
01:08:21,200 --> 01:08:25,720
to com.google.something
or edu.mit.something.

1601
01:08:25,720 --> 01:08:28,830
So in fact, one slight
weakness in Android

1602
01:08:28,830 --> 01:08:32,529
that was there at least when
I checked a while ago-- it

1603
01:08:32,529 --> 01:08:36,194
probably is still there-- is
that the label definitions are

1604
01:08:36,194 --> 01:08:37,569
sort of first
come, first served.

1605
01:08:37,569 --> 01:08:39,684
So when you first
install an application,

1606
01:08:39,684 --> 01:08:41,720
it defines a
particular label, you

1607
01:08:41,720 --> 01:08:44,330
get to decide what type
that label string is

1608
01:08:44,330 --> 01:08:47,100
and what is the description
of this label string.

1609
01:08:47,100 --> 01:08:51,510
So for system permissions, this
is probably not a big problem,

1610
01:08:51,510 --> 01:08:54,109
because the system
permissions, or the ones

1611
01:08:54,109 --> 01:08:56,140
for built-in applications
like [? compiler, ?]

1612
01:08:56,140 --> 01:08:58,225
get defined first.

1613
01:08:58,225 --> 01:09:01,600
But applications that come later
are unable to redefine them.

1614
01:09:01,600 --> 01:09:04,410
So at least the
framework enforces that.

1615
01:09:04,410 --> 01:09:07,229
But certainly, one bummer
is that if you install

1616
01:09:07,229 --> 01:09:08,870
a malicious application
first and then

1617
01:09:08,870 --> 01:09:11,922
some important
application later,

1618
01:09:11,922 --> 01:09:13,630
the malicious application
can potentially

1619
01:09:13,630 --> 01:09:17,724
subvert the labels used by
the later well-meaning app.

1620
01:09:17,724 --> 01:09:20,340
So in the paper's
FRIEND VIEWER example,

1621
01:09:20,340 --> 01:09:23,370
you could actually-- if you're
a malicious developer, you could

1622
01:09:23,370 --> 01:09:26,015
first trick the
user into installing

1623
01:09:26,015 --> 01:09:28,069
these applications defines
this FRIEND [? VIEW ?]

1624
01:09:28,069 --> 01:09:31,729
permission to be a normal
permission with a description

1625
01:09:31,729 --> 01:09:34,580
stream saying, oh, this does
nothing interesting at all.

1626
01:09:34,580 --> 01:09:37,849
And then the FRIEND VIEWER
applet gets installed later.

1627
01:09:37,849 --> 01:09:39,500
It can't redefine this label.

1628
01:09:39,500 --> 01:09:40,899
It's already been defined.

1629
01:09:40,899 --> 01:09:46,320
And consequently might
be unable to prevent

1630
01:09:46,320 --> 01:09:48,170
the user from giving
away this FRIEND VIEW

1631
01:09:48,170 --> 01:09:50,403
permission to other apps.

1632
01:09:50,403 --> 01:09:52,819
AUDIENCE: [INAUDIBLE].

1633
01:09:52,819 --> 01:09:55,800
PROFESSOR: Well, in principle,
the framework could do this.

1634
01:09:55,800 --> 01:09:57,910
When I tried this, you
don't get warned at all.

1635
01:09:57,910 --> 01:10:00,980
So if you install
an application that

1636
01:10:00,980 --> 01:10:04,770
defines a label that's already
been defined, it does nothing.

1637
01:10:04,770 --> 01:10:07,360
It simply ignores the
VIEW label definition

1638
01:10:07,360 --> 01:10:09,401
and uses the old one.

1639
01:10:09,401 --> 01:10:11,650
Perhaps that's the problem
where it really goes wrong.

1640
01:10:11,650 --> 01:10:13,275
You should at least
say, well, I refuse

1641
01:10:13,275 --> 01:10:15,358
to install this application,
because it's defining

1642
01:10:15,358 --> 01:10:16,640
a label that already exists.

1643
01:10:16,640 --> 01:10:18,554
AUDIENCE: Owned by
this other application.

1644
01:10:18,554 --> 01:10:19,220
PROFESSOR: Yeah.

1645
01:10:19,220 --> 01:10:21,100
And it's owned by a
different key even.

1646
01:10:21,100 --> 01:10:21,600
Yeah.

1647
01:10:21,600 --> 01:10:24,570
So at least there's a chance
to fix this potentially.

1648
01:10:24,570 --> 01:10:27,780
I haven't seen this
fixed yet, but maybe I've

1649
01:10:27,780 --> 01:10:30,006
not been keeping track of it.

1650
01:10:30,006 --> 01:10:30,950
Anyway.

1651
01:10:30,950 --> 01:10:32,759
So that's kind of an
interesting problem

1652
01:10:32,759 --> 01:10:34,800
that you really have to
keep track of these names

1653
01:10:34,800 --> 01:10:39,320
and figure out who owns a
name and getting that right

1654
01:10:39,320 --> 01:10:41,880
is actually quite important.

1655
01:10:41,880 --> 01:10:45,090
So one interesting problem
that shows up in Android

1656
01:10:45,090 --> 01:10:48,470
has to do with these broadcast
receivers or sort of sending

1657
01:10:48,470 --> 01:10:51,382
messages between applications.

1658
01:10:51,382 --> 01:10:54,529
So one interesting problem is
when you're sending-- well,

1659
01:10:54,529 --> 01:10:56,820
I guess I should first describe
how these messages work

1660
01:10:56,820 --> 01:10:58,350
with broadcast receivers.

1661
01:10:58,350 --> 01:11:02,860
So broadcast receivers are
used for one application

1662
01:11:02,860 --> 01:11:04,970
being able to
announce some event

1663
01:11:04,970 --> 01:11:07,370
to every other
application in the system.

1664
01:11:07,370 --> 01:11:09,550
So as we saw before,
intents typically

1665
01:11:09,550 --> 01:11:12,960
go to a particular component,
like view a JPEG image.

1666
01:11:12,960 --> 01:11:16,785
But for some events,
like, the system boots up.

1667
01:11:16,785 --> 01:11:18,990
Or my friends are nearby.

1668
01:11:18,990 --> 01:11:21,440
You might want to announce
this to every application that

1669
01:11:21,440 --> 01:11:22,475
cares.

1670
01:11:22,475 --> 01:11:25,200
And this is what these
broadcast receivers are for.

1671
01:11:25,200 --> 01:11:28,470
But you actually
start worrying when

1672
01:11:28,470 --> 01:11:31,820
you have these messages being
sent between two applications,

1673
01:11:31,820 --> 01:11:34,470
both in the broadcast receiver
case and in other cases,

1674
01:11:34,470 --> 01:11:36,230
you probably care
about two things.

1675
01:11:36,230 --> 01:11:38,120
You might want to
authenticate where

1676
01:11:38,120 --> 01:11:39,510
the message is coming from.

1677
01:11:39,510 --> 01:11:41,260
So you want to know
who sent this message.

1678
01:11:41,260 --> 01:11:42,300
Can I trust them?

1679
01:11:42,300 --> 01:11:44,250
And also, you want to
potentially control

1680
01:11:44,250 --> 01:11:45,710
where this message
goes to-- who is

1681
01:11:45,710 --> 01:11:48,000
able to receive this message.

1682
01:11:48,000 --> 01:11:51,980
And initially, it seems like
an Android device didn't quite

1683
01:11:51,980 --> 01:11:56,750
get these things quite
correctly in several ways.

1684
01:11:56,750 --> 01:12:03,020
In particular, the
broadcast receivers--

1685
01:12:03,020 --> 01:12:07,010
well, if you are sending
a broadcast message

1686
01:12:07,010 --> 01:12:11,210
to all the other
components in your system,

1687
01:12:11,210 --> 01:12:13,320
I think in the initial
version of Android,

1688
01:12:13,320 --> 01:12:14,580
you just sent this message.

1689
01:12:14,580 --> 01:12:17,060
And other applications could
either subscribe or not

1690
01:12:17,060 --> 01:12:19,450
subscribe to these messages.

1691
01:12:19,450 --> 01:12:22,100
So if you have a FRIEND
VIEWER application that it'll

1692
01:12:22,100 --> 01:12:25,450
subscribe to these messages
by setting the right action

1693
01:12:25,450 --> 01:12:30,290
or date or data time or MIME
type in their Intent filter,

1694
01:12:30,290 --> 01:12:32,910
but most applications
could always

1695
01:12:32,910 --> 01:12:34,970
subscribe to all broadcast
events in the system.

1696
01:12:34,970 --> 01:12:36,470
And you are able
to watch everything

1697
01:12:36,470 --> 01:12:38,632
that's going on on the
phone, or everything

1698
01:12:38,632 --> 01:12:40,340
that's being broadcast.

1699
01:12:40,340 --> 01:12:44,630
So the Android framework added
an extra sort of argument

1700
01:12:44,630 --> 01:12:46,790
for applications to
be able to specify

1701
01:12:46,790 --> 01:12:49,200
who should be able to
see a broadcast message.

1702
01:12:49,200 --> 01:12:55,070
So when you're sending
a broadcast message,

1703
01:12:55,070 --> 01:12:58,630
there's the obvious
argument, which

1704
01:12:58,630 --> 01:13:01,570
is the message you want to send,
which is basically an intent.

1705
01:13:01,570 --> 01:13:04,540
But then you can also
specify an optional label

1706
01:13:04,540 --> 01:13:09,130
that describes who should be
able to receive this message.

1707
01:13:09,130 --> 01:13:11,540
So instead of broadcasting
to everyone in the system,

1708
01:13:11,540 --> 01:13:13,800
you can say, well, only
other applications that

1709
01:13:13,800 --> 01:13:16,770
have a certain permission
should be able to receive

1710
01:13:16,770 --> 01:13:20,290
this broadcast message from me.

1711
01:13:20,290 --> 01:13:23,660
So this way, you could send
out sensitive information,

1712
01:13:23,660 --> 01:13:25,570
like the locations
of your friends,

1713
01:13:25,570 --> 01:13:28,530
in the paper's
example, and make sure

1714
01:13:28,530 --> 01:13:31,230
that only those
applications that

1715
01:13:31,230 --> 01:13:33,380
are allowed to see the
list of your friends

1716
01:13:33,380 --> 01:13:35,777
will actually get your
broadcast message.

1717
01:13:35,777 --> 01:13:37,610
So this is how, on
Android, you can actually

1718
01:13:37,610 --> 01:13:42,060
control who receives the
message that you're sending out,

1719
01:13:42,060 --> 01:13:44,620
at least in the broadcast case.

1720
01:13:44,620 --> 01:13:45,470
Question?

1721
01:13:45,470 --> 01:13:47,755
No. [? Sorry. ?]

1722
01:13:47,755 --> 01:13:49,880
How do you authenticate
where a message is actually

1723
01:13:49,880 --> 01:13:50,470
coming from?

1724
01:13:50,470 --> 01:13:55,150
So suppose that in
Android, you register

1725
01:13:55,150 --> 01:13:58,796
for-- in the paper's example,
you have your FRIEND VIEWER

1726
01:13:58,796 --> 01:14:00,170
and you receive
a message saying,

1727
01:14:00,170 --> 01:14:02,800
yep, this friend is nearby.

1728
01:14:02,800 --> 01:14:07,830
How do you know this actually
came from the right component?

1729
01:14:07,830 --> 01:14:09,760
Can you actually convince
yourself of this?

1730
01:14:09,760 --> 01:14:10,260
Yeah?

1731
01:14:10,260 --> 01:14:13,092
AUDIENCE: Using
the kernel codes?

1732
01:14:13,092 --> 01:14:14,892
Wouldn't you trust the
kernel [INAUDIBLE]?

1733
01:14:14,892 --> 01:14:16,100
PROFESSOR: Potentially, yeah.

1734
01:14:19,100 --> 01:14:21,725
Well, this binder thing is going
to tell the reference monitor,

1735
01:14:21,725 --> 01:14:23,110
here's where the
intent came from.

1736
01:14:23,110 --> 01:14:24,485
And then the
reference monitor is

1737
01:14:24,485 --> 01:14:27,070
going to forward this intent
to your receiver application.

1738
01:14:27,070 --> 01:14:28,540
And somewhere in
there is the name

1739
01:14:28,540 --> 01:14:30,910
of the applet that
sent this guy.

1740
01:14:30,910 --> 01:14:32,587
How should you
check whether this

1741
01:14:32,587 --> 01:14:38,220
is a reasonable app that should
be sending these intents?

1742
01:14:38,220 --> 01:14:41,565
Is there a way to
do this in Android?

1743
01:14:41,565 --> 01:14:42,440
I guess you're right.

1744
01:14:42,440 --> 01:14:44,940
Strictly speaking, yeah, the
source is always authenticated.

1745
01:14:44,940 --> 01:14:47,230
You know exactly which
app sent the message.

1746
01:14:47,230 --> 01:14:49,050
But what do you do
with a source name?

1747
01:14:49,050 --> 01:14:51,190
How do you check whether
it should be sending

1748
01:14:51,190 --> 01:14:53,520
these Friend is Near messages?

1749
01:14:53,520 --> 01:14:54,430
[INAUDIBLE]

1750
01:14:54,430 --> 01:14:54,930
Yeah?

1751
01:14:54,930 --> 01:14:58,024
AUDIENCE: [INAUDIBLE]
label [INAUDIBLE].

1752
01:14:58,024 --> 01:14:58,690
PROFESSOR: Yeah.

1753
01:14:58,690 --> 01:15:02,240
So one way to do it
is to actually stick

1754
01:15:02,240 --> 01:15:04,310
a label on the
broadcast receiver.

1755
01:15:04,310 --> 01:15:07,420
So one thing you could is say,
well, the only people that

1756
01:15:07,420 --> 01:15:10,295
are allowed to send a message
to the broadcast receiver

1757
01:15:10,295 --> 01:15:20,320
are people with the Friend
Tracker maybe label.

1758
01:15:20,320 --> 01:15:23,430
So if you stick such a label
on your broadcast receiver,

1759
01:15:23,430 --> 01:15:27,583
then you know that only
messages sent from applications

1760
01:15:27,583 --> 01:15:30,880
with this label are going to get
to you through your broadcast

1761
01:15:30,880 --> 01:15:31,460
receiver.

1762
01:15:31,460 --> 01:15:35,700
That's one way to filter who's
able to send messages to you is

1763
01:15:35,700 --> 01:15:38,210
by restricting them by label.

1764
01:15:38,210 --> 01:15:41,080
So this works in many cases.

1765
01:15:41,080 --> 01:15:46,020
Android also provides a
more specific function

1766
01:15:46,020 --> 01:15:47,914
that you can use.

1767
01:15:47,914 --> 01:15:49,080
It's called Check Privilege.

1768
01:15:55,810 --> 01:15:58,700
And you could sort of say--
or Check Sender Privilege,

1769
01:15:58,700 --> 01:15:59,560
I think.

1770
01:15:59,560 --> 01:16:04,070
And you could ask the
framework whether the sender

1771
01:16:04,070 --> 01:16:07,450
of the intent you're looking
at has a certain label

1772
01:16:07,450 --> 01:16:08,990
in its provisions.

1773
01:16:08,990 --> 01:16:12,960
So this way, you can also
reason about what privileges

1774
01:16:12,960 --> 01:16:15,252
does the sender of
a particular message

1775
01:16:15,252 --> 01:16:18,220
have in situations where maybe
the framework doesn't provide

1776
01:16:18,220 --> 01:16:23,130
quite the right mechanisms
in the manifest to do this.

1777
01:16:23,130 --> 01:16:27,070
One place where this Check
Sender Privilege function

1778
01:16:27,070 --> 01:16:28,880
turns out to be
particularly useful

1779
01:16:28,880 --> 01:16:31,480
is in the case of this RPC
interaction between two

1780
01:16:31,480 --> 01:16:33,630
applications, where the
reference monitor isn't

1781
01:16:33,630 --> 01:16:37,640
actually involved in mediating
the RPC-looking applications.

1782
01:16:37,640 --> 01:16:40,310
But you still want to
ask, is the application

1783
01:16:40,310 --> 01:16:43,910
of [INAUDIBLE] privileged
for this kind of operation?

1784
01:16:43,910 --> 01:16:48,120
So this way, you can
manually invoke-- or check

1785
01:16:48,120 --> 01:16:51,382
what's in the manifest
of an application.

1786
01:16:51,382 --> 01:16:51,882
Yeah.

1787
01:16:51,882 --> 01:16:52,864
AUDIENCE: [INAUDIBLE].

1788
01:16:56,800 --> 01:17:00,009
PROFESSOR: Well, so I
guess-- [INAUDIBLE].

1789
01:17:00,009 --> 01:17:02,050
AUDIENCE: You can use the
signature to enable it.

1790
01:17:02,050 --> 01:17:03,716
PROFESSOR: Yeah, so
one thing that stops

1791
01:17:03,716 --> 01:17:05,376
is presumably the [INAUDIBLE].

1792
01:17:05,376 --> 01:17:07,000
If the label is a
signature type label,

1793
01:17:07,000 --> 01:17:09,272
then that's going to stop
it if it's not [INAUDIBLE].

1794
01:17:09,272 --> 01:17:11,230
AUDIENCE: That requires
the same signature as--

1795
01:17:11,230 --> 01:17:12,170
PROFESSOR: That's right.

1796
01:17:12,170 --> 01:17:12,640
Yeah, yeah.

1797
01:17:12,640 --> 01:17:14,690
So that requires it be
the same, exact developer.

1798
01:17:14,690 --> 01:17:18,040
Another thing that stops it is
that maybe the permission is

1799
01:17:18,040 --> 01:17:19,231
labelled as Dangerous.

1800
01:17:19,231 --> 01:17:21,480
So then the user is going
to see this on their screen.

1801
01:17:21,480 --> 01:17:23,900
When you install an
app, it says, this app

1802
01:17:23,900 --> 01:17:26,380
requires the permission
of viewing your friends,

1803
01:17:26,380 --> 01:17:27,600
or your friends' locations.

1804
01:17:27,600 --> 01:17:29,016
AUDIENCE: But that's taken
from the description.

1805
01:17:29,016 --> 01:17:29,960
PROFESSOR: That's right.

1806
01:17:29,960 --> 01:17:31,959
AUDIENCE: So what's
[INAUDIBLE] from just giving

1807
01:17:31,959 --> 01:17:33,270
a different description?

1808
01:17:33,270 --> 01:17:38,410
PROFESSOR: So I should
say, this description

1809
01:17:38,410 --> 01:17:41,760
comes from the application that
initially defines this label.

1810
01:17:41,760 --> 01:17:46,517
So the label is initially--
so there's two things going on

1811
01:17:46,517 --> 01:17:47,312
in the manifest.

1812
01:17:47,312 --> 01:17:51,429
You can ask for access
to existing labels.

1813
01:17:51,429 --> 01:17:53,220
So I can say, well,
this is an application.

1814
01:17:53,220 --> 01:17:56,164
I want access to the
FRIEND VIEW permission.

1815
01:17:56,164 --> 01:17:58,550
And a separate thing you can
do in the manifest is say,

1816
01:17:58,550 --> 01:18:01,450
I am defining a
new kind of label.

1817
01:18:01,450 --> 01:18:04,054
So then the first Friend
Viewer application--

1818
01:18:04,054 --> 01:18:06,295
or the Friend Tracker
application, presumably,

1819
01:18:06,295 --> 01:18:08,170
is going to say, well,
I have an application,

1820
01:18:08,170 --> 01:18:09,170
it has these permission.

1821
01:18:09,170 --> 01:18:11,770
But also, I'm defining
a new kind of label.

1822
01:18:11,770 --> 01:18:13,520
It's called this.

1823
01:18:13,520 --> 01:18:16,750
It's type Dangerous, and
it has this description.

1824
01:18:16,750 --> 01:18:19,774
So that's a place where
you have to really get

1825
01:18:19,774 --> 01:18:22,630
the-- this is that first
come, first served problem.

1826
01:18:22,630 --> 01:18:25,714
But as long as the application
that should define the label

1827
01:18:25,714 --> 01:18:27,630
is installed first, then
you're in good shape.

1828
01:18:27,630 --> 01:18:30,810
Any subsequent application
is going to ask for the label

1829
01:18:30,810 --> 01:18:32,806
just by its string name.

1830
01:18:32,806 --> 01:18:34,750
And then the Android
framework will fish out

1831
01:18:34,750 --> 01:18:37,260
the description and the
type from the application

1832
01:18:37,260 --> 01:18:39,081
that first defined it.

1833
01:18:42,930 --> 01:18:43,605
All right.

1834
01:18:43,605 --> 01:18:47,370
Any other questions here?

1835
01:18:47,370 --> 01:18:48,430
All right.

1836
01:18:48,430 --> 01:18:52,790
So I guess this gives you some
sense of how Android works.

1837
01:18:52,790 --> 01:18:56,700
So one cool thing about it
is that you can actually

1838
01:18:56,700 --> 01:18:58,960
get this manifest that,
to a larger extent,

1839
01:18:58,960 --> 01:19:01,800
describes the security
properties of an application.

1840
01:19:01,800 --> 01:19:04,230
So this is one thing that
the developers of the Android

1841
01:19:04,230 --> 01:19:06,021
framework were going
for-- something called

1842
01:19:06,021 --> 01:19:09,260
mandatory access control,
where you can actually specify

1843
01:19:09,260 --> 01:19:12,520
the security policy of
an application separate

1844
01:19:12,520 --> 01:19:14,690
from the application
itself, and in fact,

1845
01:19:14,690 --> 01:19:17,160
have that security policy be
enforced by this reference

1846
01:19:17,160 --> 01:19:21,190
monitor regardless of what that
application itself is doing.

1847
01:19:21,190 --> 01:19:23,000
So it seems like kind
of a nice property

1848
01:19:23,000 --> 01:19:25,140
to be able to audit an
application by looking

1849
01:19:25,140 --> 01:19:27,590
at this manifest file.

1850
01:19:27,590 --> 01:19:31,216
You can mostly think of it as a
development nicety rather than

1851
01:19:31,216 --> 01:19:33,590
a strict enforcement mechanism,
because if an application

1852
01:19:33,590 --> 01:19:35,740
really wants to get
around its own manifest,

1853
01:19:35,740 --> 01:19:37,740
it can probably do so.

1854
01:19:37,740 --> 01:19:39,476
But it seems like
a nice way of being

1855
01:19:39,476 --> 01:19:42,100
able to understand what's going
on with an application in terms

1856
01:19:42,100 --> 01:19:45,505
of security without having to
dive down into the Java code.

1857
01:19:45,505 --> 01:19:47,790
Of course, it matters,
but you can still

1858
01:19:47,790 --> 01:19:50,660
get a high-level sense of what's
going on in an application

1859
01:19:50,660 --> 01:19:52,920
from the manifest.

1860
01:19:52,920 --> 01:19:55,320
One bummer, I guess, as we
were talking about here,

1861
01:19:55,320 --> 01:19:58,515
there are some situations where
the Android framework turns out

1862
01:19:58,515 --> 01:20:01,450
to be not quite expressive
enough in the manifest.

1863
01:20:01,450 --> 01:20:03,540
And you have to
still write code that

1864
01:20:03,540 --> 01:20:05,260
talks about security checks.

1865
01:20:05,260 --> 01:20:07,802
It would be, in some ways,
nice if there were no security

1866
01:20:07,802 --> 01:20:10,010
checks at all in the code
and all the security checks

1867
01:20:10,010 --> 01:20:11,245
went to the manifest.

1868
01:20:11,245 --> 01:20:14,410
But that would mean exposing
things like all the RPCs

1869
01:20:14,410 --> 01:20:16,706
to the framework and so on.

1870
01:20:16,706 --> 01:20:18,330
That's potentially
a bit of a trade-off

1871
01:20:18,330 --> 01:20:19,787
that these guys are making.

1872
01:20:19,787 --> 01:20:21,620
And I guess one other
thing is it's actually

1873
01:20:21,620 --> 01:20:23,750
kind of hard to change
the manifest file

1874
01:20:23,750 --> 01:20:25,890
after you design the system.

1875
01:20:25,890 --> 01:20:28,020
So one perhaps
surprising thing is

1876
01:20:28,020 --> 01:20:29,950
that the Android
framework hasn't changed

1877
01:20:29,950 --> 01:20:32,220
in terms of security very
much since it was released

1878
01:20:32,220 --> 01:20:34,470
or since this paper was
written five years ago, or six

1879
01:20:34,470 --> 01:20:36,090
years ago now.

1880
01:20:36,090 --> 01:20:38,500
Because once the application
starts using this framework,

1881
01:20:38,500 --> 01:20:41,816
it's hard to say some existing
application's going to break.

1882
01:20:41,816 --> 01:20:43,190
So you basically
have to maintain

1883
01:20:43,190 --> 01:20:44,940
backwards compatibility
to a large extent.

1884
01:20:44,940 --> 01:20:49,349
So you don't get a chance
to sort of do it over again.

1885
01:20:49,349 --> 01:20:50,765
I guess one
interesting thing that

1886
01:20:50,765 --> 01:20:53,710
did happen to Android
since this paper came out

1887
01:20:53,710 --> 01:20:59,220
is that the Android guys
borrowed an idea from Apple

1888
01:20:59,220 --> 01:21:01,410
and are doing now much
more server-side analysis

1889
01:21:01,410 --> 01:21:02,840
of applications.

1890
01:21:02,840 --> 01:21:06,310
So Apple, on the iPhone side,
is pretty aggressive in terms

1891
01:21:06,310 --> 01:21:11,600
of having the Apple server
checking all the applications

1892
01:21:11,600 --> 01:21:13,590
from developers for
various guidelines,

1893
01:21:13,590 --> 01:21:15,260
including security properties.

1894
01:21:15,260 --> 01:21:19,460
And the Android servers, or
this Android market or whatever,

1895
01:21:19,460 --> 01:21:21,920
now also does quite a bit
of analysis of applications

1896
01:21:21,920 --> 01:21:24,540
submitted by developers
to make sure they are not

1897
01:21:24,540 --> 01:21:27,010
malicious in some loose sense.

1898
01:21:27,010 --> 01:21:28,430
So that's kind of a cool thing.

1899
01:21:28,430 --> 01:21:30,590
And it is largely
[? orthogonal ?]

1900
01:21:30,590 --> 01:21:32,020
to this security architecture.

1901
01:21:32,020 --> 01:21:33,560
So this security architecture
works on your phone.

1902
01:21:33,560 --> 01:21:35,410
But then for any other
security problems,

1903
01:21:35,410 --> 01:21:39,990
the server can evolve
defenses over time as need be.

1904
01:21:39,990 --> 01:21:42,560
And those tend to be more
on the phishing side, where

1905
01:21:42,560 --> 01:21:44,518
the human is being tricked
into doing something

1906
01:21:44,518 --> 01:21:46,910
rather than on exploiting
some specific vulnerability

1907
01:21:46,910 --> 01:21:49,290
in the kernel,
perhaps, and so on.

1908
01:21:49,290 --> 01:21:51,320
Make sense?

1909
01:21:51,320 --> 01:21:52,890
Any other questions?

1910
01:21:52,890 --> 01:21:53,390
All right.

1911
01:21:53,390 --> 01:21:55,306
So we'll see you guys
on Wednesday, hopefully.

1912
01:21:55,306 --> 01:21:59,510
We'll talk about an extension
of Android for data privacy.