Pracuję nad projektem, w którym zdalnie wdrażamy oprogramowanie za pomocą zarządzania konfiguracją, którego część dostarcza skrypty PowerShell do serwerów Windows, które są następnie wykonywane w celu wykonania części naszej instalacji i/lub konfiguracji.Zarejestruj skrypt PowerShell na platformie innej niż Windows?
Bieżąca metoda wdrażania zapisuje skrypty na dysku, ale nie zamyka uchwytu pliku. Zrobiono to, aby skrypt był bardziej "bezpieczny", uniemożliwiając innym procesom manipulowanie plikiem przed jego wykonaniem. Aby uruchomić skrypt, PowerShell musi go odczytać ze standardowego wejścia, ponieważ nie uruchamia skryptu, jeśli nie może uzyskać wyłącznego dostępu. Inwokacja wygląda mniej więcej tak:
powershell.exe -Command - < C:\temp\some_name.ps1
Ma to wiele wad, przede wszystkim, że nie mogę przekazać parametrów do skryptu. Ponadto czytanie dużych skryptów ze standardowego wejścia staje się fajne ze złymi znakami, zwrotami liniowymi itp.
Chciałbym wywołać skrypty w bardziej tradycyjnej metodzie, np.
powershell.exe -File C:\temp\some_name.ps1 -Param value ...
ale również w duchu upewniając się, że nic nie może modyfikować skryptu przed jego wykonaniem. W tym celu chcę podpisać skrypt powershell i uruchomić powershell za pomocą zasady wykonywania "AllSigned".
Kwestia polega na tym, że naprawdę nie mogę podpisać skryptu na serwerze docelowym, ponieważ ma on ten sam problem, co PowerShell, który uruchamia skrypt ... Muszę zwolnić wyłączny blokadę, aby umożliwić PowerShell podpisanie pliku, ale może zostać naruszony.
Wówczas zdecydowałem, że jeśli będę mógł podpisać skrypt na serwerze, który dostarcza go do komputera docelowego, który będzie działał znacznie lepiej. Jednak nasze serwery oprogramowania do zarządzania konfiguracją to tylko Linux, a ja nie mogłem znaleźć sposobu na podpisanie skryptów PowerShell na Linuksie. Mono ma wsparcie dla Authenticode, ale po wyjęciu z pudełka jest tylko dla exes i bibliotek dll. Próbowałem zagłębić się w funkcje PowerShell .Net, ale odkryłem, że korzystają z Cryptui.dll, który jest specyficzny dla systemu Windows.
W tym momencie trzymam się za to, że mogę dostać podpis dodany do skryptów, bo inaczej będę musiał zmienić sposób działania skryptów, które nie są tak naprawdę natywne. Jeśli to możliwe, chciałbym móc obliczyć sygnaturę w pamięci na łańcuchowej reprezentacji skryptu, ale wezmę metodę opartą na plikach, jeśli to wszystko, co mogę dostać.
Musieliśmy podpisać pliki tekstowe przy publikacji i użyć VBox Windows VM (z hasłem SHA na podstawie plików skopiowanym przy starcie), rozprowadzić go na maszynie budującej i użyć WinRb do wykonania 'Set-AuthenticodeSignature' na pliki, zamknij i wyrzuć kopię woluminu opartą na plikach ... naprawdę brzydka, ale działa naprawdę dobrze ... w końcu została zastąpiona niestandardową wersją 'osslsigncode' – SushiHangover
Nurkuję w mono Authenticode klasy i myślę, że mam dość wymyślonego, aby stworzyć zmodyfikowaną wersję, która działa na danych ze standardowego wejścia. Pomyślałem, że poproszę oprogramowanie do zarządzania konfiguracją o wywołanie mono exe, przekaż ciąg znaków, a następnie przeczytaj standardowe wyjście dla podpisanej wersji. Nasze oprogramowanie do zarządzania konfiguracją działa natywnie w Ruby, więc mam ochotę spróbować zbudować klasę ruby, używając biblioteki openssl do replikowania kodu mono. – AresonDeladious
Nie można zapobiec manipulowaniu przy użyciu zabezpieczeń folderów, aby zablokować innym kontom dostęp do zapisu lub przez umieszczenie skryptu na serwerze WWW, a następnie wykonanie za pomocą 'iex ((New-Object System.Net.WebClient).DownloadString ('https: //myServer/myScript.ps1')) '? Będziesz potrzebował tego tylko w swoim skrypcie do podpisywania, który może następnie wycofać skrypt i podpisać go zgodnie z wymaganiami; po której możesz użyć według swojego opisu. – JohnLBevan