WindowsVista的服务.docx

WindowsVista的服务.docx

《WindowsVista的服务.docx》由会员分享，可在线阅读，更多相关《WindowsVista的服务.docx（14页珍藏版）》请在冰豆网上搜索。

WindowsVista的服务

WindowsVista的效劳

本文档提供了一些WindowsVista效劳的相关信息。

对于想在这个版本的Windows上面开发效劳程序的开发者们，本文档也提供了一些最优方法。

这些信息应用在Windows操作系统上。

微软可能会随时更改本文档内容，可在以下地址获取最新的英文版本。

Windows效劳概述

MicrosoftWindows效劳就是程序，通常，它们虽Windows一起启动，并在后台运行，直到被关闭。

严格一点说，效劳就是所有用效劳API实现的Windows程序。

通常，效劳处理一些低级别的任务，这些任务很少需要和用户交互。

尽管效劳对于用户通常是不可见的，但Windows功能又离不开他们。

效劳处理许多重要的操作系统功能，包括：

1、联网。

很多系统效劳支持联网。

比方动态主机配置协议〔DynamicHostConfigurationProtocol,DHCP〕客户端效劳通过存储和更新系统的IP地址来管理网络配置。

2、硬件。

即插即用效劳〔PlugandPlay〕使计算机可以识别硬件配置的变化并做出响应，例如用户添加或者卸载了一个硬件。

3、远程访问。

终端效劳〔TerminalServices〕允许用户在远程登陆计算机。

除了Windows自带的效劳，大局部计算机还会运行很多第三方的效劳。

见到最多的就是防火墙和防病毒程序。

效劳怎样运行

效劳和一般程序最主要的区别是，效劳被效劳控制管理器〔ServiceControlManager,SCM〕管理。

使用效劳API实现效劳，这些API处理效劳和SCM之间的交互。

SCM维护一个数据库，这个数据库放置了所有已安装效劳的信息，并提供一个统一的方法来控制这些效劳：

1、开始和停止效劳。

2、管理正在运行的效劳。

3、维护效劳相关的状态信息。

效劳有三种状态：

已运行，已停止，已暂停。

1、已运行是效劳的一般运行状态。

2、已停止的效劳已经完全关闭，必须经过一个启动过程，才能再次进入已运行的状态。

3、已暂停效劳中止处理，但是还驻留在内存中，并且继续响应控制请求。

以暂停的效劳可以跳过启动过程直接进入以运行的状态。

效劳的一个关键的特征是它怎样被启动。

SCM管理的数据库里有这样的信息。

有三种启动模式：

1、自动。

在系统引导中，SCM自动启动这些效劳。

2、手动。

想启动这类效劳，必须利用控制面板中的管理工具。

3、禁用。

这些效劳不能被启动。

要想启动这类效劳，用户必须把启动模式调整为自动或者手动

当效劳启动后，SCM利用控制请求来管理效劳的状态。

比方，SCM向效劳发送控制请求，通知效劳暂停，继续运行，或者准备关闭。

SCM的数据库也包含了效劳的平安设置。

这些设置控制效劳有多少权限去访问系统资源，也使得系统管理者可以控制每个效劳的权限。

WindowsVista中Windows效劳的变化

多年来，效劳已经成为Windows一个重要的组成局部。

它使得开发者们可以创立长时间运行的程序：

1、可以随计算机自动启动。

2、可以被暂停和重开。

3、无论用户登陆与否，都能运行。

4、可以运行在一个独立的账户环境下，这个账户可以不同于已登陆的账户和默认账户。

这些特点使得效劳可以长时间的运行，而不干扰在同一计算机上工作的用户。

自从效劳概念的引入，效劳的运行环境已经发生了很大的变化。

这些变化已经带来了一些很多问题：

平安性、可靠性、性能、操作和管理。

这一节，讨论一下对于WindowsVista做出的改良。

平安性增强

近些年，效劳已经成为那些病毒制造者们的目标。

最近的例子有：

“Blaster〞、“Sasser〞、和“CodeRed〞。

对于这个现象，有很多原因：

1、效劳根本上都在长时间运行。

通常，从系统启动到关闭，它们都在运行。

2、效劳通常都是面向网络的，这使得他们极易受到远程攻击。

3、效劳根本上以高权限账户运行，比方LocalSystem。

这一节，讨论一下对于WindowsVista做出的改良，这些改良为了缓和效劳的平安问题。

这些改变有两个重要的目的：

1、限制用户程序访问效劳。

会话0隔离〔Session 0isolation〕要求效劳和用户程序运行在隔离的会话里。

2、“固化〞效劳使不平安效劳破系统的可能性降低。

有以下两个互补的方法来到达这个目的：

●最小权限，使得效劳运行在它所需要的权限范围内，做不了其他的事情。

●效劳隔离，利用唯一的效劳标识，使效劳如其他效劳和程序隔离开。

效劳可以利用这个标识来限制其他效劳和程序对它的资源的访问，也可以限制自己对其他效劳和程序的资源访问。

比方，效劳隔离允许防病毒效劳维护签名定义文件的专门入口。

以最小权限运行

Windows效劳通常以LocalSystem账户运行，这个账户具有系统的最高权限。

这样的效劳成为病毒制造者很有吸引力目标。

理想情况下，效劳应该以低权限级的LocalService或者NetworkService账户运行，从而减小对系统潜在的破坏。

但是，很多效劳需要的一些权限只有LocalSystem能够支持。

在WindowsVista之前就用的“all-or-nothing〞模型意思是，效劳得到了一些LocalSystem的权限后，它也同时具有了LocalSystem的所有其他权限。

这意味着很多时候，效劳所具有的权限不是它所需要的，产生对系统潜在的破坏性。

WindowsVista允许效劳以最小权限运行，解决了这个问题。

效劳不会再被标准账户支持的默认权限所限制。

效劳可以选择账户，这个账户有他们需要的权限，之后，效劳还可以去掉所有它不需要的权限。

这个功能可以用于所有的账户类型：

LocalService，NetworkService，LocalSystem，一个域，或者一个本地账户。

效劳利用一些机制来声明他们所需要的权限，这些机制将在之后讨论。

当SCM启动效劳时：

1、对于独立的效劳，SCM逆着对照进程标记符检查权限需求列表，所有没有被要求的权限都会被从进程标识符上去掉。

2、对于共享的效劳，例如svchost的效劳宿主，在这个组里的所有效劳需要的权限合并成权限列表。

SCM只将没有任何一个成员效劳需要的权限从进程标识符上删除。

3、如果效劳没有申明需要的权限，SCM假设效劳需要与账户相关的所有权限。

这样确保了向后兼容性。

但是，如果效劳组中有一个这样的效劳，组中的其他效劳也都以账户默认的一组权限运行。

如果进程标识符里没有效劳要求的权限，SCM不会启动这个效劳。

比方，以NetworkService账户运行的程序可以将SeTcbPrivilege指定为需要的权限。

但是，NetworkService进程标识符不支持SeTcbPrivilege，所以启动失败。

怎么指定所需权限

1、——管理效劳的命令行工具——有两个新命令，支持为效劳指定所需权限。

●privs这个命令为效劳设定一个权限。

privs的语法是：

scprivs[Privileges]

●qprivs这个命令查询效劳需要的权限，qprivs的语法是：

scqprivs[servicename]buffersize

Privileges是一个字符串，包含权限列表，以斜杠分开〔/〕。

例如，指定备份和恢复权限，将Privileges设置成“SeBackupPrivilege/SeRestorePrivilege〞。

2、利用程序指定需要的权限，以下面的值为参数调用ChangeServiceConfig2：

●将dwInfo参数设置为

SERVICE_CONFIG_REQUIRED_PRIVILEGES_INFO

●使lpInfo指向一个SERVICE_REQUIRED_PRIVILEGES_INFO结构。

这个结构包含了一个字符串，字符串列出了需要的权限。

使用QueryServiceConfig2查询效劳需要的权限。

权限的变化将在效劳下一次启动时生效。

注意一点，不管是命令行工具还是函数，都会检查列表中的权限是否有效，但是它们不能确定效劳是否支持指定的权限。

这个工作是由SCM在试图启动一个效劳的时候做的。

注意：

权限列表只能被那些具有SERVICE_CHANGE_CONFIG权限的调用程序更改。

默认情况下，只有本地管理员，权力用户和效劳器操作员可以在远程或者本地取得得到这个权限。

具有SERVICE_QUERY_CONFIG权限的调用程序可以查询需要的权限的列表。

默认情况下，只有本地管理员，权力用户和效劳器操作员可以在远程取得得到这个权限，效劳和交互的用户可以在本地取得这个权限。

效劳隔离

许多效劳需要访问一些特定的对象，而这些对象只有高权限账户才能访问。

比方，效劳可能要向注册表写值，而注册表只有管理员能够访问。

在WindowsVista以前的系统中，效劳以象LocalSystem这样的高权限账户运行，从而得到访问这些对象的权限。

还有一个做法，就是降低这些对象的平安性，使具有低权限的效劳已可以访问它们。

这两个方式都有可能使攻击者或病毒得到系统的控制权。

对于管理员，唯一可以降低这个风险的方法是，建立一个效劳的专有账户，只让这个账户具有访问这些对象的权限。

但是，这样又带来了管理效率的问题：

大量的密码管理，因为管理员再也利用不到使用系统内置账户的好处了。

为了缓和这个问题，WindowsVista引入了效劳隔离，它给效劳提供了一个访问特定对象的方法，既不需要以高权限运行，又不需要降低对象的平安。

例如，效劳隔离允许一个反病毒效劳运行在比LocalSystem权限更低的账户下，但这个反病毒效劳还能完全访问它的特征定义文件或者注册表，通常这些只有管理员可以访问。

效劳隔离是一个专门用来保护资源〔比方访问文件或者注册表的访问〕的对象，它有一个包含效劳平安ID〔servicesecurityID,SID）的权限控制表。

我们把这个ID叫做“per-serviceSID〞，它来源于效劳的名字，对于效劳是唯一的。

SID被分配给效劳之后，效劳的所有者就可以更改所需的对象的权限控制列表〔accesscontrollists,ACLs〕，使得效劳可以访问这个对象。

例如，具有管理权限的效劳才能够访问注册表键值HKEY_LOCAL_MACHINE\SOFTWARE。

把per-serviceSID添加到这个键值的ACL里，效劳就可以运行在权限更低的账户下，但还可以访问这个键值。

如果per-serviceSID被启用，它被添加到效劳的进程标识符里。

注意，在效劳的进程被添加到进程标识符里的同时，必须启用per-serviceSID。

per-serviceSID也允许，向进程标识符里添加几个SID之后，把进程标识符转换成一个限制标识符。

利用受限SID减少潜在破坏

使用per-serviceSID，提供了良好的隔离程度，并且允许效劳运行在更低的权限账户下。

但是，它并不阻止效劳访问账户可以访问的资源，因为进程标识符包含了账户的SID。

考虑下面的情况：

X效劳以LocalService账户运行，并且启用了SID。

除了可以访问已经明确给予它访问权限的那些对象，它还可以访问LocalService账户可以访问的所有对象。

如果这个效劳涉及平安问题，攻击者可能利用它访问与这个效劳不相关的资源，从而破坏系统。

为了缓和这个问题，降低涉及平安问题的效劳对系统造成破坏的可能性，WindowsVista结合写限制标识符〔write-restrictedtokens〕和per-serviceSID为效劳引入受限SID。

效劳启用受限SID时，效劳的SID被添加到写限制效劳进程标识符的正常和受限SID列表中。

这样保证了，只有明确地将对象的写权限赋予受限列表中的SID时，效劳才可以写对象。

回到上面的例子，启用受限SID，X效劳将没有权限写入访问LocalService账户可以访问的对象，因为效劳X的per-serviceSID没有被明确地赋予这些对象的写权限。

怎样指定per-serviceSID

1、要指定per-serviceSID，SID的种类必须设定为SERVICE_SID_TYPE_UNRESTRICTED。

如果效劳不需要SID，可以不设置SID类型，或者把它设置为SERVICE_SID_TYPE_NONE。

设置了类型之后，SID在下一次进程创立的时候被添加到进程标识符里。

可用以下两种属性激活SID：

●SE_GROUP_ENABLED_BY_DEFAULT

●SE_GROUP_OWNER

存取控制表也扩充了效劳的进程标识符，它为效劳登陆SID提供GENERIC_ALL权限。

这就允许在效劳启动或者停止的时候，激活或者禁用进程标识符中效劳的SID。

SID被添加到进程标识符之后，它就不能被去掉了。

SID的类型必须改变，之后进程必须被重新利用。

这个改变只会发生在进程重开的时候。

2、要把进程标识符设置成写入限制的。

SID必须设置成为SERVICE_SID_TYPE_RESTRICTED。

使用SERVICE_SID_TYPE_RESTRICTED类型，必须要考虑几个问题。

●如果进程包含多个效劳，所有的这些效劳都必须设置成SERVICE_SID_TYPE_RESTRICTED。

否那么，设置成为SERVICE_SID_TYPE_RESTRICTED的效劳都会启动失败。

●三个SID被自动地参加到受限列表：

Ø通用SID〔WorldSID〕〔S-1-1-0〕。

这个SID为效劳提供所有ACL支持通用SID的对象的写权限。

通用SID提供访问装载路径中的一些动态连接库的权限。

Ø效劳登陆SID。

这个SID提供那些连接效劳进程和SCM的命名管道的写权限。

Ø写限制SID〔S-1-5-33〕。

这个SID允许对象拥有一个ACL，使得所有写限制的效劳进程可以写入对象。

一个常见的例子就是Windows的事件跟踪对象〔eventtracingforWindows（ETW）objects〕。

3、e有两个支持per-serviceSID的新命令：

●Sidtype。

这个命令改变效劳的SID。

命令的语法为：

scsidtype[servicename][type]

●Qsidtype。

这个命令找回效劳的SID设置。

命令的语法为：

scqsidtype[servicename]

4、如果要编程设置这个标志，调用ChangeServiceConfig2，用下面的属性值作参数。

在系统下一次启动时，改变将会生效：

●将dwInfo设置为SERVICE_CONFIG_SERVICE_SID_INFO。

●使lpInfo指向一个SERVICE_SID_INFO结构。

这个结构包含一个DWORD成员，这个成员包含SID类型。

5、两个关联的公共函数对于效劳所有者也很有用：

●LookupAccountName，传入SID，返回相关的效劳名。

●LookupAccountSID，传入效劳名，返回相关的SID。

6、也可使用来得到指定的效劳的效劳SID。

下面的命令返回一个效劳的SID。

Scshowsid[servicename]

注意：

调用者必须拥有SERVICE_CHANGE_CONFIG权限才能改变这些设置。

默认情况下，只有管理员，权力用户，效劳器操作员可以在远程或者本地得到这个权限。

另外，效劳和交互用户可以在本地得到SERVICE_CHANGE_CONFIG权限。

受限的网络访问

很多效劳都是面向网络的，使得他们很容易受到远程攻击。

效劳固化在WindowsVista和MicrosoftWindowsServer®CodeName"Longhorn"中，这样允许开发者减少效劳对网络资源的访问，这些资源包括端口、协议、网络通信方向。

比方，DHCP效劳——更新系统的IP地址——可以把它自己限制到本地68端口，入站的用户数据报协议通信在远程的67端口。

翻开或者监听其他端口的企图，都会被WindowsVista和WindowsServerLonghorn的防火墙阻止。

WindowsVista和WindowsServerLonghorn支持下面这几种效劳网络限制的情况：

情况

举例

限制

无网络权限

Shell硬件检测效劳（ShellHWDetection）

效劳不可能监听或者连接到网络

监听静态的TCP或者UDP端口

远程过程调用效劳〔Rpcss〕，在135端口上

效劳只能监听指定的终端

监听可配置的TCP或者UPD端口

域名效劳（DNS）

效劳可以监听配置的终端

效劳网络限制和per-serviceSIDS一起使用。

这个机制有点像用于限制效劳的文件或注册表的权限，这在“效劳隔离〞中讨论过了。

WindowsVista和WindowsServerLonghorn的防火墙API已经被加强，提供这些必要的支持。

INetFwServiceRestriction接口包含了限制效劳网络权限的方法。

要取得更多信息，请看“因特网连接共享和因特网连接防火墙〞，在本文档最后的“资源〞一章。

下面的MicrosoftVisualBasic脚本使用防火墙API，把6to4效劳限制到端口500，只接受入站。

'requirevariabledeclarations

optionexplicit

'handleerrors

onerrorresumenext

'direction

ConstNET_FW_DIRECTION_IN=1

'CreatetheFwPolicy2object.

DimfwPolicy2

SetfwPolicy2=CreateObject（"HNetCfg.FwPolicy2"）

DimFwSvcRestr

rviceRestriction

'restrictservice

FwSvcRestr.RestrictService"6to4","c:

\windows\system32\svchost.exe",TRUE,TRUE

'Createanewrestrictionrule

DimNewRule

setNewRule=CreateObRule"）

NewRule.Name="6to4500"

NewRule.Description="Allow6to4toreceiveTCPtrafficonport500"

NewRule.ApplicationName="c:

\windows\system32\svchost.exe"

NewRule.ServiceName="6to4"

NewRule.Protocol=6

NewRule.LocalPorts="500"

n=NET_FW_DIRECTION_IN

NewRule.Enabled=TRUE

'AddthebehaviorruletotheWSHstore.

fwPolicy2.ServiceRestriction.Rules.AddNewRule

会话0隔离

Windows把每个同时登陆的用户放到不同的会话里面，从而提供多用户登陆功能。

系统启动中建立会话0，如果需要，还会建立更多会话。

在WindowsVista之前的系统中，效劳总是运行在会话0中，用户程序也可以运行在会话0中。

比方，WindowsXP激活快速用户切换〔FastUserSwitching,FUS〕后，第一个登陆的用户被分配到会话0，这个用户的所有程序也运行在会话0下。

第二个登陆到系统的用户就被分配到会话1上，如此等等。

1、效劳和用户程序运行在同一个会话里，造成了很多平安问题。

为了解决这个问题，WindowsVista对会话0作了两个重要的改变。

●会话0被留用给那些所有与交互用户会话没有关系的效劳和其他程序。

用户程序必须运行在会话1上，或更高的会话上。

●会话0不支用户界面。

详细点说，运行在会话0上的程序没有权限使用图形硬件，不会在显示器上显示用户界面。

2、对于效劳，会话0隔离还有很多隐含的意义，包括：

●效劳不能使用PostMessage或者SendMessage向用户程序发送消息。

运行在会话1和其他会话上的程序都有不同的消息队列。

同理，程序也不能向效劳发送Windows消息。

效劳要给程序发送消息，必须利用一些类似于远程过程调用或者命名管道的机制。

●具有用户界面的效劳——比方有一个对话框——不能在WindowsVista中直接显示出来。

效劳只能间接的处理和用户的交互。

对于简单的交互，效劳可以调用WTSSendMessage，在用户的会话上显示一个消息窗。

对于复杂的交互，效劳必须调用CreateProcessAsUser或使用其他方法，在用户的会话上创立一个用户界面程序。

这个界面程序处理用户的交互，并且使用远程过程调用户或者命名管道来个效劳通信。

要取得更多有关WindowsVista中会话0的信息，以及编写WindowsVista效劳的指导信息，请看本文档末尾“WindowsVista效劳和驱动的会话0隔离带来的影响〞一章。

性能的增强

延时自动启动

在WindowsVista之前，有两个启动效劳的方法：

自动启动和按需启动。

自动启动的效劳在系统引导的时候启动。

有几种方法可以启动按需启动的效劳，但这些都需要用户手动崇启这些效劳。

1、把一个效劳定义成自动启动效劳，主要原因有两个：

●这个效劳必须在引导程序中较早的启动，因为其他效劳依赖它。

●管理员通常需要一些没有用户交互的效劳无人值守地启动。

这样保证在需要时，效劳总是可用的。

自动启动效劳的问题是，它们数量不断增加，影响了系统启动的速度。

但是，很多效劳属于上面两种原因中的第二种。

它们并不需要成为系统引导队列的一局部；只是在系统启动完成之后，它们可以无人值守地启动，并且在需要时随时可用。

WindowsVista提供了一个不同的自动启动模式——延时启动，解决了在引导过程中，效劳对性能的影响。

被指定成为延时自动启动的效劳会在系统启动完成后，自动启动。

他们不会在系统引导的过程中自动启动，只是在系统引导完成后稍短的时间内启动。

这样不仅提高了系统引导性能，还可以使效劳无人值守地启动。

2、在把效劳指定为延时自动启动之前，开发人员和管理员们应该考虑下面几个问题：

●了解效劳的依赖。

如果因为另一个必须在引导过程中启动的效劳依赖这个效劳，就不要把这个效劳标记成为延时启动效劳。

SCM会忽略标记设置而在引导过程中启动这个效劳。

●对于延时启动效劳，没有明确的延时时间。

如果用户程序在延时效劳启动之前试图使用它，将会失败。

如果用户程序依赖一个延时启动效劳，它就应该处理这种失败情况，或者一段时间后重试，或者调用StartService启动效劳。

如果这样的失败情况总是发生，可能把效劳设置成延时启动并不是一个好选择。

●延时启动效劳不属于装载顺序组〔load-ordergroup〕。

它们属于独立组〔stand-alone〕。

怎样效劳指定为延时自动启动

要将创立一个延时自动启动效劳，就设置延时自动启动标志。

虽然所有效劳都能设置这个标志，但它只对自动启动效劳有效。

如果自动启动效劳被设置成为延时自动启动，那么在引导队列完成以后，它才会被启动。

其他启动类型会忽略这个标志。

1、e有两个支持延时自动启动的命令

●delayflag。

这个命令改变延时自动启动标志的设置。

命令的语法为：

scserverdelayflag[servicename][fla