Strategie per la firma di sezioni di un file di testo per evitare manomissioni

Question

Strategie per la firma di sezioni di un file di testo per evitare manomissioni

#1 da (3 voti)

4

Sto cercando suggerimenti dalla community sul modo migliore per affrontare questo problema di protezione di un file di testo pur continuando a renderlo abbastanza condivisibile:

Ho una raccolta di ricette per chef in git, che definiscono laboratori, ad es. una configurazione di jenkins CI, che le persone saranno in grado di utilizzare e personalizzare a proprio uso
Tuttavia, posso prevedere circostanze in cui qualcuno potrebbe voler aggiungere alcune sezioni immutabili del libro di cucina, ad es. impostazioni del firewall
Quale strategia avrebbe senso bloccare alcune sezioni del file per convalidare che non è stato modificato, consentendo al tempo stesso modifiche arbitrarie al di fuori di
Idealmente risolverebbe anche la possibilità di offuscare le sezioni se necessario

Aggiungerei la mia DSL nel codice - con un checksum per ogni blocco protetto - pre-elaborarlo per scartarlo e convalidarlo prima di passarlo allo chef?

es. Il mio primo tentativo in un formato - continua a non risolvere il problema delle persone che eliminano tutte le sezioni firmate - a meno che non sia necessario firmare ogni file

naturalmente potrei pensare a questo in modo sbagliato.

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

code-signing

posta velniukas 28.07.2012 - 13:13

fonte

1 risposta

Leggi altre domande sui tag code-signing

È possibile modificare una CA senza dover riemettere tutti i certificati derivati? Necessità di ambito nel flusso di credenziali del client OAuth

score 3 · Accepted Answer

Non credo di capire capisco il problema. Per aiutarti a pensare e spiegare più chiaramente cosa stai cercando di ottenere, ti suggerisco di decidere: quali sono le azioni legittime che vuoi consentire? Inoltre, quali sono alcuni esempi di azioni illegittime che non vuoi permettere? Chi vuoi essere in grado di modificare le sezioni non bloccate del file? Cosa stai cercando di proteggere contro?

Il mio primo suggerimento sarebbe: rompere il file in più file, e renderne alcuni modificabili e altri no.

Tuttavia, non capisco veramente quale sia il tuo obiettivo. Chiunque può fare una copia locale del file e modificare qualsiasi parte di esso che vogliono. Niente di ciò che fai può impedirlo. Non vedo come le firme possano aiutare, perché chiunque può semplicemente ignorare il fatto che le firme non sono valide e continuare a utilizzare il file (se necessario, possono modificare il codice che controlla le firme per ignorare la firma non valida). Alla prima impressione sembra quindi che tu stia cercando di risolvere un problema irrisolvibile, qualcosa di simile a rendere l'acqua non bagnata.

Se stai parlando di impedire modifiche alla versione del file memorizzato in git, perché stai dando alle persone che non ti fidi dell'accesso in scrittura al tuo repository git? Sembra che dovresti semplicemente evitare di farlo.

Modifica 9/29: nei tuoi commenti hai chiarito l'impostazione del problema. Ora posso dare una risposta migliore:

Suddividi il file in due parti o due file, uno destinato a essere modificato e uno non destinato a essere modificato. Etichetta chiaramente ogni parte e indica quale parte / file deve essere cambiata e quale non dovrebbe.

E rendersi conto che nessuna misura tecnica può costringerli a includere le parti che non si desidera modificare senza modificarle. Questo non è qualcosa che puoi risolvere con mezzi tecnici. Invece, il tuo obiettivo dovrebbe essere quello di chiarire le tue intenzioni su quali parti non dovrebbero essere cambiate. Quindi, dovrai fare affidamento su mezzi sociali per impedire alle persone di fare ciò che non vuoi che facciano (cioè, farai affidamento sulla buona volontà altrui, o sulla minaccia di conseguenze negative se si allontanano dai tuoi consigli ).