iOS 的围栏花园
许久以前看过一篇论文,将苹果公司移动操作系统的安全模型叫做 Walled Garden Model ,将 Android 平台的安全模型叫做 End-user control model 。这两种平台具有迥异的设计思想和与生具来的“种族差异”,很有意思。今天就来说说 iOS 的 Walled Garden,我将它翻译成“围栏花园”。
iOS 是一种严格的 Walled Garden
在维基百科中:
a “walled garden” refers to a carrier or service provider’s control over applications, content, and media on platforms (such as mobile devices) and restriction of convenient access to non-approved applications or content.
简单翻译一下,运营商或者服务提供商对平台(移动设备)上的应用、内容和媒体进行强势控制,限制非法的应用和内容。维基百科文中提到,iOS 就是典型的 Walled Garden 运作范例。
iOS 的围栏花园是一种“圈养”式的模型,这种圈养,不仅仅是对最终用户,更是对每一个应用。打一个比喻,用户就如一个孩子,被限制在一个周围围着高大围栏的安全的活动范围里,而应用就像围栏花园中种的鲜花瓜果,这个花园的每一棵植物只允许生存在自己的花盆里,如果有邪恶的植物,比如毒花毒草企图污染泥土、空气或者把根伸到其他花盆,那它将被苹果公司的园丁大叔连根带泥整个扔掉。于是,在园丁大叔的强制管理下,花园里的各种植物按照规划长得规规矩矩。花园里鸟语花香,孩子在围栏花园中放心玩乐,如此和谐“世界”只因有一个神一样的存在——苹果公司,它打造花园、建立秩序、维护秩序,正如人类社会一样。这样的围栏花园为一个核心的政府意志所主导,其规则被一整套审核机构进行强制推行。
每一个应用都是一个孤岛
“每一个应用都是一个孤岛(Every App Is an Island)”,苹果公司的开发文档如是说。在信息世界,其他设计师们都在想办法打破信息孤岛的时候,这个设计很值得思考,安全至上的移动操作系统,可以说极大程度的推崇应用隔离,毫不客气的牺牲了本机内应用间信息共享(实际上,应用间的通信可以通过云端机制来解决大部分需求),可以说在同一台设备上,应用间的距离是“咫尺天涯”。
换一种严谨的技术语言来审视 iOS 上的应用安全性特性,苹果平台中的应用,被限制在沙箱(sandbox)中,应用只看到沙箱容器目录,不可见系统的其他目录和整个文件系统,沙箱中关键子目录,例如,<Application_Home>/AppName.app、<Application_Home>/Documents/、<Application_Home>/Documents/Inbox、<Application_Home>/Library/等目录,每个子目录使用方法有严格规定。沙箱严格控制文件目录访问,每个应用仅能访问自身的文件和数据,严格控制了硬件、系统共用数据、网络等资源的使用权限。如果应用不遵循设计规格,应用或者不能正常运作,或者在审核环节被废弃,或者上市之后被下架。
有深入探究者会好奇,严格的沙箱结构下,应用只能访问沙箱的容器目录,应用之间的文件共享究竟需要多大的代价?举一个例子来帮助理解(非开发步骤),EMail 应用和 TXT 编辑应用严格隔离,如果 EMail 的应用需要 TXT 文本编辑器打开和显示一个文本的附件,TXT 文本编辑器需要声明自身能处理的文档类型,当用户点击 EMail 的附件并选择了TXT文件编辑器的时候,EMail的TXT附件被 iOS 系统机制传送到 TXT 文本编辑应用的 /Documents/Inbox 目录下,TXT 文本应用读取这个附件文件展现给用户,当用户编辑这个文本附件,TXT 文本编辑应用应该将这个文件移动到本应用的数据目录下,因为沙箱规定/Documents/Inbox只有读取和删除文件的权限,并没有写文件的权限。这是严格的沙箱结构的特例流程,苹果公司官方开发文档中需要专门文档进行阐述。
iOS 的沙箱不是Unix的应用隔离机制
iOS 和 Android 有一定的亲缘血统,这个血统来自于 Unix ,具有类似的进程账号绑定机制。Android 上使用不同的用户账号来运行进程,以此进行应用隔离,iOS 与此不同,所有应用使用相同的用户账号来运行进程, 使用沙箱内核扩展来实施安全隔离机制,iOS 内置了 35 个沙箱配置文件对应不同类别应用的运行。iOS 的沙箱机制可以参看 iOS 的同源兄弟 Mac OS X上的 “sandbox-exec” 命令,其运作机制可以参见下图(来自“技术奇异点”博客),在操作系统内核对应用访问权限进行强制检查,图中的 Access Control List 相当于 sandbox-exec 命令中的沙箱配置文件profile。
sandbox- exec [- f profile- file] [ – n profile- name] [ – p profile- string] [- D key=value …]
command [arguments …]
$ sandbox-exec -f /usr/share/sandbox/bsd.sb /bin/ls
使用沙箱环境运行程序/bin/ls程序,其沙箱配置文件为/usr/share/sandbox/bsd.sb。想体验一下沙箱的限制作用,可以运行下面的命令:
$ sandbox-exec -n no-internet ping www.google.com
PING www.l.google.com (209.85.148.106): 56 data bytes
ping: sendto: Operation not permitted
……
可以看到限制了网络的访问权限之后,ping 程序将不能正常运行。
Mac OS X上用户可以运行 sandbox-exec 命令,可以看到文件系统,以及控制沙箱,然而,iOS 上的沙箱则是无所不在的幕后黑手,沙箱就像是一方井水,应用就像是坐井观天的青蛙。
围栏花园是运营出来的
尽管 iOS 上具有严密的机制隔离以及控制应用,然而,再完备的操作系统也难免有漏洞,并非牢不可破。整个 iOS 围栏花园的应用安全不仅仅靠 iOS 操作系统本身的架构以及防卫体系,更加依靠苹果公司对整个平台生态系统的经营。
苹果公司通过终端(iPhone)与平台(应用商城 App Store 以及其他内容传送平台)的组合运营,逐步吸引和驯化用户,平台的应用和内容丰富了,成为用户获取应用和内容的主流渠道,因此用户也逐渐忠诚,于是,聚集了海量高商业价值用户的平台成为苹果公司的筹码,得以要求逐利的应用开发商遵循苛刻的安全准则,平台安全性则反过来增加用户对平台的信赖程度,使整个生态系统呈正反馈方向健康的发展。
在平台运营中,需要有足够的技术装备,还需要巨额的人力成本和资源。在应用上架之前以及任何时候对静态代码进行扫描,逆向工程,运行时检查,杜绝恶意的应用毁坏平台的安全根基。