Strategies for signing sections of a text file to prevent tampering

Question

I'm looking for suggestions from the community on the best way to approach this problem of securing a text file while still making it fairly shareable:

1. 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

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

3. 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

4. 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

of course I might be thinking of this the whole wrong way around.

#---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

Answer 1

I don't think I understand I understand the problem. To help you think and explain more clearly about what you are trying to achieve, I suggest you decide: What are the legitimate actions that you want to allow? Also, what are some examples of illegitimate actions that you don't want to allow? Who do you want to be able to modify the non-locked sections of the file? What are you trying to protect against?

My first suggestion would be: break the file up into multiple files, and make some modifiable and some not.

However I don't really understand what your goal is. Anyone can make a local copy of the file and modify any part of it they want. Nothing you do can prevent that. I don't see how signatures help, because anyone can just ignore the fact that the signatures are invalid and continue to use the file (if necessary, they can modify the code that checks the signatures to ignore the invalid signature). So it sounds on first impression like you may be trying to solve an unsolvable problem -- something akin to making water not wet.

If you are talking about preventing modification to the version of the file stored in git, why are you giving people you don't trust write access to your git repository? Seems like you should just avoid doing that.

Edit 9/29: In your comments, you clarified the problem setting. Now I can give a better answer:

Split the file up into two parts or two files, one intended to be changed and one not intended to be changed. Label each part clearly, and indicate which part/file should be changed and which should not.

And, realize that no technical measure can force them to include the parts-you-want-not-to-change without changing them. This is not something you can solve through technical means. Instead, your goal should be to elucidate your intentions about which parts they aren't supposed to be changed. Then, you will have to rely upon social means to keep people from doing what you don't want them to do (i.e., you will be relying upon other people's good will, or upon the threat of negative consequences if they deviate from your recommendations).