CN104704506A

CN104704506A - 系统控制

Info

Publication number: CN104704506A
Application number: CN201380048445.0A
Authority: CN
Inventors: D·凯鲁比尼; T·库奇诺塔
Original assignee: Alcatel Lucent SAS
Current assignee: Alcatel Lucent SAS
Priority date: 2012-09-20
Filing date: 2013-09-13
Publication date: 2015-06-10
Also published as: US20150220710A1; WO2014044373A1; JP2015531517A; WO2014044373A8; KR20150045488A; EP2711861A1

Abstract

一种控制能够由操作系统的用户实施的系统关键改变的方法、可操作为执行该方法的计算机程序产品和操作系统。该方法包括：从用户接收进行系统关键改变的请求；评估该用户是否具有进行所述系统关键改变的适当权限；如果有，则向具有进行所述系统关键改变的适当权限的至少一个其他用户通知所接收的请求；以及在实施所请求的系统关键改变之前等待来自至少一个其他用户的批准。各方面和实施例通过消除单个用户直接发布和实施危险或破坏性的命令的能力来改进计算机系统的安全。

Description

系统控制

技术领域

本发明涉及一种控制能够由操作系统的用户实施的系统关键改变的方法、可操作为执行该方法的操作系统和计算机程序产品。

背景技术

需要提供计算系统的更好的保护。系统管理员一般可以访问系统内的数据和代码。此外，不可信的、可能恶意的软件可能在系统上运行，并且可能获得对系统内的数据和代码的访问。

从实际和实现的角度来看，对进行可能恶意或有害的改变更富有弹性的安全系统必须在技术上有效而且还能够负担。

期望提供对可能恶意或有害的改变具有改善的弹性的操作系统。

发明内容

第一方面提供一种控制能够由操作系统的用户实施的系统关键改变的方法，该方法包括：从用户接收进行系统关键改变的请求；评估用户是否具有进行系统关键改变的适当权限；如果有，则向具有进行系统关键改变的适当权限的至少一个其它用户通知所接收的请求；以及在实施所请求的系统关键改变之前，等待来自至少一个其它用户的批准。

由例如共置在数据中心中的服务器容纳的计算系统通常被很好地保护，因为物理进入服务器房间通常被严格限制。远程访问操作系统和在其上运行的应用一般也是受控的，例如，通过安全壳(SSH)或远程桌面会话。存在防止一般用户(不论该用户是人还是软件服务)具有对计算系统进行可能破坏性的改变的能力的方法。

通常，存在具有对系统进行改变几乎不受限制的权力的特殊用户。该用户在很多操作系统中通常被成为“超级用户”。在UNIX和类UNIX系统中，超级用户(根(root))可操作以改变每个用户的权限。用户“根”可以不受限制地访问文件和命令。因此任何获得超级用户接入的恶意用户或恶意软件可在系统内执行任何动作，例如，删除敏感数据、关闭虚拟机或关闭整个系统。应当知道，真正的超级用户也可以执行相同的一组动作，包括上面提出的危险动作，虽然真正的超级用户可能无意或疏忽地执行这些操作。这种情况也可能发生在其它操作系统中，例如，微软的视窗操作系统。

操作系统一般依照“最小权限”的原理来工作，依照该原理可以配置用户账户，以使得每个用户(除了超级用户以外)能够只管理平台上的一些可用服务。例如，用户可以被分配能够改变网络服务器的配置并重新启动它的权限，但是该用户可能不会被赋予或分配足以能够关闭其它服务或整个系统的权限。用户可能在配置服务时无意识地出错或出于个人目的有意识地错误地配置服务。

典型操作系统的接入控制模型是为了允许用户来管理操作系统的每一个服务，使得查询被发送到接入控制子系统，从该接入控制子系统返回的答案采用二进制响应的形式返回。用户要么被授权要么不被授权来管理该服务。

由授权用户采取的管理动作被批准，而不需要检查这些操作。在此描述的方面和实施例认识到，可能存在与对典型的操作系统接入控制模型的改变相关联的益处，以使得由授权用户采取的动作(例如关键动作)可能需要具有适当权限的一个或多个其他用户的批准，以使得新的配置在任何改变被系统应用之前被一个以上的其他用户同意。

应当知道，这样的安排如果在数据中心和/或云计算服务器上实现是有用的，其中由于系统管理员的失误而产生的服务器的错误配置可导致破坏与客户之间的安全级别协议或者例如破坏客户的数据的安全和保密性。

在典型的现代操作系统中，接入控制列表(ACL)用于授权用户执行所请求的操作。例如，被赋予读和/或写和/或执行特定文件的能力的用户通常在与该特定文件相关联的ACL中定义。文件系统可支持可移植操作系统接口(POSIX)ACL，根据该POSIX ACL，用于个人用户和组的多个接入规则对于系统中的每个文件可以是特定的。

在已知的ACL实现中，存在超级用户，并且该超级用户在整个系统中具有不受限制的权限，因此，能够采取任何动作，例如，添加、编辑或删除任何文件或者启动、停止、或重新启动任何在系统上运行的应用。超级用户通常是受过训练的技术人员，并且该超级用户也通常被称为系统管理员。这种系统管理员通常负责支持和维护计算机系统。系统管理员通常具备可有助于维持低故障率和低数据丢失率的训练和经验。但是，人为错误仍然可能发生，并且恶意用户或恶意软件仍然可能在系统上破坏性地运行。

为了应对人为错误，系统或应用可操作以自动检查任何发布的“关键”命令。系统或应用可以向超级用户发送适当的警告消息。关于关键命令的最后决定可以由超级用户做出，其可以主动或无意地忽略任何这种警告消息，关键命令可被提交。应当知道，已经例如通过权限提升技术获得对系统的超级用户接入的恶意用户或软件的活动是不可控制的。可以使用一些重新授权对策，但是这通常发生得太迟。

基于工作流的交互模型有时候仅在配置改变需要在被提交前经过其他用户批准的单独应用或服务上可用。例如，多种支持在因特网上发布网页的内容管理系统(CMS)具有这种功能，通常以基于网络的编辑系统的形式可用，据此，用户可准备一些对网站的改变，并且这些改变在直到某些其他用户批准后才变得确定。然而，这种工作流一般在操作系统的最深处的功能级处不可用，如在此描述的各方面和实施例所提出的。

第一方面提供操作系统和/或由该操作系统提供的服务的多重授权或多重批准管理。因此，各方面可以提供一种方式以避免对真实或虚拟的计算系统的可能破坏性的改变。各方面和实施例对操作系统(OS)进行扩展以提供执行两个或更多个管理者需要在改变被提交前同意“关键”动作的接入控制模型。关键动作可根据具体实现进行配置，但一般是与在操作系统或由该操作系统提供的一个或多个服务的配置上进行可能破坏性的改变相关联的动作。

根据一个实施例，用户和至少一个其他用户中的至少一个具有系统管理员权限。那些管理员权限可以基本上与超级用户权限同义。在实施例中，用户和至少一个其他用户具有相同的特权。因此，对等批准可发生。根据一个实施例，用户和至少一个其他用户两者都具有系统管理员权限。因此，多重批准对等批准方式对于提交系统关键改变是必需的。如果所提出或请求的改变特别重要，则大量的对等用户可被要求批准该改变。

根据一个实施例，批准和实现与请求的接收异步发生。因此，在某些实施例中，所请求的操作或改变被推迟到稍后被至少一个其他用户批准，该第二用户能够在所提出的系统级改变被实施之前对该改变进行双重检查。因此，为了认证或批准所请求的改变，不需要请求用户和至少一个其他用户的同步操作。应当了解，根据一些实施例，对于每一个所请求的关键改变，批准过程必须发生，并且交叉检查在每次由用户请求系统关键改变时都发生。因此，单个用户不能实现系统关键改变，无论用户是否已经针对先前所请求的系统关键改变而被交叉检查过。实施例可以提供异步操作模式，根据该模式，用户可执行或请求管理动作或系统关键动作，该动作的应用被推迟直到另一个具有适当权限的用户可检查和批准该动作。每一个用户可以单独登录，使用他们自己的凭证以执行系统关键改变和/或批准并应用由其他等待批准的用户所请求的改变。

根据一个实施例，接收、评估和通知在内核空间中实施。各方面和实施例可以在内核空间中实现，例如，作为接入控制列表的扩展，或者在用户空间中实现，例如，利用持续运行的不能修改的守护进程的实现。根据一个实施例，接收、评估和通知在用户空间中实施。根据一个实施例，接收、评估和通知由操作系统所运行的守护进程实现，该守护进程具有适当权限。在一个实施例中，守护进程具有超级用户权限。根据一个实施例，守护进程不能被操作系统的任何单个用户修改。应当了解，守护进程自身的修改，例如，将系统关键动作升级或修复或增加或消除到一组预先确定的系统关键改变，可包括系统关键改变，并要求多用户批准系统，如果期望改变守护进程的操作参数。

根据一个实施例，系统关键改变包括关键的操作系统级别操作。

根据一个实施例，该方法包括配置能够由操作系统实施的哪些改变被认为是系统关键改变。可进行操作系统的多重批准过程的关键操作或过程的例子例如包括：重新启动或关闭虚拟机或真机；文件或过程权限的修改；对安全设置应用改变(例如，防火墙政策)；对网络设置应用改变；访问属于另一个用户的其它敏感数据和其它类似操作。各方面和实施例允许操作系统内的多重批准工作流程，其保护关键的操作系统级别操作，诸如网络适配器的重新配置、网络服务和路由表、创建或删除用户、修改用户权限、执行关闭或重新启动操作等等。

根据一个实施例，该方法包括向每个能够由操作系统实施的系统关键改变分配安全级别，以及基于所分配的安全级别，将通知和批准参数与系统关键改变相关联。因此，那些被确定具有高安全级别的改变可要求超过一个的其他用户在改变被提交之前批准。如果改变具有高安全级别，则所选择的通知方法可包括更即时的通知形式，诸如启动文本消息，而不是在下一次登录时通知其他用户。通知和批准参数可适合于各种类型的关键级别系统改变。

根据一个实施例，通知至少一个其他用户包括以下的一个或多个：启动发送电子邮件给至少一个其他用户的过程；启动发送SMS消息给至少一个其他用户的过程；启动发送即时消息给至少一个其他用户的过程；启动通过电话联系至少一个其他用户的过程；启动向至少一个其他用户显示弹出消息的过程。因此，通知可以采用各种方式中的一个或多个发生。应当了解，内核自身并不用于发送电子邮件，但是如果在内核空间中实现，则实施例可操作以使得内核可用于将待定的需要批准的改变请求转移到适当的用户空间守护进程，该守护进程自身可用于向适当的用户通知改变请求。

第二方面提供一种计算机程序产品，其在计算机上执行时可操作以执行第一方面的方法。

第三方面提供了一种可操作以控制能够由用户实施的系统关键改变的操作系统，该操作系统包括：请求接待逻辑，其可操作以从用户接收进行系统关键改变的请求；权限评估逻辑，其可操作以评估该用户是否具有进行系统关键改变的适当权限；通知逻辑，其可操作以在该用户被评估为具有进行系统关键改变的适当逻辑的情况下，向具有进行系统关键改变的适当权限的至少一个其他用户通知所接收的请求；以及实施逻辑，其可操作以在实施所请求的系统关键改变之前，等待来自至少一个其他用户的批准。

根据一个实施例，用户和至少一个其他用户中的至少一个具有系统管理员权限。

根据一个实施例，用户和至少一个其他用户都具有系统管理员权限。

根据一个实施例，实施逻辑可操作以在实施所请求的系统关键改变之前，等待来自至少一个其他用户的异步批准。

根据一个实施例，接收、评估和通知逻辑在内核空间中运行。

根据一个实施例，接收、评估和通知逻辑在用户空间中运行。

根据一个实施例，接收、评估和通知逻辑如由操作系统运行的守护进程一样运行，该守护进程具有适当权限。

根据一个实施例，守护进程不能被操作系统的任何单个用户修改。

根据一个实施例，关键改变包括关键的操作系统级别操作。

根据一个实施例，操作系统包括配置逻辑，其可操作以确定能够由操作系统实施的哪些改变被认为是系统关键改变。

根据一个实施例，配置逻辑可操作以向能够由操作系统实施的每个系统关键改变分配安全级别，并根据所分配的安全级别，将通知和批准参数与系统关键改变相关联。

根据一个实施例，通知逻辑可操作以通过以下的一个或多个来通知至少一个其他用户:启动发送电子邮件给至少一个其他用户的过程；启动发送SMS消息给至少一个其他用户的过程；启动发送即时消息给至少一个其他用户的过程；启动通过电话联系至少一个其他用户的过程；启动向至少一个其他用户显示弹出消息的过程。

更具体和优选的方面在所附的独立权利要求和从属权利要求中提出。从属权利要求的特征可在适当的情况下与独立权利要求的特征相结合，并与其它没有在权利要求中明确提出的内容结合。

当装置特征被描述为可操作以提供功能时，应当了解，这包括提供该功能或者适于或被配置以提供该功能的装置特征。

附图说明

现在将参照附图进一步描述本发明的实施例，其中：

图1说明两个管理员批准过程的例子。

图2和图3是根据一个实施例示意性地说明批准进程的批准序列图。

具体实施方式

概述

在更详细地讨论实施例之前，首先将提供概述。各方面和实施例将操作系统扩展成提供执行需要两个或更多个管理员在改变被提交之前同意“关键”动作的接入控制模式。关键动作可根据具体实现来配置，但一般是与在操作系统或由操作系统提供的一个或多个服务的配置中进行可能破坏性的改变相关联的动作。

各方面和实施例提供一种操作系统，其具有操作系统OS或在软件堆栈的最低级别可用的服务的多重授权或多重批准管理，作为操作系统接入控制子系统的直接特征。换句话说，各方面和实施例提供一种操作系统，其如同具有多个管理员一样运行，其中两个或更多个管理员被要求在那些关键操作执行之前互相批准关键操作。应当了解，相互的多重批准过程自身也可用于将操作或进程定义为是关键的。

多级批准机制可以采用多种方式实现，例如：

·如在图1中示意性表明的2个管理员批准进程，根据该进程，Admin_1批准Admin_2的操作，反之亦然；

·n个管理员批准进程，根据该进程，一个管理员的操作必须经另一个管理员批准(单独批准)或经2个或更多个其他管理员批准(多重批准)。

操作系统的受到多重批准进程的关键操作或进程的例子例如包括：

·重新启动或关闭虚拟机或真机；

·文件和程序权限的修改；

·对安全设置应用改变(例如，防火墙政策)；

·对网络设置应用改变；

·访问属于另一个用户的其它敏感数据。

各方面和实施例可以在内核空间中实现，例如，作为接入控制列表的扩展，或者在用户空间中实现，例如，利用持续运行的不可修改的守护进程实现。

图2和图3是根据一个实施例的示意性说明批准进程的批准序列图。

根据一个实施例，适当的改变可以由UNIX系统实施适当以实现多重批准系统。合适的改变可以包括永久运行的进程，例如，称为approvald的守护进程，该守护进程具有特定的特性和所有权。

根据这样的实施例，超级用户根保留标准的UNIX定义的权限，并且是唯一的被配置为具有全部管理权限的用户。但是，根据一个实施例，在操作系统安装过程之后，管理员根的登录被永久并强制地禁用。用户根具有先前启动的批准守护进程，并且是唯一的在approvald上具有权限并与系统相关联的用户。也就是说，根“拥有”approvald守护进程，并且是系统中唯一的可启动和/或停止approvald守护进程的用户。

在图2和图3中，示出了两个可能的批准序列。根据所示出的例子，给定进程(process)的“关键”配置文件(process.conf)正被系统管理员(例如，admin_1)改变。

然而，由于process.conf已经被预先配置成“关键”进程，因此，只有approvald守护进程可提交对系统的永久改变。换句话说，提交进程需要执行对admin_1所提出的改变的附加检查。根据所示出的例子，批准守护进程运行以使得在改变被提交前所需的附加检查包括第二系统管理员(例如，admin_2)的检查和批准。

根据一些实施例，可以如下更详细描述地并如图2和图3所示地实现过程。

1.当admin_1尝试提交对process.conf进行的改变(例如，通过保存新的process.conf或重新启动process)时，向approvald守护进程通知该请求。例如，在图2和图3中，文本编辑器发送COMMIT_REQ(<user>,<file>)命令到approvald；

2.守护进程approvald用任何合适的通知方法(例如，电子邮件、即时消息、SMS、预先录制的电话、弹出消息)向admin_2通知已经对process.conf提出了改变；

3.守护进程approvald将COMMIT_REQ请求以APPROVAL_REQ(<user>,<file>)转发到admin_2。COMMIT_REQ可以是单独消息的一部分或者嵌入通知消息自身中。

4.因此，admin_2将检查admin_1所进行的改变，该改变可被批准(图2)或者被拒绝(图3)。对approvald的这些批准/拒绝消息分别用APPROVAL_ACK和APPROVAL_REJ表示。

5.最后，approvald通知(例如，直接或通过文本编辑器)admin_1关于对process.conf提出的改变所作出的决定。

各方面减少管理员错误率，并且可以大幅度地减少由于例如攻击者或恶意软件所执行的超级用户攻击而造成的损害。

各方面和实施例通过消除管理员的直接发布危险或破坏性的命令的能力来改进计算机系统的安全。

本领域的技术人员可以容易地认识到各种上述方法的步骤可由编程计算机执行。在此，一些实施例也意在覆盖程序存储设备，例如，数字数据存储介质，其是机器或计算机可读的，并对机器可执行或计算机可执行的指令程序进行编码，其中，所述命令执行以上描述的方法的一些或所有步骤。程序存储设备可以例如是数字存储器、诸如磁盘和磁带的磁性存储介质、硬盘驱动器、或者光学可读数字数据存储介质。实施例也旨在覆盖被编程以执行上述的方法的所述步骤的计算机。

在附图中示出的各种单元的功能，包括任何标以“处理器”或“逻辑”标签的功能块，可以通过使用专用硬件以及能够与适当的软件联合执行软件的硬件来提供。当由处理器提供时，功能可以由单个专用处理器、单个共享处理器、或者多个单独的处理器(其中一些处理器可被共享)提供。另外，术语“处理器”或“控制器”或“逻辑”的明确使用不应被理解为唯一指代能够执行软件的硬件，而可以隐含地包括但不限于数字信号处理器(DSP)硬件、网络处理器、专用集成电路(ASIC)、现场可编程门阵列(FPGA)、用于存储软件的只读存储器(ROM)、随机存取存储器(RAM)和非易失性存储器。其它硬件，传统的和/或定制的，也可以包括在其中。类似地，在附图中示出的任何开关只是概念性的。它们的功能可以通过程序逻辑的操作、通过专用逻辑、通过程序控件和专用逻辑的交互、或者甚至手动地完成，随着根据上下文更具体地理解，特定的技术可由实施者选择。

本领域的技术人员应当了解，在此的任何框图表示体现本发明原理的说明性电路的概念观点。类似地，应当了解任何流程表、流程图、状态转移图、伪代码等表示各种进程，其可基本上在计算机可读介质中表示，并由计算机或处理器执行，无论这样的计算机或处理器是否明显示出。

描述和附图仅仅说明本发明的原理。因此，可以理解，本领域的技术人员能够设计各种安排，这些安排虽然在此没有明确描述或示出，但体现本发明的原理，并被包括在其精神和范围内。此外，在此记载的所有例子主要旨在仅用于教育目的以帮助读者了解本发明的原理以及发明人对现有技术贡献的概念，并且应当被理解为对具体记载的例子和情况没有限制。此外，在此所有关于本发明的原理、方面、和实施例及其特定例子的文字陈述旨在包含其等同物。

Claims

1.一种控制能够由操作系统的用户实施的系统关键改变的方法，所述方法包括：

从用户接收进行系统关键改变的请求；

评估所述用户是否具有进行所述系统关键改变的适当权限；

如果所述用户具有进行所述系统关键改变的适当权限，则向具有进行所述系统关键改变的适当权限的至少一个其他用户通知所接收的请求；以及

在实施所请求的系统关键改变之前，等待来自至少一个所述其他用户的批准。

2.根据权利要求1所述的方法，其中，所述用户和所述至少一个其他用户都具有系统管理员权限。

3.根据权利要求1或2所述的方法，其中，所述批准和实施相对于所述请求的所述接收异步地发生。

4.根据权利要求1至3中任一权利要求所述的方法，其中，接收、评估和通知在内核空间中实施。

5.根据权利要求1至3中任一权利要求所述的方法，其中，接收、评估和通知在用户空间中实施。

6.根据权利要求5所述的方法，其中，接收、评估和通知由所述操作系统所运行的守护进程实施，所述守护进程具有适当权限。

7.根据权利要求6所述的方法，其中，所述守护进程不能被所述操作系统的任何单个用户修改。

8.根据权利要求1至7中任一权利要求所述的方法，其中，所述系统关键改变包括关键的操作系统级别操作。

9.根据权利要求1至8中任一权利要求所述的方法，包括：配置能够由操作系统实施的哪些改变被认为是系统关键改变。

10.根据权利要求1至9中任一权利要求所述的方法，包括：向能够由操作系统实施的每个系统关键改变分配安全级别，以及根据所分配的安全级别，将通知和批准参数关联到所述系统关键改变。

11.根据权利要求1至10中任一权利要求所述的方法，其中，通知至少一个其他用户包括以下的一个或多个：启动向所述至少一个其他用户发送电子邮件的过程；启动向所述至少一个其他用户发送SMS消息的过程；启动向所述至少一个其他用户发送即时消息的过程；启动通过电话联系所述至少一个其他用户的过程；启动向所述至少一个其他用户显示弹出消息的过程。

12.一种计算机程序产品，其可操作为在计算机上执行时执行权利要求1至11的任何一个的方法。

13.一种操作系统，可操作为控制能够由用户实施的系统关键改变，所述操作系统包括：

请求接收逻辑，其可操作为从用户接收进行系统关键改变的请求；

权限评估逻辑，其可操作为评估所述用户是否具有进行所述系统关键改变的适当权限；

通知逻辑，其可操作为如果所述用户被评估为具有进行所述系统关键改变的适当权限，则向具有进行所述系统关键改变的适当权限的至少一个其他用户通知所接收的请求；以及

实施逻辑，其可操作为在实施所请求的系统关键改变之前，等待来自至少一个所述其他用户的批准。