软件配置项约束提取

13《不要将错误配置归咎于用户》

[x]SPEX用于从软件源代码自动推断配置需求（称为约束），然后使用推断出的约束：（1）暴露错误配置漏洞（即，系统对配置错误的不良反应，如崩溃、挂起、无声故障）；以及（2）检测某些类型的易出错配置设计和处理。

一个配置参数的约束规定了它的数据类型、格式、取值范围、与其他参数的依赖性和关联性等，

方法：通过分析配置参数的读取和使用方式，从源代码中自动推断配置约束。1）通过注入违反约束的错误来加固系统，以暴露错误配置的漏洞；（2）检测某些类型的容易出错的配置设计和处理，以使其更加方便用户。

 

1. 数据类型有两类：基本类型（整数、字符、布尔值、浮点数、字符串等）和语义类型（"字符串 "参数可能指的是一个文件路径或一个IP地址）。

2. 值范围。配置参数可以通过一些可接受的有效值范围来进一步约束，比如最小值和最大值，或者像枚举式那样的可接受值列表。

3. 控制依赖性。多个配置参数可能有依赖性。（P,V,⋄）→Q，这意味着参数Q的使用依赖于参数P的设置，条件是P⋄V，其中⋄∈{<，>，=，!=，≥，≤}，而V是一个常值。

4. 值的关系。除了两个参数之间的控制依存关系外，它们的值的关系也可能施加约束。Ӏft_max_word_lenӀ should be greater than Ӏft_min_word_lenӀ.

推断约束条件：SPEX首先需要识别源代码中的配置变量。然后，它跟踪与配置参数相对应的每个程序变量的数据流，并记录在数据流路径上发现的任何约束条件。

• SPEX对源代码进行了两次扫描。在第一遍中，它推断每个参数的数据流路径，并寻找每个参数的数据类型和数据范围约束。

• 为了进一步推断涉及多个参数的约束（即控制依赖和值关系），SPEX再次扫描代码，但这次只扫描包含每个参数的数据流的程序片。

             

1. 将 参数映射到变量 ：三个接口之一将配置参数映射到程序变量中：结构（struct config_int ConfigureNamesInt[]）、比较（strcasecmp）和容器（所有的配置参数存储在一个中央容器中，并使用普通的getter函数来检索值）。
2. 类型推断： SPEX从源代码中的类型信息推断出每个参数的基本类型。 SPEX通过沿着参数的整个数据流路径搜索以下模式来推断语义类型约束：
   1. 参数被传递给已知的函数调用（例如，系统和库调用）或已知的数据结构；
   2. 参数与已知函数调用的返回值（例如，时间系统调用的返回值）相比较，或者被分配给已知的函数调用。
3. 数据范围推断： SPEX推断两种类型的范围：数值型和枚举型。
   1. 对于数字比较，SPEX将常数视为数据范围的阈值。
   2. 如果参数被用于开关语句或 "if...else if...else "逻辑中，则推断出枚举范围。 图3(d)显示了OpenLDAP的一个范围推断的例子，其中 "index intlen "的范围被分为(-∞,4)，[4,255]，和(255,+∞)。(-∞,4)和(255,+∞)都是无效的，因为参数在这些范围内被重置。
4. 控制依赖性推断： 从一个参数Q的使用语句开始，以自下而上的方式寻找支配这些语句的条件分支。如果条件涉及的变量是另一个参数P的数据流的一部分，SPEX就会以(P,V,⋄)→Q的形式记录P和Q之间的控制依赖关系。
5. 值关系推断： 如果来自不同参数的数据流路径的两个变量相互比较，SPEX就会以P⋄Q的形式推断出这两个参数的价值关系。

20《PracExtractor：从手册中提取配置良好实践，以检测服务器错误配置》

     错误来源 ：通常，手册不仅描述了配置参数的含义，还描述了关于如何配置某些参数的良好实践建议。不幸的是，手册通常也有大量页面，人类阅读和理解这些页面非常耗时。

     发现： 60%的研究建议描述了具体和可检查的规范，而不仅仅是一般指导。此外，几乎所有（97%）此类规范都没有在系统的源代码中进行检查，其中61%不等同于默认设置。

      方法： PracExtractor，该工具使用自然语言处理（NLP）技术从软件手册中自动提取配置建议，将其转换为规范，然后使用生成的规范检测系统管理员配置设置中的违规行为。

              [x]基于关键字的过滤（例如“推荐”、“建议”）、基于语法模式的过滤（推荐还包含一个设置短语，一个描述推荐设置的名词/动词短语。）

              [x]生成四种类型的规范，包括值、相关性、用法和属性，

    观察：

1. 60%的研究良好实践建议是具体的（ 建议将其设置为大于2000 ），而不仅仅是一般性建议（ 建议将其设置为较大值 ）。
2.  97%手册中推荐的特定良好实践未在源代码中检查。
3. 61%的具体良好做法建议不等同于默认设置。
4. 六份研究手册的组织结构相似。六本手册采用HTML或XML格式，其中的参数以类似的结构描述：＜key＞：＜value＞

     挑战：

（1） 由于手册以纯文本编写，并且有大量与建议无关的文本，如何有效地过滤噪音并仅提取建议？

（2） 提取建议之后，如何将其转换为可用于自动检查违规行为的正式规范？

     解决

1. 将手动文本分成句子，并通过两个过滤步骤提取推荐句子：基于关键词的过滤（粗粒度）和基于句法模式的过滤（细粒度）。
2. 首先识别推荐语句中的语义实体（例如，参数名称和值），然后通过将它们与语义模式匹配，将其转换为正式规范。

      *实现

1. 将软件手册预处理并解析为 参数名称、元信息（ 类型和默认值 ）和自由文本描述。
2. 过滤包含建议语句：
   • 关键字：  例如“recommend”、“suggest”  ，将研究的 261 个推荐句子分解为单个单词和二元组（两个连续单词），并将它们用作候选关键字 T。PracExtractor 使用逆文档频率（IDF）对候选关键词进行排名。
   • 基于 句法模式的过滤：经过关键词过滤后，剩下的句子中有 7.3% 是推荐的。 推荐还包含一个设置短语，一个描述推荐什么设置的名词/动词短语。这样的设定短语和关键词之间，存在一定的句法关系（模式），这在非推荐句中是不存在的。 ( amod——从名词到形容词修饰语的链接； nsubj – 动词/名词和介词短语之间的关系； attr – 动词/形容词和补语等之间的关系。)

 

• 规范生成-- 最简单的是将设置短语与预定义的正则表达式匹配并相应地转换它们

• • • 识别参数名称： 识别句子与哪个参数相关联。 参数X相关的段落p中的推荐句子s，有四种可能的情况 1）s中只提到X。  2) s中提到了另一个参数Y。 3) s 中没有提到参数。 4）p中没有提到参数，PracExtractor判断句子是针对X的

    • 识别设置实体： 根据相关参数的类型从设置短语中识别设置实体（例如值和格式）， 可以识别的七种 ：<parameter> 用于设置短语描述当前参数相对于另一个参数的情况，例如“设置A 大于B”。 <format>，PracExtractor 根据单词匹配识别参数的常见格式（例如“电子邮件地址”、“绝对路径”）。 所有其他单词/短语都被标识为<string>。

 生成规范： 将设置短语与预定义的语义模式匹配来生成可检查的正式规范。

 

• • 检查否定： 检测推荐句子中的否定，并在必要时否定规范。 PracExtractor 在句子中查找直接否定词，例如“not”， “none”和“never”，此外 检测间接否定词和短语，例如“避免”、“谨慎”、“很少”和“很少”等，以识别否定。
• 配置中的 违规检测： PracExtractor 根据提取的规范检查解析的参数值，并在检测到违规时生成警告消息。                        

总结： PracExtractor 检测到的大多数违规行为都无法被以前的工作检测到。以前的工作

[ Static extraction of pro gram configuration options , 

Early detec tion of configuration errors to reduce failure damage , 

Do not blame users for misconfigurations ] 

主要使用源代码中的配置检查/使用逻辑来检测错误配置。但是，大多数建议没有在源代码中检查，因此这些作品无法检测到对它们的违反。

18《你真的知道如何配置你的软件吗？源代码中的配置约束可能会有所帮助》

错误来源

     用户很难在千页文档中找到这些信息，一些开发人员可能无法维护格式良好的文档，如果软件文档没有及时更新，文档中记录的约束可能完全错误，从而增加了错误配置诊断的难度。

发现：

     手工研究了五种广泛使用的开源软件，发现不同类型的软件中配置约束的形式不同，这并不总是在简单的if语句检查情况下。   由于糟糕的配置设计或开发人员的疏忽，可能根本没有关于配置约束的检查机制。

    三类发现：

1. 一般统计数据包括可从源代码中提取的配置约束的比例、具有不同基本类型的配置选项的配置约束比例，以及源代码中配置变量的一般存在形式。
2. 特定类型约束的一般特征主要集中在各种形式的配置约束、枚举约束的集群定义和声明以及可用于约束的语义信息提取。
3. 提取配置约束的障碍主要在于结构配置选项和资源相关配置选项。

方法：

1. 首先，对于使用统一映射结构的配置选项，我们通过统计分析以及一些语义信息提取了这些配置选项的数值范围。
2. 然后，考虑到用于枚举的集群代码段，使用一些文本分析来提取枚举配置选项的值空间。
3. 最后，利用函数参数标识符的一些语义信息，我们改进了数据流分析，以获得配置选项的语义。

实现：

1. 首先，通过搜索官方文档和手册，为每个研究过的软件包构建了配置选项的集合。
2. 建立了配置文件中的配置选项与目标软件源代码中的程序变量之间的映射关系。（假设：配置变量通常直接使用，而无需复杂的分配和传播）
3. 分类 ：

   值范围	数值配置选项应满足的值范围。
   枚举	枚举配置选项应满足的值空间。
   语义	配置选项的语义含义。
   值控制  多值关系	一个配置选项的使用依赖于另一个配置选项。 两个或多个不同的配置选项的值关系应该满足。

   1. 复杂类型，它涵盖了所有结构配置选项和软件特定的封装配置选    
   2. 配置类型分为简单类型和复杂类型，其中简单类型包括数字、字符串和枚举
4. 1. 一维约束由语义、值范围和枚举组成，
   2. 多维约束包括值控制和多值关系。
      1. 主要考虑五种语义含义，即文件、目录、端口、IP和URL。
      2. 只有数字配置选项具有值范围约束。
      3. 枚举指的是配置选项可以分配给的值空间。
      4. 值控制关系中，配置选项是否生效取决于另一配置选项的值
      5. 多值关系确定了两个或多个不同配置选项的值应满足的条件。

人工分析--整个研究花费了将近每个人十个月。

发现：

1. 基于程序分析，我们平均能够提取64%的各种代码形式的配置约束，而当前的研究仅涵盖27%，主要是在if语句情况下。
2. 数字配置选项检查得更好，而字符串类型的配置选项检查总是很差。
3. 不同软件包中变量的形式可能不同，但它们主要是全局变量或全局结构的成员。
4. 配置约束有多种形式，而不是if条件语句。（大多数数值约束是在结构中进行配置选项和相关配置变量之间的映射；我们相应地将它们称为映射约束）
5. 不同的软件包中使用了各种形式的枚举约束，而不仅仅限于切换case语句的情况
6. 语义信息隐含在使用配置选项的函数的参数中。（使用数据流信息追溯到已知的库函数，）dymap_init（path,var_shlib_directory)
7. 由于不同类型软件中的各种结构形式，没有成熟的方法来处理结构配置选项和配置选项的影响范围。
8. 大多数研究的软件包没有足够的资源相关配置选项检查机制。

 

21《ConfInLog: 利用软件日志来推断配置约束条件》

方法：使用总结的模式从源代码中选择与配置相关的日志消息，然后根据总结的自然语言模式从日志消息中推断出约束条件。

1. 为了获取软件系统的日志记录，我们选择注入配置错误，生成与配置选项相关的日志记录 
2. 日志分析:   如果一条日志记录满足以下条件之一，我们就认为它与被测选项有关：
   1. 日志记录包含被测选项的名称；
   2. 它包含选项中所有与普通分隔符相连的词；
   3. 它包含在配置文件中找到该选项的位置信息（行号）。
   4. 如果日志记录与被测选项有关，并且为修复配置错误提供了指导，我们认为它包含了配置约束。 

现有的方法： 两个主要步骤。首先，他们将配置选项映射到程序变量上，然后通过静态程序分析跟踪变量的使用情况。其次，当变量出现在一些预定的代码模式中时，他们会推断出约束条件。

现有方法的困难：一方面，C/C++等编程语言中的指针机制可能会给静态程序分析带来很大的障碍，特别是对于大规模的软件系统，限制了分析的范围和准确性。另一方面，这些预定义模式的质量高度依赖于个人经验。因此，他们可能会遗漏那些难以被静态分析跟踪的约束条件，或者遗漏那些不属于任何模式的约束。

发现：

1. 57.0%的配置选项在日志记录中有约束描述。
2. 12.5%的日志信息没有明确呈现在日志语句中，而是以各种样式存在，隐含数据流到日志语句中。
3. 77.6%的配置选项的日志信息并不包含选项名称。
4. 51.8%的配置相关的日志信息可以通过直接匹配日志信息中的选项名称，或找到相关的函数或变量来识别，这意味着识别配置相关的日志信息的可行性。
5. 剩下的48.2%的配置选项，根据发现4无法识别相关的日志信息，它们都是数字或布尔类型，并通过一般的逻辑与特定结构中的预定义信息来处理。

实现：首先，ConfInLog收集目标软件中的日志信息并选择与配置相关的信息。然后，根据总结的NLP模式，ConfInLog从选定的日志信息中推断出配置约束。

1. 日志信息选择--> ConfInLog将代码中所有的字符串常量都视为候选日志信息。 一条日志信息可能由几个字符串常量、变量和宏拼接而成，ConfInLog首先将变量转换为特殊标签"_VARIABLE_"，并替换常量和宏，然后将它们连接起来。

             

•     识别配置相关日志信息的直接方法是检查日志信息中是否包含选项名称信息。
•     寻找与日志信息隐含相关的配置选项.   主要关注与配置选项相关的函数和变量。
  1. 收集配置选项的相关代码元素
     • 如果配置选项的名称字符串在为配置-变量映射定义的结构接口中使用，ConfInLog就会使用最小公因式算法来收集配置变量和配置函数。
     • 如果配置选项被映射到容器接口的变量上（基于getter api读取配置值），ConfInLog会收集返回变量作为配置变量。
     • 对于比较接口，如果一个配置选项在类似strcmp的条件下被使用，并且后继块少于3行，ConfInLog将收集后继块中assign语句的左边变量作为配置变量。
  2. 日志信息的后向切分
     • 从包含日志消息的语句开始切分。一旦在切片中得到一个变量或函数，ConfInLog就会检查它是否是一个配置变量或函数，如果是的话，就认为该日志消息与这个配置选项有关.
  3. 互补性相似性比较
     • 某些情况下，ConfInLog没有收集到配置变量,或没有匹配的配置函数， ConfInLog就会应用一种近似的方法，根据配置选项和分片中的变量之间的相似性来识别与配置相关的日志信息。   将配置变量命名为与选项相似的名称
• 约束推断： 获得了与配置相关的日志信息之后， 用了一种基于NLP（自然语言处理）模式的方法来表示配置约束的描述。 使用POS（Part-Of-Speech）标签序列来表示这些描述，xxxxx