签署厨师食谱文件的部分以防止篡改的策略(Strategies for signing sections of a chef recipe file to prevent tampering)

我正在寻找社区关于解决此问题的最佳方法的建议:

我在git中有一系列厨师食谱,定义了实验室,例如jenkins CI设置,人们可以根据自己的需要进行分类和定制

但是,我可以预见有人可能想要添加食谱的某些不可变部分,例如防火墙设置

锁定文件的某些部分以验证它是否未被更改,同时允许在该范围之外进行任意更改,哪种策略是有意义的

理想情况下,它还可以解决在需要时对这些部分进行模糊处理的能力

我是否会将自己的DSL添加到代码中 - 每个受保护块的校验和 - 在将其传递给厨师之前预先处理它以进行解包和验证?

例如,我首次尝试某种格式 - 仍然无法解决人们删除所有已签名部分的问题 - 除非每个文件都必须签名

#---SIGNED-FILE SHA-256 507e74380188c07bad2fa66acb8cbbeeb63f84fcee5fd639499575654239cd49 # # Cookbook Name:: jenkins # Recipe:: default # # https://wiki.jenkins-ci.org/display/JENKINS/Installing+Jenkins+on+Ubuntu # This is super-simple, compared to the other Chef cookbook I found # for Jenkins (https://github.com/fnichol/chef-jenkins). # # This doesn't include Chef libraries for adding Jenkin's jobs via # the command line, but it does get Jenkins up and running. include_recipe "apt" include_recipe "java" #---SIGNED-SECTION-START SHA-256 e4d3d02f14ee2a6d815a91307c610c3e182979ce8fca92cef05e53ea9c90f5c7 apt_repository "jenkins" do uri "http://pkg.jenkins-ci.org/debian" key "http://pkg.jenkins-ci.org/debian/jenkins-ci.org.key" components ["binary/"] action :add end #---SIGNED-SECTION-END #---OBFUSCATED-SECTION-START SHA-256 5f536f2137dc7e2c5817de861d1329ead72b1e9d2dbb9dbe181ec7bc274dddeb YXB0X3JlcG9zaXRvcnkgImplbmtpbnMiIGRvCiAgdXJpICJodHRwOi8vcGtnLmplbmtpbnMtY2kub3JnL2RlYmlhbiIKICBrZXkgImh0dHA6Ly9wa2cuamVua2lucy1jaS5vcmcvZGViaWFuL2plbmtpbnMtY2kub3JnLmtleSIKICBjb21wb25lbnRzIFsiYmluYXJ5LyJdCiAgYWN0aW9uIDphZGQKZW5k #---OBFUSCATED-SECTION-END package "jenkins" service "jenkins" do supports [:stop, :start, :restart] action [:start, :enable] end

I'm looking for suggestions from the community on the best way to approach this problem:

I have a collection of chef recipes in git, defining labs e.g. a jenkins CI setup, which people will be able to fork and tailor to their own use

However, I can forsee circumstances when someone may want to add certain immutable sections of the cookbook, e.g. firewall settings

What strategy would make sense to lock certain sections of the file to validate that it hasn't been changed, while allowing arbitrary changes outside that

Ideally it would also solve the ability to obfuscate the sections if needed

Would I be adding my own DSL into the code - with a checksum for each protected block - pre-process it to unwrap and validate it before passing it to chef?

e.g. My first attempt at a format - still doesn't solve the problem of people just deleting all the signed sections - unless every file has to be signed

#---SIGNED-FILE SHA-256 507e74380188c07bad2fa66acb8cbbeeb63f84fcee5fd639499575654239cd49 # # Cookbook Name:: jenkins # Recipe:: default # # https://wiki.jenkins-ci.org/display/JENKINS/Installing+Jenkins+on+Ubuntu # This is super-simple, compared to the other Chef cookbook I found # for Jenkins (https://github.com/fnichol/chef-jenkins). # # This doesn't include Chef libraries for adding Jenkin's jobs via # the command line, but it does get Jenkins up and running. include_recipe "apt" include_recipe "java" #---SIGNED-SECTION-START SHA-256 e4d3d02f14ee2a6d815a91307c610c3e182979ce8fca92cef05e53ea9c90f5c7 apt_repository "jenkins" do uri "http://pkg.jenkins-ci.org/debian" key "http://pkg.jenkins-ci.org/debian/jenkins-ci.org.key" components ["binary/"] action :add end #---SIGNED-SECTION-END #---OBFUSCATED-SECTION-START SHA-256 5f536f2137dc7e2c5817de861d1329ead72b1e9d2dbb9dbe181ec7bc274dddeb YXB0X3JlcG9zaXRvcnkgImplbmtpbnMiIGRvCiAgdXJpICJodHRwOi8vcGtnLmplbmtpbnMtY2kub3JnL2RlYmlhbiIKICBrZXkgImh0dHA6Ly9wa2cuamVua2lucy1jaS5vcmcvZGViaWFuL2plbmtpbnMtY2kub3JnLmtleSIKICBjb21wb25lbnRzIFsiYmluYXJ5LyJdCiAgYWN0aW9uIDphZGQKZW5k #---OBFUSCATED-SECTION-END package "jenkins" service "jenkins" do supports [:stop, :start, :restart] action [:start, :enable] end

最满意答案

如何设计文件以带符号的部分开头,描述将在整个文件中找到的已签名实体。 然后,您的解析代码需要检查每个实体是否如所描述的那样存在且尚未删除。

要防止重放攻击,您需要在每个签名中包含时间戳,并在每次更改任何已签名的部分时重新计算整个文件中的签名。 因此,文件仅在以下情况下有效:

“标题”中描述的签名实体存在于文件中。

每个签名都验证并包含相同的时间戳。

可选 :签名时间戳匹配(在可接受的增量内)文件时间戳?

剩下的风险是有人用以前的版本替换整个文件(即有效删除他们不喜欢的新部分)。 我不知道你怎么能防范它,除非通过检查上面建议的文件时间戳。

NB。 我的答案假设您在创建和解析文件时可以实现的目标。 我可能误解了你的环境的限制(我不熟悉git),如果是这样的话请不要理我!

How about a design whereby the file begins with a signed section, describing the signed entities that will be found throughout the file. Your parsing code would then need to check that each entity is present as described and hasn't been deleted.

To prevent replay attacks, you would need to include a time stamp into each signature, and recompute the signatures across the entire file each time you make a change to any of the signed sections. Therefore, a file is only valid if:

The signed entities described in the "header" are present in the file.

Each signature verifies and contains an identical time stamp.

Optional: The signature time stamp matches (within an acceptable delta) the file time stamp?

The remaining risk is that someone replaces the entire file with a previous revision (i.e. to effectively delete a new section they don't like). I'm not sure how you can defend against that, except perhaps by examining the file time stamp as suggested above.

NB. My answer makes assumptions about what you can achieve when creating and parsing the file. I've possibly misunderstood the constraints of your environment (I'm not familiar with git), if so please disregard me!

更多推荐