Prywatna piaskownica, czyli Windows Sandbox #praktycznie

Zapraszam do części praktycznej artykułu poświęconemu funkcji Windows Sandbox.

W ramach sekcji #merytorycznie wyjaśniłem czym jest piaskownica Windows, w jakim celu można ją wykorzystać oraz na jakie aspekty bezpieczeństwa należy zwrócić uwagę rozpoczynając pracę z tym produktem. W sekcji #praktycznie postaram się przedstawić przykłady zastosowania, a także wykorzystać Windows Sandbox do stworzenia narzędzia rozszerzającego możliwości codziennej pracy.

GDZIE JEST MÓJ ZAMEK, GDZIE MOJE ZABAWKI?

Systemy typu Sandbox charakteryzują się swego rodzaju ulotnością, która powoduje, że wszystko, co na nich robimy, znika wraz z zamknięciem procesu. Czy to wada? To na pewno cecha, którą można przekuć w sporą korzyść. Do tego wystarczy odrobina czasu oraz określenie oczekiwań względem wyposażenia naszej piaskownicy. Tu zaczyna się największa zabawa.

Zacznę od instalacji funkcji w systemie Windows. Najłatwiej jest to zrobić za pomocą polecenia Powershell:

Wymagane jest ponowne uruchomienie systemu i od tej chwili możliwe jest uruchamianie systemu Sandbox na hoście za pomocą narzędzia Windows Sandbox dostępnego z poziomu menu start.

Jak wcześniej wspomniałem, podstawowa konfiguracja wymaga dodatkowych aktywności, aby spełniała oczekiwania osób używających tej funkcji systemu do zastosowań profesjonalnych.
W tym celu należy wygenerować własny plik konfiguracyjny o rozszerzeniu *.wsb, który służył będzie do personalizacji i uruchamiania piaskownicy. Taki plik można przechowywać w dowolnym miejscu na dysku.

W pierwszej kolejności spróbuję stworzyć bazową konfigurację i pomyślnie ją uruchomić.
W tym celu stworzę poniższą sekcję w pliku o rozszerzeniu .wsb. Plik nazwałem First.wsb.

Po jego zapisaniu jestem w stanie uruchomić bazową maszynę. Świetnie – pierwszy krok za mną. W następnym kroku spróbuję zamapować folder oraz nadać do niego prawo zapisu, zatem uzupełnię sekcję Configuration dodatkowymi parametrami i nazwę plik, jako MappedFolder.wsb:

Po uruchomieniu piaskownicy widać mapowany folder oraz możliwość zapisu:

Na wstępie chciałbym zwrócić szczególną uwagę na ścieżkę mapowanego folderu z poziomu piaskownicy:
C:\Users\WDAGUtilityAccount\Desktop\(Nazwa_Folderu)
W moim przypadku: C:\Users\WDAGUtilityAccount\Desktop\DevOps

Jest to istotne w przypadku budowy narzędzi obsługujących pliki znajdujące się w tej lokalizacji.
Od teraz w łatwy sposób mogę wymieniać pliki między hostem, a maszyną Sandbox, dzięki czemu jestem w stanie uruchamiać potencjalnie niebezpieczne pliki na odizolowanym środowisku bez ryzyka uszkodzenia systemu hosta. Mogę też używać tego systemu do innych zastosowań, jak uruchamianie niewygodnych skryptów, aplikacji czy do debugowania kodu.

Właściwie na tym można, by zakończyć artykuł, ponieważ do odpowiednio uzupełnionego katalogu mógłbym wrzucić instalki potrzebnych narzędzi, a następnie instalować je na piaskownicy… czy jednak o to nam chodzi? Każde zbędne kliknięcie myszką to strata czasu, a z pewnością nie jest to moment, w którym kończą się możliwości.

SPRAWDŹMY TO...

Posiadam już przestrzeń, w której mogę wymieniać się plikami. Wykorzystam ją do stworzenia skryptu, który będzie uruchamiany każdorazowo przy uruchomieniu Windows Sandbox. Dzięki temu zaoszczędzę czas wymagany na ręczne dostosowanie maszyny do własnych potrzeb. W tym celu wykorzystam element LogonCommand, za pomocą którego spróbuję uruchomić wiersz poleceń. Plik zapisuję pod nazwą RunCMD.wsb.

Po zapisaniu i uruchomieniu piaskownicy z pliku RunCMD.wsb ukazuje się poniższe okno:

To oznacza, że mogę zacząć myśleć o bardziej złożonych operacjach, jak na przykład zmiana tapety.

Do tego potrzebuję czterech rzeczy: 

1. Oczywiście tapety! Plik zapisuję do katalogu, który będzie mapowany na maszynie typu Sandbox.
   
   
2. Skryptu, który użyje pliku *.jpg do stworzenia nowej tapety. W tym celu zastosuję prostą funkcję w Powershell, którą w postaci pliku o nazwie Set-Background.ps1 zachowam w tym samym katalogu:
   
   
   
   
   
   
   
3. Pliku Background.cmd, który będzie w stanie wywołać funkcję Powershell i w efekcie ustawić pożądaną tapetę:
   
   
   
   
   
   
4. Wskazania pliku cmd w pliku *.wsb.
   
   
   
   
   
   

Po włączeniu maszyny uruchamia się okno cmd:

Po jego zamknięciu widoczny jest efekt zmian:

Po tym ćwiczeniu mam już solidne fundamenty do dalszej personalizacji. W tym miejscu należy zadać sobie pytanie, jakie narzędzia niezbędne są w profesjonalnej pracy?

ZAPNIJ PASY!

Na warsztat wziąłem przykład DevOps i podstawowe narzędzia pozwalające na pisanie kodu, edycję plików konfiguracyjnych i debugowanie, czyli: Firefox, Notepad++, Visual Studio Code, Git. Z takim zestawem aplikacji można myśleć o pracy w obrębie wytwarzania oprogramowania. Zaczynamy!

1. Do instalacji wyżej wymienionych narzędzi użyję repozytorium choco, zatem w pierwszej kolejności stworzę plik Powershell, który zainstaluje niezbędne narzędzia. Nazwę go Install-Prerequisites.ps1 i zapiszę w mapowanym folderze:
   
   
   
   
   
   
2. Plik ten wyzwalany będzie z poziomu cmd, zatem tworzę plik Trigger-Prerequisutes.cmd i zapisuję w tym samym katalogu:
   
   
   
   
   
   
3. Wskazuję plik cmd w konfiguracji, a plik zapisuję jako Sandbox-DevOps.wsb: C:\Sandbox\DevOps false explorer.exe C:\Users\WDAGUtilityAccount\Desktop\DevOps\Trigger-Prerequisites.cmd
   
   

Po uruchomieniu maszyny i odczekaniu około trzech minut widzę efekt finalny dotychczasowej pracy:

Maszyna działa, narzędzia są dostępne. Można zaczynać pracę…

…albo i nie.

Jeśli dobrnąłeś do tego miejsca, jest mi niezmiernie miło. Jeśli czytałeś uważnie, pewnie zauważysz, że zapomniałem o tapecie. Jednak nie zrobiłem tego celowo. Chciałbym, abyś w ramach pracy domowej utrwalił to ćwiczenie i stworzył spójny „obraz” piaskownicy, ze swoim zamkiem i własnymi zabawkami!

__________________________________

Damian Petliński - Manager z prawie 10-letnim doświadczeniem w obszarze IT. Pasjonat automatyzacji i entuzjasta metodyki DevOps. Jeden z założycieli i współtwórców bloga technologicznego Architects Guru.