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 以及其他内容传送平台）的组合运营，逐步吸引和驯化用户，平台的应用和内容丰富了，成为用户获取应用和内容的主流渠道，因此用户也逐渐忠诚，于是，聚集了海量高商业价值用户的平台成为苹果公司的筹码，得以要求逐利的应用开发商遵循苛刻的安全准则，平台安全性则反过来增加用户对平台的信赖程度，使整个生态系统呈正反馈方向健康的发展。
在平台运营中，需要有足够的技术装备，还需要巨额的人力成本和资源。在应用上架之前以及任何时候对静态代码进行扫描，逆向工程，运行时检查，杜绝恶意的应用毁坏平台的安全根基。
