1
00:00:00,500 --> 00:00:02,550
Android App沙盒做了一件很伟大的工作 The Android App Sandbox does a great job

2
00:00:02,550 --> 00:00:04,300
那就是默认保持app之间相对独立 of keeping apps separate by default.

3
00:00:04,300 --> 00:00:06,780
但是当提供的隔离等级 But what can you do when the provided level of isolation

4
00:00:06,780 --> 00:00:09,170
和应用模型不和呢 doesn't match your application's model?

5
00:00:09,170 --> 00:00:11,250
Hi  我是Geremy Condra  在这个视频中 Hi, I'm Geremy Condra, and in this video,

6
00:00:11,250 --> 00:00:13,750
我们将讨论你该如何用Android平台来 we'll be talking about how you can use the Android Platform

7
00:00:13,750 --> 00:00:16,040
支持不同的隔离模型 Support for different isolation models

8
00:00:16,040 --> 00:00:19,510
使你的应用更加强大和安全 to make your app more robust and more secure.

9
00:00:19,510 --> 00:00:21,440
你看到的是一些Android提供的 What you see here is a loose model of some

10
00:00:21,440 --> 00:00:23,390
最重要的隔离层的 of the most important layers of isolation

11
00:00:23,390 --> 00:00:26,060
宽松模型  SELinux保护 Android provides-- SELinux protections

12
00:00:26,060 --> 00:00:28,930
系统组件中独立的应用 that separate applications from system components.

13
00:00:28,930 --> 00:00:31,090
你可以看到Linux用户  一个分离的UID You see Linux User, a UID separation,

14
00:00:31,090 --> 00:00:33,360
用来保持应用分离开来 which keeps separate apps separate.

15
00:00:33,360 --> 00:00:37,320
你还可以看到应用组件之间进程等级的分离 And you see the process level separation between app components.

16
00:00:37,320 --> 00:00:40,800
所以  让我们来讨论进程中的分离 So let's start off talking about process separation.

17
00:00:40,800 --> 00:00:42,480
当Zygote产出一个应用时 When Zygote spawns an application,

18
00:00:42,480 --> 00:00:45,400
这些应用通常都会有自己的进程 that application generally gets its own process.

19
00:00:45,400 --> 00:00:47,860
这防止别的应用来修改这个应用的内存 This prevents other applications from modifying its memory

20
00:00:47,860 --> 00:00:51,225
在另一方面把一个应用和崩溃隔离开来 and isolates one app against a crash in another.

21
00:00:51,225 --> 00:00:53,600
所以事实就是当你的应用和其他一些糟糕的应用在 So the fact that your app and someone else's terrible app

22
00:00:53,600 --> 00:00:57,970
同一个手机上的时候这并不影响你的应用的体验 are on the same phone doesn't impact your app's experience.

23
00:00:57,970 --> 00:01:00,690
它也让应用和系统组件隔离 It also isolates the application from system components

24
00:01:00,690 --> 00:01:03,690
同时系统组件之间也是隔离的 and system components from each other.

25
00:01:03,690 --> 00:01:05,349
稍微放大一点  我们可以看到 Zooming in a little bit, we can see

26
00:01:05,349 --> 00:01:07,330
这两个app虽然不共享一个进程 that two apps which don't share a process

27
00:01:07,330 --> 00:01:10,610
但却能用一些方式来交流  例如binder can still communicate in a variety of ways, such as binder

28
00:01:10,610 --> 00:01:14,992
或者是向系统发送intent  或者通过旧的机制像Pipe或者是Socket or the intent system, or over legacy mechanisms like pipes or sockets.

29
00:01:14,992 --> 00:01:16,450
不共享一个进程的原因是 The thing to take away from this is

30
00:01:16,450 --> 00:01:19,000
进程的分离并不是很严格 that process separation isn't very restrictive.

31
00:01:19,000 --> 00:01:21,270
当你仍然可以跨过这些边界来交流的时候 Since you can still talk across these boundaries,

32
00:01:21,270 --> 00:01:24,449
你就可以用小的开销来获得好的隔离效果 it's easy to get good isolation with little cost.

33
00:01:24,449 --> 00:01:26,740
当然了  当我们在这里讨论隔离模型的时候 And of course, when we're talking about isolation here,

34
00:01:26,740 --> 00:01:29,370
我们真正的意思是  当一个进程死亡或是 what we really mean is that if one process dies or gets

35
00:01:29,370 --> 00:01:33,580
被破坏  其他的进程依然可以正确运行 compromised, other processes can continue to run correctly.

36
00:01:33,580 --> 00:01:34,890
所以  这就是默认的模型 So that's the default model.

37
00:01:34,890 --> 00:01:37,612
这对种类繁多的应用来说非常好 And it's a good one for a huge variety of apps.

38
00:01:37,612 --> 00:01:39,820
但是当基础模型不能提供你需要的隔离模型 But what happens if that basic model doesn't give you

39
00:01:39,820 --> 00:01:41,570
的时候会发生什么 the isolation you need?

40
00:01:41,570 --> 00:01:44,270
当你想从另一部分隔离你应用的一部分的时候 What do you do when you want to isolate one part of your app

41
00:01:44,270 --> 00:01:46,287
你会怎么做  比如当你想从crashy service from another-- like, say, a crashy service

42
00:01:46,287 --> 00:01:48,370
或者是一个network-aware组件中隔离持有秘钥或者是 or a network-aware component-- from something that

43
00:01:48,370 --> 00:01:50,740
其他敏感数据的应用的时候你会怎么做 handles keys or other sensitive data?

44
00:01:50,740 --> 00:01:53,410
幸运的是  Android很懂你 Fortunately, Android's got your back.

45
00:01:53,410 --> 00:01:57,280
Activities和服务都支持Android进程属性 Activities and services both support the Android process attribute.

46
00:01:57,280 --> 00:01:59,470
这将允许你指定你想把你的代码 This allows you to specify exactly what process

47
00:01:59,470 --> 00:02:01,886
运行在什么进程里 然后它可以为该组件 you want to run your code in and getting a new one spawned

48
00:02:01,886 --> 00:02:04,560
生出新的进程  如果进程不存在的话 for that component if it doesn't already exist.

49
00:02:04,560 --> 00:02:06,060
在这里例子里  我们有一个服务 In this example, we have the service

50
00:02:06,060 --> 00:02:09,119
如果它崩溃了而我们不想要关闭其他的应用 that we don't want taking down the rest of our app if it crashes.

51
00:02:09,119 --> 00:02:11,660
通过指定它应该在一个叫做colon crashy的进程中运行 By specifying that it should be run in a process called colon

52
00:02:11,660 --> 00:02:14,490
我们确保Android会把这个服务运行 crashy, we make sure that Android will run the service

53
00:02:14,490 --> 00:02:18,130
在一个专门为此创建新进程中 in a new process created explicitly for this purpose.

54
00:02:18,130 --> 00:02:19,970
一旦你完成这些  这个进程集合 Once you're done, the set of processes

55
00:02:19,970 --> 00:02:22,120
就会更像这样 looks a little more like this.

56
00:02:22,120 --> 00:02:25,050
因为colon crashy和应用处理器是分开的 Because colon crashy and the app processor are separate,

57
00:02:25,050 --> 00:02:28,730
crashy可以关闭然而并不需要关闭其他的应用 crashy can go down and not take down the rest of the app.

58
00:02:28,730 --> 00:02:31,440
你可以用它来更好地限制你的进程间通信(Inter-Process Communication)的端点 You can also use this to better restrict your IPC endpoint.

59
00:02:31,440 --> 00:02:33,380
在这个模型中  colon crashy并不需要 In this model, colon crashy won't wind up

60
00:02:33,380 --> 00:02:38,660
其他组件来间接向进程间通信端点交流 indirectly talking to the IPC endpoints needed by other components.

61
00:02:38,660 --> 00:02:40,880
为什么我们需要其他的隔离层 So why do we need the other layers of isolation?

62
00:02:40,880 --> 00:02:43,425
为什么不直接用进程来做所有事情 Why not just use processes for everything?

63
00:02:43,425 --> 00:02:45,800
我们不用进程分离做所有事是因为 The reason we don't use process separation for everything

64
00:02:45,800 --> 00:02:47,758
它没有一套不同的 is because it doesn't come with a different set

65
00:02:47,758 --> 00:02:49,204
永久的凭证 of persistent credentials.

66
00:02:49,204 --> 00:02:50,620
所以其他进程也许不能 So while another process might not

67
00:02:50,620 --> 00:02:53,287
修改你的内存  如果它拥有一样的UID be able to modify your memory, if it has the same UID,

68
00:02:53,287 --> 00:02:54,870
但是它仍拥有同样的权限 it'll have the same permissions, it'll

69
00:02:54,870 --> 00:02:57,940
它有读和写同样的文件的权利  等等 be able to read and write the same files, et cetera.

70
00:02:57,940 --> 00:02:59,670
结论就是  除了被进程边界 As a result, besides being separated

71
00:02:59,670 --> 00:03:01,870
分开  Android应用程序 by process boundaries, Android applications

72
00:03:01,870 --> 00:03:04,850
通常也作为他们自己的用户运行 are also generally run as their own user.

73
00:03:04,850 --> 00:03:06,800
这构成了App沙盒的基础 This forms the basis for the App Sandbox,

74
00:03:06,800 --> 00:03:10,330
以及应用程序主目录之间的分离 as well as the separation between application home directories.

75
00:03:10,330 --> 00:03:13,290
如此  Android提供了一个kernel-enforced guarantee In this way, Android provides a kernel-enforced guarantee

76
00:03:13,290 --> 00:03:14,980
那就是应用程序的数据只能 that the application's data can only

77
00:03:14,980 --> 00:03:19,255
被自己修改  除非这个应用允许其他程序来修改 be modified by that application, unless the app decides otherwise.

78
00:03:19,255 --> 00:03:23,236
这无疑使应用程序更加灵活和可控制 This gives a ton of flexibility and control to the application.

79
00:03:23,236 --> 00:03:25,610
这个规则有两个例外  那就是每个应用都有自己的 There are two exceptions to this rule that every app gets

80
00:03:25,610 --> 00:03:29,410
共享UID和隔离进程 its own UID-- shared UID and isolated process.

81
00:03:29,410 --> 00:03:32,010
让我们先讨论一下共享UID Let's talk about shared UID first.

82
00:03:32,010 --> 00:03:35,060
在这个图表中  应用B和C被标记了共享UID In this diagram, apps B and C are marked shared UID,

83
00:03:35,060 --> 00:03:36,940
应用A则没有 while app A is not.

84
00:03:36,940 --> 00:03:39,060
应用程序被标记共享UID并使用 Applications marked shared UID and signed

85
00:03:39,060 --> 00:03:42,770
相同的签名秘钥就能做到大部分另外应用程序能做到的事 with the same keys are able to do almost anything the other can do.

86
00:03:42,770 --> 00:03:46,510
所以从安全的角度来说  标记两个应用程序为共享UID So from the security perspective, marking two applications shared UID

87
00:03:46,510 --> 00:03:50,040
意味着它们实质上可以被当成一个应用来看待 means that they can be treated as essentially the same app.

88
00:03:50,040 --> 00:03:52,600
这有时对分离应用程序很有用 And that's sometimes useful to help break up applications

89
00:03:52,600 --> 00:03:55,210
或是用有趣的方式提供访问资源的权限 or provide access to resources in interesting ways.

90
00:03:55,210 --> 00:03:58,130
但是在安全的角度上  我们更经常遇到相反的问题 But in security, we more often get the opposite question.

91
00:03:58,130 --> 00:04:00,990
如果我想打破一个应用并把它分成几个安全环境   What do I do if I want to break one app into several security

92
00:04:00,990 --> 00:04:03,120
我该怎么做呢 contexts instead?

93
00:04:03,120 --> 00:04:05,469
这就是隔离进程起作用的地方 And that's where isolated process comes in.

94
00:04:05,469 --> 00:04:07,010
为了知道它为什么有用  让我们返回 To see why it's valuable let's return

95
00:04:07,010 --> 00:04:09,160
到crashy service的这个例子中 to the example of the crashy service.

96
00:04:09,160 --> 00:04:11,514
尤其是对于原生代码  当你只是想从崩溃的可能性中隔离 Especially for native code, it may not make sense just

97
00:04:11,514 --> 00:04:15,030
你自己的时候  你的代码可能会毫无迹象地崩溃 to isolate yourself from the possibility that your code will crash.

98
00:04:15,030 --> 00:04:17,860
如果你的代码真的很可疑  像某些类型的渲染器 If the code is really suspect, like certain kinds of renderers

99
00:04:17,860 --> 00:04:19,490
或媒体编解码器  你或许不想 or media codecs, you may not want

100
00:04:19,490 --> 00:04:22,070
对那些代码做太多工作 to have very much to do with that code at all.

101
00:04:22,070 --> 00:04:24,440
事实上  你可能想要把它运行在一个完全分离的 In fact, you may want to run it in a completely separate

102
00:04:24,440 --> 00:04:28,540
进程用户中  实质上  就像它自己的分离的应用 processing user-- essentially, as its own separate app.

103
00:04:28,540 --> 00:04:31,392
而这就是隔离进程所做的事 And that's exactly what isolated process does.

104
00:04:31,392 --> 00:04:33,100
最终的结果看起来是这样的 The net result looks something like this,

105
00:04:33,100 --> 00:04:35,720
应用A分离成两个组件 with app A split into two components.

106
00:04:35,720 --> 00:04:37,590
每个都是在不同的用户和进程下 Each is in a different user and process,

107
00:04:37,590 --> 00:04:40,030
意思就是从这个应用A中被隔离的 meaning that the isolated part of the application

108
00:04:40,030 --> 00:04:43,030
那部分就像别的应用一样 is as separate from app A as other apps are.

109
00:04:43,030 --> 00:04:45,280
所以  什么时候你应该使用进程  什么时候你应该 So when should you use process, and when should you

110
00:04:45,280 --> 00:04:47,790
使用隔离进程 use isolated process?

111
00:04:47,790 --> 00:04:50,500
当隔离的代码是纯Java Use process when the isolated code is pure Java, when

112
00:04:50,500 --> 00:04:52,700
当它不包含一个解释器或类似的东西 it doesn't contain an interpreter or similar,

113
00:04:52,700 --> 00:04:56,590
或当它需要以你的名义来与其他进程交互的时候就用进程 or when it needs to interact with other processes on your behalf.

114
00:04:56,590 --> 00:04:58,900
当隔离的代码是原生代码 Use isolated process when the isolated code

115
00:04:58,900 --> 00:05:01,720
当它进行复杂的操作  像渲染或编码 is native code, when it performs complex operations

116
00:05:01,720 --> 00:05:03,960
当它包含一个解释器或JIT like rendering or encoding, when it contains

117
00:05:03,960 --> 00:05:06,010
当它不需要以用户的名义来 an interpreter or JIT, and when it

118
00:05:06,010 --> 00:05:08,530
运行的时候就用隔离进程 doesn't need to run as your user.

119
00:05:08,530 --> 00:05:11,270
这就是我要说的为Android app开发者设计的隔离模型 That's it for isolation for Android app developers.

120
00:05:11,270 --> 00:05:13,700
一定要看看这个系列的其他视频 Be sure to check out the other videos in this series,

121
00:05:13,700 --> 00:05:13,750
最后感谢观看 and thanks for watching.