几个改进的想法
这个帖子缘于石头的帖子：[url=http://bbs.kafan.cn/viewthread.php?tid=304614]http://bbs.kafan.cn/viewthread.php?tid=304614[/url][quote]原帖由 [i]中网S3[/i] 于 2008-8-12 07:43 发表 [url=http://bbs.kafan.cn/redirect.php?goto=findpost&pid=4466791&ptid=304614][img]http://bbs.kafan.cn/images/common/back.gif[/img][/url]
S3没有内置多少规则，只是一些危险的行为不想让用户决定，比如类似于Image File Execution Options注册键、和autorun.inf 相关的文件和注册键值，以及直接文件读写磁盘的操作。函数调用的问题值得考虑，这是以前为了应付那些稀奇古怪的测试工具不得已的下策，比如拦截icmp.dll的某个函数。如果我在防火墙中内置不允许发送icmp请求的规则，却无法询问，如果不拦截这个dll这个函数，icmp包就会把数据发送出去，测试就会无法通过。但是形如icmp.dll的函数何止千万，没有办法也只好在getprocaddress上做文章了，这只能应付测试，却不实用，没有几个人对调用函数都了如指掌。
explorer进程的确比较难处理，这个进程规则太严非常容易让任务栏卡死。但是很多测试程序leaktest大都是围绕它展开，动不动就是让cmd.exe发起一个explorer.exe [url=http://www.xxxxx.com/?user=a&password=b][color=#000000]http://www.xxxxx.com/?user=a&password=b[/color][/url]的进程，如果你让它成功运行了，即便你把网线拔掉，它也会认为你没有通过。另外explorer.exe和svchost.exe是autorun.inf自动运行的发动机，同时也是用户文件操作、运行程序的寄主程序。放行还是阻止,询问还是预置规则，高级用户是否顺手，初级用户能否搞定，都是需要考虑的问题。
安装完以后，都要学习一遍，或者弹框一轮，是否多余。当然这些问题只要提出来，我们肯定会认真考虑的。
[/quote]
我的意思和石头差不多：
一、内置规则不是说不可以，不过最好能让用户知道有哪些内置的规则，不然用户容易在某些操作被内置规则拦截时犯迷糊。比如可以考虑在规则列表中列出来，但是为灰色不可改动状态。这点可以参考Malware Defender，它针对一些系统程序也设了内置规则，就是这么处理的。
二、关于报函数调用的问题，从触发情况的复杂性来看似乎也只能如此，就还是维持这种作法吧，不过弹框信息以及生成的规则中最好描述清楚这个函数的功能与用途，如果允许可能产生的后果等，这样可以在一定程序上解决用户对函数不了解的问题。不过视目前拦截的函数数量，这个工作量可能会比较大。
另外，目前规则中没有描述一栏，回头用户查看或整理规则时还是可能会看不懂。建议在规则中增加备注或描述栏目。
三、关于explorer，毕竟explorer是经常容易被利用的宿主之一，我觉得还是严一点比较好。当然，这个度确实比较难把握，我有个思路，不知道可行不：对系统第一个explorer进程（Shell）限制松一些，就象现在这样，而对其它explorer实例则进行严格限制。这样处理我想应该是一个比较折衷的办法，应该可行，不过这需要S3在检测到explorer进程创建时增加一个判断动作。
四、S3目前是没有AD分组以及权限继承的概念的，我还是建议加上，如果说S3目前的架构要处理权限继承问题改动量比较大的话，至少分组可以先做。（AD、ND分组我都提了好多次了，不好意思哈！）
五、新进程创建的弹框增加“进入安装状态”选项，对于选择进入安装状态的进程，内置规则：
创建文件夹或文件——允许
在其创建的文件夹下写入文件——允许
创建新的注册表项——允许
在其创建的注册表项下写入注册表值——允许
对于以上几种行为直接过，其它该弹框的仍然弹框（比如加驱、修改非其创建的注册表项等等），这样既不会放得太开，也可以减少大量弹框。
[[i] 本帖最后由 Devy 于 2008-8-12 14:05 编辑 [/i]] 支持，希望s3越来越好，加油！ 补充楼主
ND要加强一下..
另外问一下：AD还是“文件名+路径”吗？ 版主的建议很好 希望中网考虑 支持，希望s3越来越好，加油！
我坚决支持中网s3，我现在又改用中网s3了。一个半月前也是看了EQSecure论坛那个热，用的人多，说优点的也不少，我动摇了，我也报试试的态度安了EQSecure，哪个郁闷那 ！！！！
回复 5楼 keliyuan 的帖子
每个软件都有自己的优点和粉丝群，没什么好跟风的，用适合自己的就好。：） 嗯ad权限组 [quote]原帖由 [i]Devy[/i] 于 2008-8-12 14:03 发表 [url=http://bbs.kafan.cn/redirect.php?goto=findpost&pid=4470130&ptid=304986][img]http://bbs.kafan.cn/images/common/back.gif[/img][/url]
这个帖子缘于石头的帖子：[url=http://bbs.kafan.cn/viewthread.php?tid=304614]http://bbs.kafan.cn/viewthread.php?tid=304614[/url]
我的意思和石头差不多：
一、内置规则不是说不可以，不过最好能让用户知道有哪些内置的规则，不然用户容易在某些操作被内置规则拦 ... [/quote]
1.内置规则是程序员的一种偷懒行为，再没有比直接返回deny，无需交互更简单、更放心的做法了，交互相形起来就不那么让人放心，会一定程度上增加系统响应迟钝的机会。自定义规则除非用户有精力有耐心，一些用户会更喜欢完全信任、完全不信任、内置规则，完全不保护模式，这种无需干预的工作模式。另外一些内置处理做了大量判断和分析，这些处理过程很难用统一的规则模式来描述出来，比如规则一般不包含父进程的关系约束。 第一个explorer.exe进程和用户发起的explorer。exe,两者的父进程是不同的，如果需要对两者区别对待，用规则进行约束就比较困难。还有就是IE发起的进程问题，IE缓冲区溢出时会触发一个进程，同样用户直接使用IE下载，下载完成后直接运行程序也会触发进程，这两种情况完全放开或者完全拒绝都会给用户带来种种不便。内置处理可以通过编程分析的办法来判断某个进程的运行是用户自己手工下载的，还是溢出造成的。当然这种分析有时是费力不讨好。
当然这些意见提过多次了，一部分用规则描述出来了，一部分还没有完全解放，其实内置的规则并不多，其实我也明白这个道理，如果内置的规则多了，意味着需要大量的硬编码，程序维护就会越来越费劲。 2. 函数调用或者系统调用一方面是为了未知动态链接库、未知函数调用进行监控，这类规则只能通过询问框进行添加，采用这种一致的接口方式，是避免底层和上层交互式频繁地改变接口的结构。这样只要按照函数名称、函数描述、参数名称、参数描述等信息填充后，上层的应用不需要做任何修改，对于任何新增的函数和调用拦截，都是进行询问，无需做任何编码的调整。
当然这种调用，用户是否认可是另外一回事，因为他们大多不一定看懂这些询问框是什么意思，对询问框往往无所适从。
规则描述的问题，一般只对于预置规则可行，对于询问框添加的规则，我想大多数用户会更关心规则主体的属性。如果是良民，他们一般是完全信任，如果不是，他们多数会选择卸载而后快。其他情况，他们一般搞不定了。当然我可能犯了主观主义的错误，对用户未必真正了解，低估了初级用户的能力。
也就是说如果需要对规则进行描述的话，这些描述也只能产生一个大概的描述，由用户自己来编辑和完善，按照自己的口味来定制规则描述信息。
[[i] 本帖最后由 中网S3 于 2008-8-15 14:58 编辑 [/i]] 3.Explorer.exe进程的问题的确比较棘手，因为这个进程可以轻松被杀死，也可以手工创建，大多数用户安装程序、文件管理都是在这个进程里完成，处理不好，会带来很多麻烦。因为S3拦截的调用不只是AD、FD、ND和RD，还包括窗口消息，任务栏、状态区、桌面的交互涉及了大量和Explorer进程的窗口消息，这些窗口消息有时是发给另外一个进程的。前一阵子桌面比较卡，反应迟缓，没有办法只好把Explorer 相关的一小部分窗口消息给预先放走了。不过Exploer被排斥在系统保护程序之外，不是S3内置的系统保护程序，如果只是对其ND、RD和FD进行限制的话，手工定义的规则应该能够生效。
判断是否是第一个Explorer可以通过父进程来判断，这一点没有问题，但问题是Explorer.exe进程的多数行为主要是用户触发的，对这个进程预置规则，限制太多会带来一些不便。不过可以考虑将它的预置规则拿出来。
[[i] 本帖最后由 中网S3 于 2008-8-15 15:12 编辑 [/i]] 另外还有一点需要澄清的是，除了底层驱动做了规则判断之外，应用层出于减少询问框，也做了大量的规则，最简单的例子就是判断是否是系统保护文件、是否有合法的数字签名，这些情况可能会在某种设置情况下被予以放行，而不再询问，所以对于没有询问放行的情况，未必都是驱动里面内置了大量的规则，驱动里面的确没有预置多少规则。
在“帮用户拿主意”和“让用户拿主意”之间，我已经徘徊了好久。 4.第4条涉及重大改进，我尚不清楚权限继承和分组到底是什么样子，需要多大的变化，有的东西说起来容易，实现起来就比较难，尤其是我们人手紧张的情况下，架构太复杂，我也很难驾驭。关于这一条我可以私下和lz沟通一下。我们休息了一周，下周一正式上班。 5.安装状态可以研究
安装问题已经被论坛网友提过多次，主要是弹框太多的问题，S3的弹框类型很多，涉及进程互操作、窗口消息、系统调用、关机操作、keylogger、窗口钩子.安装驱动等等，很多类别不能简单地划归到RD、AD、FD的范畴，即使XD（RD、ND、FD）不弹了，还有可能其他询问框，而且数目可能还比较多，因为安装产生的文件多为新文件，还没有来得及为其准备规则。比如函数调用，也很讨厌。出于这种考虑，才提出和父进程完全信任、子进程也被信任的安装状态。当然这也没有做好，现在发现应用层拦截还是会弹框的，可能还需要修改。
另外一个问题是一些安装程序在安装过程中会先释放出一大堆临时文件比如_setup.tmp等等，然后再运行_setup.tmp文件，信任继承的安装状态可以解决这类程序的安装。当然一些共享软件比如暴风影音、QQ、快车等等往往会在安装过程中会附加安装第三方的软件比如google工具条、google拼音，我想与其在弹框过程中拦截这些附加程序的安装，还不如在这些程序的安装选项对话框，勾掉这类插件的安装。
询问框比较适合对某些可疑的程序调试运行，通过询问框来了解这类程序都干了些什么，特别是那些测试hips性能的程序以及病毒样本。如果对所有的安装的程序都调试和询问的话（就是说询问框比较多），可能浪费用户很多时间和光阴，大多数用户还是比较喜欢无人值守的安装，不过也不喜欢偷偷摸摸安装一大堆流氓软件。 我很欢迎和感谢楼主这些想法，我提出自己的看法并不意味着我对楼主的意见无动于衷，我很愿意用自己的劳动满足包括楼主在内的用户需求。 好~ 中网s3的说法很中肯 慢慢沟通 相信会做出出色的s3！
ad、nd分组可以参考ca hips ，和权限分组相似 是预先设定好权限（包括运行、不容许程序执行行为和容许执行行为的ad、nd）组别，这样，如果有未知程序可以直接把它归属到相应权限的组别中，而且组对象权限应该有继承（即子进程不能超过父进程的权限），比每单个程序规定相应的ad、nd要方便直观的多，当然还可以自己单独制定这个程序的规则。 内置规则的放开 ，特别是explorer，有助于客户了解explorer的运行情况，以便制定自己相应的规则，当然s3可以将内置规则放开后，放到默认的规则中，先行勾选执行（便于开机启动、初始运行不蓝屏等），客户可以根据自己的情况再制定详细的规则，同时大家可以交流讨论相应规则细节，更能激活对s3的热情。
回复 8楼至14楼 中网S3 的帖子
[quote]原帖由 [i]中网S3[/i] 于 2008-8-15 14:45 发表 [url=http://bbs.kafan.cn/redirect.php?goto=findpost&pid=4499598&ptid=304986][img]http://bbs.kafan.cn/images/common/back.gif[/img][/url]1.内置规则是程序员的一种偷懒行为，再没有比直接返回deny，无需交互更简单、更放心的做法了，交互相形起来就不那么让人放心，会一定程度上增加系统响应迟钝的机会。自定义规则除非用户有精力有耐心，一些用户会更喜欢完全信任、完全不信任、内置规则，完全不保护模式，这种无需干预的工作模式。另外一些内置处理做了大量判断和分析，这些处理过程很难用统一的规则模式来描述出来，比如规则一般不包含父进程的关系约束。 第一个explorer.exe进程和用户发起的explorer。exe,两者的父进程是不同的，如果需要对两者区别对待，用规则进行约束就比较困难。还有就是IE发起的进程问题，IE缓冲区溢出时会触发一个进程，同样用户直接使用IE下载，下载完成后直接运行程序也会触发进程，这两种情况完全放开或者完全拒绝都会给用户带来种种不便。内置处理可以通过编程分析的办法来判断某个进程的运行是用户自己手工下载的，还是溢出造成的。当然这种分析有时是费力不讨好。
当然这些意见提过多次了，一部分用规则描述出来了，一部分还没有完全解放，其实内置的规则并不多，其实我也明白这个道理，如果内置的规则多了，意味着需要大量的硬编码，程序维护就会越来越费劲。[/quote]
[b]适当的内置规则是必要的也是无法避免的，[/b]比如难以用规则体现的（规则体系以外）、或者可以直接处理无需用户干涉同时内置处理可以提高软件性能的（简化操作、优化性能、易于实现）等。这个我想[b]大家都支持并理解[/b]的，[b]我的意思是内置了哪些东西，最好有个公示，这样大家心里会比较有底。[/b]当然，内置规则的量这个度要把握好。
[quote]原帖由 [i]中网S3[/i] 于 2008-8-15 14:56 发表 [url=http://bbs.kafan.cn/redirect.php?goto=findpost&pid=4499679&ptid=304986][img]http://bbs.kafan.cn/images/common/back.gif[/img][/url]
2. 函数调用或者系统调用一方面是为了未知动态链接库、未知函数调用进行监控，这类规则只能通过询问框进行添加，采用这种一致的接口方式，是避免底层和上层交互式频繁地改变接口的结构。这样只要按照函数名称、函数描述、参数名称、参数描述等信息填充后，上层的应用不需要做任何修改，对于任何新增的函数和调用拦截，都是进行询问，无需做任何编码的调整。
当然这种调用，用户是否认可是另外一回事，因为他们大多不一定看懂这些询问框是什么意思，对询问框往往无所适从。
规则描述的问题，一般只对于预置规则可行，对于询问框添加的规则，我想大多数用户会更关心规则主体的属性。如果是良民，他们一般是完全信任，如果不是，他们多数会选择卸载而后快。其他情况，他们一般搞不定了。当然我可能犯了主观主义的错误，对用户未必真正了解，低估了初级用户的能力。
也就是说如果需要对规则进行描述的话，这些描述也只能产生一个大概的描述，由用户自己来编辑和完善，按照自己的口味来定制规则描述信息。[/quote]
从用户交互的方面来说，[b]越是直观易懂的交互界面与信息，越能被用户所接受[/b]，以函数调用信息描述程序行为对于一般用户来说，理解会比较有难度。能用更浅显直观的文字描述进行说明当然更好，不行或者说实现有难度的话，[b]在规则里提供一个备注栏用于补充描述规则及程序行为信息，可以在一定程序上改善这个问题[/b]，同时不会对现有软件框架产生影响，对结构上影响也很少，应该说是个较折衷的方案。
[quote]原帖由 [i]中网S3[/i] 于 2008-8-15 15:08 发表 [url=http://bbs.kafan.cn/redirect.php?goto=findpost&pid=4499806&ptid=304986][img]http://bbs.kafan.cn/images/common/back.gif[/img][/url]
3.Explorer.exe进程的问题的确比较棘手，因为这个进程可以轻松被杀死，也可以手工创建，大多数用户安装程序、文件管理都是在这个进程里完成，处理不好，会带来很多麻烦。因为S3拦截的调用不只是AD、FD、ND和RD，还包括窗口消息，任务栏、状态区、桌面的交互涉及了大量和Explorer进程的窗口消息，这些窗口消息有时是发给另外一个进程的。前一阵子桌面比较卡，反应迟缓，没有办法只好把Explorer 相关的一小部分窗口消息给预先放走了。不过Exploer被排斥在系统保护程序之外，不是S3内置的系统保护程序，如果只是对其ND、RD和FD进行限制的话，手工定义的规则应该能够生效。
判断是否是第一个Explorer可以通过父进程来判断，这一点没有问题，但问题是Explorer.exe进程的多数行为主要是用户触发的，对这个进程预置规则，限制太多会带来一些不便。不过可以考虑将它的预置规则拿出来。[/quote]
[b]Explorer.exe进程的问题确实比较难办，官人先把它的预置规则拿出来大家集思广益一下吧[/b]。
[quote]原帖由 [i]中网S3[/i] 于 2008-8-15 15:20 发表 [url=http://bbs.kafan.cn/redirect.php?goto=findpost&pid=4499947&ptid=304986][img]http://bbs.kafan.cn/images/common/back.gif[/img][/url]
另外还有一点需要澄清的是，除了底层驱动做了规则判断之外，应用层出于减少询问框，也做了大量的规则，最简单的例子就是判断是否是系统保护文件、是否有合法的数字签名，这些情况可能会在某种设置情况下被予以放行，而不再询问，所以对于没有询问放行的情况，未必都是驱动里面内置了大量的规则，驱动里面的确没有预置多少规则。
在“帮用户拿主意”和“让用户拿主意”之间，我已经徘徊了好久。[/quote]
对于这个问题，我的看法是，S3是一款传统型的或者说是经典型的HIPS，所有的防护基本上都建立在规则之上，[b]使用这类HIPS的用户，玩的是可操控性[/b]，否则他会更愿意选择智能型的HIPS了。因此我觉得还是少帮用户拿主意好些，而是[b]考虑如何强化规则架构的弹性和可控性。让规则体系能够轻松面对、适应、处理各种复杂的情况。这才是更重要的[/b]。
[quote]原帖由 [i]中网S3[/i] 于 2008-8-15 15:25 发表 [url=http://bbs.kafan.cn/redirect.php?goto=findpost&pid=4499984&ptid=304986][img]http://bbs.kafan.cn/images/common/back.gif[/img][/url]
4.第4条涉及重大改进，我尚不清楚权限继承和分组到底是什么样子，需要多大的变化，有的东西说起来容易，实现起来就比较难，尤其是我们人手紧张的情况下，架构太复杂，我也很难驾驭。关于这一条我可以私下和lz沟通一下。我们休息了一周，下周一正式上班。[/quote]
关于[b]继承[/b]，实现起来确实比较困难，[b]有程序与子程序间的继承（被调用程序是否具有父进程的权限）、有程序与其创建对象间的继承（被创建的程序文件，运行时是否具有其创建者相同的权限）、另外还有组权限继承、继承权限叠加、继承关系是否无限继承等等问题[/b]。我一个人也说不好，拿出来大家讨论吧。
关于[b]分组[/b]，有三种情况：
[b]一、第一种情况——程序组，是组仅仅是一堆程序的集合[/b]（这堆程序可能相关也可能不相关，但赋予的权限基本一样），放在组里的程序具有相同的权限，通过给组设置权限，即使得组中各程序具有一样的权限。[b]起到简化设置的作用[/b]。如：
[code]原来的规则：
程序A：权限1、权限2、权限3
程序B：权限1、权限2、权限3
程序C：权限1、权限2、权限3
程序D：权限1、权限2、权限3
使用组后（规则数减少为原来1/4）：
（定义组A：程序A、程序B、程序C）
组A：权限1、权限2、权限3[/code]
对于这种用途的分组，需要考虑的就是，几个程序虽然有一些相同的权限，但还有些不同的权限。如：
[code]程序A、程序C有单独的权限：权限4、权限5
程序A：权限1、权限2、权限3、权限4
程序B：权限1、权限2、权限3
程序C：权限1、权限2、权限3、权限5
程序D：权限1、权限2、权限3
那这时使用组后的规则应该为：
（定义程序组G：程序A、程序B、程序C）
程序组G：权限1、权限2、权限3
程序A：权限4
程序C：权限5[/code]
这时就[b]需要考虑程序规则与组规则的优先级问题[/b]。
[b]二、第二种情况——规则组或者说权限组，是组是一堆规则或者权限的集合。类型于第一种情况，也是为了简化设置[/b]。如：
[code]
程序A：权限1规则、权限2规则、权限3规则
程序B：权限1规则、权限2规则、权限3规则
程序C：权限1规则、权限2规则、权限3规则
程序D：权限1规则、权限2规则、权限3规则
使用规则组后（规则数减少为原来1/3）：
（定义规则组R：权限1规则、权限2规则、权限3规则）
程序A：规则组R
程序B：规则组R
程序C：规则组R
程序D：规则组R[/code]
如果同时使用程序组和规则组：
[code]程序A：权限1规则、权限2规则、权限3规则、权限4规则
程序B：权限1规则、权限2规则、权限3规则
程序C：权限1规则、权限2规则、权限3规则、权限5规则
程序D：权限1规则、权限2规则、权限3规则
那这时使用组后的规则应该为（规则数减少为原来3/14）：
（定义程序组G：程序A、程序B、程序C）
（定义规则组R：权限1规则、权限2规则、权限3规则）
程序组G：规则组R
程序A：权限4规则
程序C：权限5规则[/code]
[b]三、第三种情况，是在第一、二种情况的形式上，引入了继承的概念[/b]（程序继承所属组的权限，并允许有自己的权限）。如果引入继承概念，从实现效果上看起来似乎和上面并无不同，但从开发设计角度（逻辑上），是[b]要先在实现权限继承的基础上来做的。因为在权限继承里，组继承只是继承关系中的一种[/b]。
[quote]原帖由 [i]中网S3[/i] 于 2008-8-15 15:42 发表 [url=http://bbs.kafan.cn/redirect.php?goto=findpost&pid=4500151&ptid=304986][img]http://bbs.kafan.cn/images/common/back.gif[/img][/url]
5.安装状态可以研究
安装问题已经被论坛网友提过多次，主要是弹框太多的问题，S3的弹框类型很多，涉及进程互操作、窗口消息、系统调用、关机操作、keylogger、窗口钩子.安装驱动等等，很多类别不能简单地划归到RD、AD、FD的范畴，即使XD（RD、ND、FD）不弹了，还有可能其他询问框，而且数目可能还比较多，因为安装产生的文件多为新文件，还没有来得及为其准备规则。比如函数调用，也很讨厌。出于这种考虑，才提出和父进程完全信任、子进程也被信任的安装状态。当然这也没有做好，现在发现应用层拦截还是会弹框的，可能还需要修改。
另外一个问题是一些安装程序在安装过程中会先释放出一大堆临时文件比如_setup.tmp等等，然后再运行_setup.tmp文件，信任继承的安装状态可以解决这类程序的安装。当然一些共享软件比如暴风影音、QQ、快车等等往往会在安装过程中会附加安装第三方的软件比如google工具条、google拼音，我想与其在弹框过程中拦截这些附加程序的安装，还不如在这些程序的安装选项对话框，勾掉这类插件的安装。
询问框比较适合对某些可疑的程序调试运行，通过询问框来了解这类程序都干了些什么，特别是那些测试hips性能的程序以及病毒样本。如果对所有的安装的程序都调试和询问的话（就是说询问框比较多），可能浪费用户很多时间和光阴，大多数用户还是比较喜欢无人值守的安装，不过也不喜欢偷偷摸摸安装一大堆流氓软件。[/quote]
程序安装问题确实很复杂，如果要完全解决，需要建立在继承关系逻辑的完整实现基础之上。因此，[b]很多人把程序安装问题与权限继承搅在一起说，我觉得不妥。要么先理清继承问题，再谈程序安装问题；要么撇开继承，先只考虑解决在不影响安全性的前提下减少程序安装中的弹框问题。[/b]而我之前的建议，是基于第二种考虑方式。这里要说明的是，是减少弹框，而不是避免弹框。[b]FD、RD弹框如果能减少很多，程序安装过程中的弹框当然也就减少不少，起码用户体验上有改善。何乐而不为？[/b]为何非要想把所有的弹框都考虑进来？我觉得没有必要。在没有清晰继承概念和实现的情况下，完全没有必要。我们的目的只有一个：在不损失安全性的前提下减少弹框，只要在不损失安全性的前提下弹框减少了，我们的目的就达到了。
最后，在这里感谢官人与我们的坦诚交流与辛勤付出。：）
回复 17楼 Devy 的帖子
好 怎么官人又不见了？[:11:] 看的devy的回帖，有些汗颜。1.内置的规则，将有选择逐步开放出来，保证用户的知情权。
2.用户交互模式下描述信息，将会按照devy意见，提高可读性
3.Explorer.exe进程的问题，可以另行发帖和大家一起探讨
4.界面规则的问题是一个最棘手的问题，有关权限分组的问题，提的很好，但是难度不小，规则指派，规则分组，的确可以很大程度上方便用户定制和管理规则，同时也可以大大减少规则的冗余。这个修改涉及到界面、数据库、和规则文件，我们现在只实现了一个只有文件组、注册表项的客体组，和受保护程序、信任程序、不信任程序的主体组。而devy提到的权限规则组更具有代表意义，根据一组和一个主体对象指派一组权限规则，这样媒体播放类、浏览辅助类、文件下载、IM类、系统安全类这样就可以轻松搞定了，尽管每一类下面可能有上百条的规则。
也许我们在当初规划之初，就应该想到这一点，一步到位。说实在，分组的问题，让我头大。
[[i] 本帖最后由 中网S3 于 2008-8-18 10:02 编辑 [/i]]
页:
[1]
2