移动Web操作系统安全综述

杨 莹李 威吴 荻

1(中国科学院信息工程研究所 北京 100093)2(公安部第三研究所 上海 200031)(yangying@iie.ac.cn)

移动互联网的发展、移动终端普及率的提高，推动了移动办公、移动政务、电子商务、电子支付等新兴领域的发展.在这些领域，由于涉及到手机用户的个人信息或公司的内部信息，安全问题成为人们普遍关心的问题.目前智能终端操作系统中Android，iOS，WP (Windows phone)占据了大部分市场份额，iOS和WP的安全依赖于其闭源和应用溯源等安全机制.而Android由于开源，使恶意软件和黑客非常容易进行权限获取和系统修改，面临更多的内核层危害.在移动政务领域，要求系统能够为用户提供机密性和完整性的保护，而这些安全需求在当前的主流操作系统中并未体现.

随着网络带宽的增加和网络传输速度的提升，越来越多的厂商推出了新的移动操作系统，比如Mozilla的Firefox OS、Intel和三星共同开发的Tizen、Google的Chrome OS、Ubuntu的Touch等.这些操作系统都是采用HTML5，CSS，JavaScript等Web语言开发的基于网络的操作系统(Web-based operating system, Web OS)，而对于用户来说这些Web OS更像一个浏览器或者服务平台.对于政府和企业用户，利用基于Web OS的移动终端可以使用户通过Web OS在不同的终端的浏览器框架运行云端存储的办公软件，而数据的存储和管理交给可信云，既解决了移动办公问题，又可通过数据和应用的集中管理保证信息的安全性.因此，基于Web OS实现的移动终端成为一种新的移动政务解决方案.

1 研究现状

由于Android和iOS超过95%的市场占有率，对于新发展起来的Web OS等新型智能终端操作系统的研究相对较少.目前开源的Web OS主要有：Firefox OS[1-2]，Chrome OS[3]，Tizen[4]，Ubuntu Touch[5]等，对Web OS安全的研究主要从Web应用的安全性[6-9]、权限机制[10-11]和应用审核发布[12-15]等方面进行.还有一些研究是基于移动网络的攻击[16-17]和内置广告的威胁[18-19]来进行.

随着Web OS系统的发展，文献[20]提出一个基于P2P网格架构和语义技术的PGSW-OS(P2P网格语义Web OS)模型来改善Web操作系统中的资源管理，降低了在Web操作系统环境中搜索的计算复杂度.文献[21]对存在缺陷倾向的应用程序与平台依赖性之间的关系进行研究，指出具有缺陷倾向的应用源代码比无缺陷的对平台的依赖性更高，并且增加平台依赖性会增加源代码文件中存在缺陷的可能性.而基于Web OS能够提供更好的跨平台性，Web应用也具有较少的平台依赖性.在当前工作[22-23]中将Web OS用于对远程应用程序管理，并且这些方案能够减少时间、成本和资源的使用，提高了信息集成的效率，这也为移动政务提供了一种新的解决方案.还有一些面向高安全等级移动办公的解决方案[24]，通过引入改进的BLP模型来提高基于Web OS办公系统的机密性.

利用Web OS实现移动瘦终端是使用Web OS提供的浏览器框架来运行安装在服务器上的应用(称为Web应用)，而本地只存储这个应用的Manifest文件(权限列表文件)，用来对Web应用调用终端系统资源进行权限管理.这种方式的优点是跨平台性，且不必考虑终端运算能力、存储条件便可以直接使用服务器上的资源.但是由于Web OS是新技术，在设计时侧重移动性和跨平台性，对安全性折中考虑.在此背景下，本文针对几个开源Web OS分析其安全问题和应对方案.

2 安全性分析

Firefox OS，Tizen，Chrome OS，Ubuntu Touch均基于Linux内核采用层级的系统架构，但具有不同的安全机制，本节从这些平台的体系结构、应用类型和安全机制入手，进一步分析其各自的安全性.

图1 Firefox OS系统架构

2.1 体系结构

2012年Mozilla将Boot to Gecko项目正式更名为Firefox OS.其系统架构[1]如图1所示，在硬件上方依次是Gonk，Gecko，Gaia层.Gonk层将底层手机硬件的功能抽象提供给Gecko层，并提供系统库、设备驱动程序和Linux内核.Gecko层是应用程序运行时，通过Web API强制执行安全策略，而访问设备硬件功能的唯一方法是使用Web API调用.Gaia层由基于HTML5，CSS，JavaScript编写的应用程序组成.

Tizen系统整合了BADA和MeeGo操作系统，于2012年2月正式公布，目前已经应用到手机、平板、智能手表、TV等设备.其架构[4]如图2所示，由系统层、各类本地子系统、框架层和应用层组成.它为开发人员提供Web API和本地API.Web框架可以开发和运行具有HTML5功能的应用程序，并为开发人员提供2组API：W3CHTML5 API和设备API.应用程序通过与其类型相对应的API实现对设备功能的访问.

图2 Tizen系统架构

Chrome OS自2013年起可以在x86或ARM微处理器上运行.其系统架构[3]如图3所示，具有3层：固件、系统级软件和服务、浏览器和窗口管理器.固件有助于快速启动、验证引导过程中的每个步骤并协助系统恢复;系统级软件包括Linux内核、设备驱动等;浏览器为应用提供运行环境，窗口管理器处理用户交互.

图3 Chrome OS系统架构

图4 Ubuntu Touch系统架构

Ubuntu Touch项目开始于2011年，于2013年1月2日发布了该系统.目前该系统定位于能够在手机、平板、IoT设备、TV上广泛使用并兼容的系统.Ubuntu Touch[25]系统架构如图4所示，分为内核、Ubuntu平台、应用和应用框架层.Ubuntu为应用程序提供3种API：Ubuntu平台API(Unity)、W3C API和Cordova API.Unity API提供对OS服务的访问，例如通知、消息传递、媒体播放器、启动器等.W3C API遵循W3C规范，提供有限的1组设备资源访问.Cordova API提供对各种系统资源的访问，如摄像头、联系人、文件、地理定位和存储，且任何来源Web代码都可以访问Cordova API.

在体系结构方面，由于这些平台所采取的商业发展策略不同，其体系结构也有所区别.比如Tizen出于对Android应用的兼容，采用混合的框架层，同时支持Web应用和Android应用，而Chrome和Ubuntu仅支持远程安装的Web应用.总的来说，这些平台都采用了层级的结构：硬件依次为Linux内核、系统层、框架层和应用层.

Linux内核和系统层为用户提供最基本的功能，包括内存管理、进程调度、设备驱动和文件系统.Firefox的内核是基于ASOP项目，并作了相应的修改，相比Android内核的Binder进程间通信，Firefox OS不支持进程间的直接通信，也就间接减少了进程间的共谋攻击.其他3个平台均基于不同版本的原生Linux内核，因此具有Linux内核的一些特点，如采用了Linux的访问控制列表(ACL)强制实施文件系统权限.

框架层作为上层应用与底层硬件之间的中间层，提供底层程序的接口库以及用以访问核心功能的API框架.框架层还提供了各种服务和管理工具，包括应用开发所需的界面管理、数据访问、应用层的消息传递、应用包的管理、电话管理、定位管理等功能.这些开源的Web OS均是在该层实现应用程序对系统软硬件资源的访问控制，但多是基于应用类型和应用安装时申请到的权限列表，这种访问控制仍属于自主访问控制.

应用层包括一些内置的基本应用，如桌面、浏览器等，以及用户安装的采用HTML5，CCS，JS等编写的各类Web应用.这几个平台都支持各类远程安装的Web应用，但是Tizen，Firefox也支持本地安装(packaged app)的应用，并且本地安装的这类应用给予更高的系统权限.

2.2 Web应用

Firefox OS系统将Web应用程序分为3类：特权(certified)、认证(privileged)和Web.特权应用和认证应用与Android应用类似，需要在本地打包存储.安装在服务器上的Web应用，通过HTTP加载，仅在手机上存储其清单(manifest)文件.Web应用的工作方式类似于普通网站，在默认情况下具有与普通网页相同的权限，但允许它们通过访问Web API与设备硬件功能交互.

Tizen提供3类应用：本地的、Web和混合的，具体取决于其底层框架的类型(Native，Web或两者的组合).同时Web应用分为3类：移动网站、托管应用和打包应用.移动网站应用在浏览器中打开，具有与普通网页相同的资源.类似Firefox OS，托管应用存储在远程服务器，具有非常有限的本地资源访问权限，本地打包应用具有较高权限.

Chrome OS自2016年起开始兼容Android应用程序，目前主要支持3种类型的Web应用程序：Web、网页和扩展的.Web应用安装在远程服务器上，只在设备上安装了manifest文件和图标.网页应用在浏览器实例中运行，但没有浏览器UI.扩展应用在常规浏览器实例中运行，但可以更加紧密地与浏览器集成，并绕过同源策略.

Ubuntu Touch支持2类应用程序：HTML5应用和Web应用.HTML5应用在没有浏览器UI元素的Web容器内执行，后者在Web浏览器中执行.Ubuntu提供了应用程序的本地代码和远程代码之间的隔离，将远程代码看作是不同的来源，并强制实施同源策略.

这些Web OS根据其商业发展策略采用了Web应用或多种应用类型组合的模式.广义的Web应用包括HTML5应用和Web应用，前者可以看作是普通网页，后者则是具有和Android应用类似功能(计算能力、数据处理能力、办公能力等)的应用.在较为通用的系统架构下(见2.1节)，本文将平台中的应用程序分为3类：1)本地应用，一般是系统应用，本地安装和存储，为用户提供各种基本的系统功能和服务，并且这类应用具有较高的权限；2)HTML5应用，类似于网页，具有最少的系统资源访问权限；3)Web应用，安装在服务器端，但是需要将应用的manifest文件存储在终端，在该文件中应用需要列出其所需的权限列表、来源等信息.

在面向高安全级移动办公的瘦终端应用背景下，Web应用具有云端安装、云存储以及集中管理的优点，因此本文以Firefox为例对Web应用的安全性进行进一步的分析.

在应用的审核和发布方面，由于Firefox OS中所有的应用都是用HTML5，JavaScript，CSS，media和其他开源网络技术编写，因此在代码审核阶段，采用自动化工具分析和人工检查(主要是针对使用Web API调用是否合理)相结合.应用审核发布阶段，所有的文档和应用指南审查过程公开，任何开发人员都可以访问它们.这些措施在一定程度上减少了恶意应用的来源.

在应用对系统的访问方面，必须通过Web API，甚至对文件系统的访问也通过Web API和1个后端SQLite数据库.本地安装存储的打包应用包括1个ZIP文件和manifest文件提供显式的文件列表以及相应的哈希值，来保证打包应用的完整性，也因此给与这类应用更多的信任和权限.此外，系统还提供了类似于Android和iOS的沙箱机制，实现应用之间的隔离.基于manifest文件中的权限列表，在应用安装时和运行时进行访问控制来确保应用整个生命周期的安全性.

由于Web应用都像是浏览器选项卡，是作为b2g(类似于Android的zygote进程)的子进程运行，b2g来判定它能否获得某个特权调用(即获取Web API访问).此外还对Web应用实施同源策略，即同源(指向同一个iframe tag)的Web应用是在不同的沙箱运行，具有不同的cookie和数据存储.

图5 Firefox OS应用沙箱模型

综上，Web OS采取的Web应用的严格审核和发布、访问控制和同源策略等安全措施，在一定程度上保证了应用程序在系统中的安全运行.

2.3 安全机制

在安全机制方面，这几个平台具有Linux内核、Web语言开发等共同特性，但是又由于各个平台的差异性，具有各自的一些具体实现细节.总的来说，这些平台主要采用的安全机制有如下几个方面.

2.3.1Linux安全机制

文件访问控制继承了Linux的权限机制，每个文件都绑定UID、GID和rwx权限，用于进行自主访问控制(也称为Linux DAC)，这点与Android是一样的.为了增强安全性，所有用户数据都存储在数据分区，与系统分区隔离.但是根据DAC的特点，自主决定写、删除或读取属于其他用户的文件，可能导致信息泄露或超出预期的行为如特权提升.

POSIX权能机制是Linux内核对POSIX.1e权能(capabilities)的一个子集提供支持，是将传统上与超级用户关联的特权分为几个单元，称为权能，它们可以被独立地启用或禁用.

2.3.2沙箱机制

应用沙箱是当前智能终端操作系统普遍采用的一种安全机制，通过隔离每个应用，使得应用不能与区域外的其他工作区交互.该机制实质是一种在App运行时设置边界和限制的方式来实现应用和其数据与其他应用之间的隔离保护.在Web OS系统中，每个App运行于自己的工作空间，只能访问被允许的Web APIs、数据以及与工作区相关的资源(如IndexedDB databases，cookies，offline storage等).Tizen，Chrome OS，Ubuntu采用类似于Android的沙箱机制，并允许进程间的直接通信，这就存在通过共享内存的通信方式导致应用被恶意代码感染.

Firefox OS的沙箱机制与上述几个平台的有所区别.在Firefox OS系统中b2g进程是运行在高特权的系统进程，能够访问手机硬件参数.在运行时，每个App的运行环境都是b2g的子进程，具有受限的系统权限.如图5所示，应用A，B，C只能通过Web API读取自己沙箱内的数据，不能直接读或写文件系统的其他文件，这些请求都由b2g父进程判断并通过Web API提供.唯一的应用之间的“沟通”方式是：A创建一个自己的事件发送给b2g进程，B通过监听并截获它.然后，当B(Web App)想打开A时，如果A是Web App，即打开A指向的一个网站，并以A的另一个实例的方式打开A；如果A不是Web应用，在一个iframe中打开A将报错，并且无论是否存在应用A均提示同一信息，以避免出现隐蔽通道攻击.

2.3.3同源策略

同源的Web应用程序是指不同的应用程序的manifest文件中指向同一个iframe tag的应用.因此，根据Web应用的特殊性，这些Web OS均采用了同源策略，即2个同源应用在不同的沙箱运行，具有不同的cookie和数据存储.在系统资源的保护方面，当Web AppA或它的一个实例A1获取访问某一本地资源的权限，但A的另一个实例A2或与A同源的Web AppB不具有这一权限.特别地，Chrome OS和Ubuntu平台进一步加强同源策略，将同一应用的本地代码和远程代码之间也实施同源策略.这样更有效地避免了远程的不可信代码对系统的危害.

2.3.4权限机制

权限管理是系统中最重要的安全措施之一，这些Web OS平台对于权限的设计和考虑以达到方便、易用和简单、快速为主要目标，在安全性方面作出了折中，采用了较粗粒度的权限管理机制.

目前Web OS的权限管理都遵循最小权限原则，即最初只给予最小的权限.如果应用需要额外的权限，必须在manifest文件中声明，然后用户可以选择性地在安装时授予所申请的额外权限.否则，如果缺少必要的权限，由于沙箱的保护，这些应用程序将不能正常提供所期望的功能与服务.

由于基于Linux内核，系统中的权限分为3类：所有者权限、ROOT权限、应用权限，前两者类似于Android.ROOT权限也是系统中的最高权限，如果拥有该权限就可以对系统中的任何文件、数据、资源进行任意操作.因此就存在恶意应用采用类似iOS越狱、Android的ROOT提权等攻击方法，获得系统最高权限，进而危害系统乃至设备的安全.应用权限默认的是根据应用的类型，给与所需的最小的权限种类，如果应用需要类型所属的额外权限，必须在manifest文件中声明，在程序安装时由用户授权.

特别的是，Tizen提供了一种简化的强制访问控制内核(simplified mandatory access control kernel, SMACK)[26]作为其强制访问控制机制，它是在安装时给每个进程(主体)和资源(客体)一个10个字符的SMACK标签，作为扩展属性.一旦应用程序在安装期间被授予某些权限，则这些权限将成为相应的SMACK规则.

Web OS的系统权限机制一般是在框架层实现的，采用了引用监控器思想，由访问监控器(reference monitor)判断是否授予对Web API访问.首先是根据该Web App的类型判断是否具有足够资格访问，然后查询应用的manifest文件中是否声明了该权限.Android也具有类似的权限申请机制[27]，在Android的AndroidManifest.xml文件中，通过〈permission〉，〈permission-group〉，〈permission-tree〉等标签指定.但是Web OS还要求提供特定的mime类型清单[28](applicationjson x-web-app-manifest+)和Web应用对应的完整主机名(用来确定Web应用的来源)这一机制用来确保Web应用的可靠性.

虽然这些系统提供了不少安全机制，但仍不同程度地存在安全缺陷.Firefox OS应用通过Web API访问系统资源，由系统框架层根据调用应用程序的类型和访问控制列表来检查访问请求.这种访问控制不足以控制特权提升，如通过写入、删除或读取属于相同类型的另一用户的文件，进而将导致信息泄露或意外行为.Tizen出于其商业策略，采取混合的框架以支持更多的应用类型，如支持Android应用，但是缺点是会导致未经授权的访问和管理混淆.Chrome OS同样根据manifest文件中声明的权限实现访问控制，但开发人员可以添加更严格的运行时检查.默认情况下单个Web API必须由应用程序显式请求才能激活，其安全性取决于开发人员对每个资源请求的源检查[29].此外，即使正确执行的检查也可能被绕过.Ubuntu提供3种API[30]：Ubuntu平台API、W3C API和Cordova API，分别对应不同类型的系统资源.但是对这3类API的管控不够严格，如将Cordova API公开给所有Web源代码，也就是允许不可信的远程Web代码访问摄像头、麦克风等敏感资源.

3 安全拓展

这些Web OS平台与其他移动操作系统一样，面临的攻击不仅来自互联网，还可能来自系统内部，如内核漏洞、访问控制粒度较粗带来的安全问题.此外，一些平台还缺乏加密接口，依赖第三方实现；对于一些新技术，如ASLR和NX，目前仍不支持.

对于体系结构、应用安全、现有安全机制尚存的缺陷，并借鉴Android的安全机制改进方案，本文从不同角度提出了一些安全拓展方案，分别针对的是体系结构中的不同层级或者它们的组合.

3.1 内核安全

迄今为止，大部分对于安全性的研究是针对中间件层的访问控制，并未针对Linux DAC机制的改进.但是中间件实现的访问控制模型都依赖于内核层的控制，因此内核层面的访问控制相对中间件层能够更好地保证安全策略的实现不可旁路.随着安全需求的不断提升，Android在2013年引入SELinux[31]来实现内核层的强制访问控制，并在Android系统的更新迭代中逐步实施.同时Linux也不断推出了一些新的内核安全技术，如cgroups，grsecurity等.因此，本文讨论的这类基于Linux内核的Web OS在未来必须逐步采用这类安全技术来提高内核的安全性.

3.2 体系结构改进

权能体系是较早用于实现安全内核的结构体系，作为实现访问控制的一种通用的、可塑性良好的方法，目前移动终端操作系统多采用POSIX.1e的权能机制，但是基于权能的系统缺乏策略可变通性.SEAndroid[32]是将Flask[33]体系应用在Android系统中.该体系结构的实现是借助了Linux安全模块(LSM)实现，作为Linux内核模块的1个子系统，并借助LSM提供的多类钩子函数来实现安全策略的判断.目前Web OS还未引入Flask体系结构，但对Web API的访问控制已经采用了引用监控器思想，但是访问判断基于权限列表或manifest文件，而非安全服务器.因此基于Flask体系对Web OS体系结构进行改进，能够提高系统对多个安全策略的兼容和安全策略的灵活性.

3.3 隔离措施

基于ARM的TrustZone构建可信移动平台(trusted mobile platform, TMP)[34]是在资源受限的移动平台为敏感应用提供一个安全可信的环境.该技术主要是通过在微处理器中加入域隔离功能，将移动可信模块(MTM)功能软件代码置于TrustZone的安全区，由安全区内核保证MTM的运行可信.Web OS在未来发展中利用该技术，可以实现类似于Android的基于硬件保护的安全隔离(如双系统、安全容器方案)，或将boot loader和加密模块存储于TrustZone的安全区，实现基于硬件保护的可信引导、可信加密等安全机制.也可以利用该硬件保护机制，实现对服务器端数据的安全验证和通信.

3.4 强制访问控制

在访问控制策略方面，这些平台都基于Linux内核，因此在文件系统以及系统敏感资源的访问控制都基于Linux DAC模型.Tizen的简化的强制访问控制内核是一种轻量级的强制访问控制(MAC)机制，为移动Web OS实施MAC提供一个很好的开端.它是通过在安装时给每个进程(主体)和资源(客体)1个10个字符的SMACK标签，作为扩展属性，实现基于标签的访问控制.一旦应用程序在安装期间被授予某些权限，则这些权限将成为相应的SMACK规则，那么此后系统的访问控制就是基于该安全标记进行的，也就是强制访问控制.因此，采用强制访问控制模型增强系统的访问控制机制能够解决自主访问控制带来的非授权访问等问题，是提高Web OS安全的有效途径.

3.5 ROOT权限分解

基于Linux内核的操作系统都存在着ROOT权限，而且，通过系统漏洞或应用的漏洞，这一权限很容易被恶意应用获取，可想而知对系统的破坏也是巨大的.因此，一些安全操作系统已经开始研究将系统权限分解为几个权限组，而原来的ROOT所能完成的功能，由几个特权系统应用共同实现.因此，对于某个特权系统应用只能获得某一组或几组和自己需要完成的功能相关的权限，而不能获得所有权限.这种将ROOT分解的方式，在一定程度上减少了系统特权应用被利用后对系统造成的危害，是保护系统安全的重要措施.

4 总 结

Web操作系统由于具有良好的迁移性，符合未来移动办公的需求，本文通过对几个开源Web OS平台的分析，认为目前通用的Web OS架构基于Linux内核，采用DAC模型，由底向上依次为系统层、框架层和应用层.系统的安全框架遵循最小特权的原则，在框架层的Web API使用基于权限列表的强制访问控制，但文件系统和其他子系统仍使用DAC模型.一般地，将应用程序分为本地应用和Web应用，本地应用仅指系统应用或系统服务相关的应用，这些应用可以认为是可信的，而各种Web应用程序安装在远程服务器中，对于Web应用进一步划分其可信级别，将远程代码和本地代码加以区分.

在安全保护方面，这些Web OS都采用了应用沙箱、同源策略、权限管理等安全机制.但是这些安全措施仍存在不同程度的缺陷和不足，因此将Web OS应用到高安全级移动办公中，还须引入访问控制模型防止未经授权的访问和修改.目前的Web OS缺乏完整性验证，Web APIs作为应用访问系统资源的唯一接口和进程通信的通道，应实施更有效的强制访问控制来保护系统资源和确保进程间的有效隔离.最后本文提出一些安全拓展方案，对提高Web OS的安全性提供一些建议.