Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

Bezpieczny windows cz.2

Poprzednią część skończyła się na tym, jak zabezpieczyć system, w tej cześć skupię się na tym, jak możemy zabezpieczyć pliki prywatne.
Jak wspomniałem w cz.1, pracując na koncie standardowego użytkownika potencjalny złośliwy kod uruchomiony z poświadczeniami standardowego użytkownika nie może ingerować w ustawienia systemowe, może natomiast narobić szkód w katalogach i plikach do których ten użytkownik ma dostęp. Rozwiązaniem jest stworzenie czegoś w rodzaju 'piaskownicy', choć nie w sensie technicznym, a raczej w sensie idei ograniczenia pola działania aplikacji, które mogą być podatne na atak. Idealnym rozwiązaniem byłoby możliwość nadania każdej aplikacji zakresu dostępu do różnych lokacji na dyskach - ale takich mechanizmów standardowo nie ma w windowsie, stąd nasz kaganiec na aplikacje utworzony zostanie z nowego konta użytkownika, którego uprawnienia dostępu ograniczymy do niezbędnego minimum.

Tworzenie nowego standardowego użytkownika (z konta administracyjnego) -> cmd->net user su psw /addużytkownik dostał przykładową nazwę su (od safeuser, nie superuser;)), oraz hasło psw - takimi nazwami będę się posługiwać dalej w tym wpisie. Konto su będzie służyć do uruchamiania z jego uprawnieniami aplikacji potencjalnie podatnych na atak - np. przeglądarki, mailery, pdf-readery, odtwarzacze multimedialne, aplikacje z niezaufanych źródeł i a i niekiedy z zaufanych, ale które nie zawsze wiadomo co robią, itp. Standardowo stworzony użytkownik jak powyżej ma dostęp do swojego katalogu %USERPROFILE% z uprawnieniami odczyt+zapis, %windir% - tylko odczyt, wszystkie inne wolumeny: odczyt+zapis. W zależności od tego, jak bardzo chcemy ograniczyć dostęp su do innych wolumenów możemy zostawić atrybuty Read/Write, ograniczyć do R, lub odmówić(N) w ogóle dostępu do tych partycji - i ta opcja zostanie zastosowana dla su w tym wpisie.

Zakładając, że c:\ jest systemowy, a d:\ to partycja z rzeczami, która dla działania przeglądarki, mailera, pdf-reader,itp nie jest potrzebna: cmd->cacls "d:" /E /T /P su:N - odmawiamy dostępu do wszystkich plików i folderów na wolumenie 'd:\', nie zmieniając wcześniejszych uprawnień tam będących - dorzucamy tylko swoje 3 grosze dla su. Oczywiście można to zrobić bardziej wybiórczo i nadawać różne uprawnienia różnym katalogom, ale zazwyczaj nie ma żadnego powodu, dla którego np. Firefox miałby mieć dostęp do innego dysku - no, chyba, że ma tam ustawioną ścieżkę dla pobierania - standardowo jest ona w %USERPROFILE%. Można jeszcze dla całego katalogu %USERPROFILE% użytkownika su odmówić prawa do uruchamiania plików wykonywalnych i jednocześnie uszczuplić uprawnienia by ten nie mógł zmieniać uprawnień w tej lokalizacji, co sprawi, że nawet jeśli złośliwy kod utworzy exeka gdzieś w katalogach profilu su, nie będzie go w stanie uruchomić ani nadać praw do tego. Niestety prawa do uruchamiania programów nie można odmówić z cacls w wersji XP (w vista/7 - jest 'icacls' który ma taką możliwość); w XP Professional możemy te uprawnienie łatwo ustawić z zakładki 'Zabezpieczenia' exploratora, w XP Home trzeba się dostać do windy w trybie awaryjnym.[PS.1]
Jak korzystać z konta su ? oczywiście można korzystać z FastUserSwitching - ale przełączanie użytkowników jest o tyle nieprzyjemne, że wymaga podawania haseł przy każdym przełączeniu - no, chyba, że ktoś ma konta zupełnie bez haseł - ale takiego wariantu nawet nie rozpatruję; drugą niedogodnością są rozłączne pulpity - albo jeden albo drugi. Rozwiązaniem jest korzystanie z możliwości uruchomienia aplikacji z innymi poświadczeniami, co nie mniej nie więcej oznacza, że dwa okna obok siebie mogą pracować z zupełnie innymi uprawnieniami. Najprostszym sposobem na to, jest zrobienie sobie linków do programów i ustawić w ich właściwościach: ->zaawansowane->uruchom z innymi poświadczeniami. Dosyć wygodne, gdyby nie fakt, że uruchomienie z innymi poświadczeniami wymaga by konto miało hasło i przy uruchamianiu zawsze trzeba wybrać użytkownika z którego poświadczeniami będzie uruchomiony program i dodatkowo wpisać hasło. Niewiele lepiej jest z runas, bo również wymaga hasła, a na nieszczęście nie można go podać w formie: 'runas (..jakieś parametry..) < secret_folder/secret_file_with_pass.txt', runas oczekuje na podanie ich 'z palca'.

Dla wygodnego wykorzystani tego konta trzeba bardziej radykalnych kroków - napiszemy program który będzie uruchamiał aplikacje z odpowiednimi poświadczeniami. W windowsie nie ma domyślnie kompilatora, ani nagłówków. Można je sobie ściągnąć ze stron MS - ale całe środowiska z tonami dokumentacji będzie ważyć od kilkuset MB do kilku GB a dla kogoś niezainteresowanego to marnowanie czasu, miejsca i dodatkowy śmietnik. Z tego powodu wykorzystamy C# i .NET, którego kompilator jest instalowany wraz z samym frameworkiem. Dla naszych celów wystarczy, że mamy zainstalowany .NET 2.0, ma on już trochę lat, wiec pewnie gości na wielu komputerach.

Kodu nie będę tłumaczył, wskażę tylko istotne miejsca, by można go było dopasować do swojej nazwy użytkownika - odpowiednika su.

Dwa słowa wyjaśnienia jak przygotować się do kompilacji - tworzymy sobie np. na pulpicie katalog a w nim dwa zwykłe pliki tekstowe do których wkleimy kod:
plik c.bat - polecenie kompilowania naszego kodu: %windir%/Microsoft.NET/Framework/v2.0.50727/csc.exe /target:winexe RunAsSu.cs pause

oraz plik RunAsSu.cs using System; using System.IO; using System.Security; using System.Diagnostics; using System.Windows.Forms; using System.ComponentModel; namespace SafeUser { class SafeUser { [STAThread] public static int Main(string[] argv) { string usr_n = "su"; string usr_p = "psw"; if(String.Compare(Environment.UserName,usr_n,true)!=0) { SecureString spsw = new SecureString(); for(int ch = 0; ch < usr_p.Length; ++ch) spsw.AppendChar(usr_p[ch]); ProcessStartInfo psi = new ProcessStartInfo(); psi.UserName = usr_n; psi.Domain = Environment.UserDomainName; psi.Password = spsw; psi.LoadUserProfile = true; psi.UseShellExecute = false; //:-( if(argv.Length > 0) { psi.FileName = Process.GetCurrentProcess().MainModule.FileName; psi.Arguments = "\"" + argv[0] + "\""; psi.WorkingDirectory = Path.GetDirectoryName(psi.FileName); } else { psi.FileName = Environment.GetEnvironmentVariable("COMSPEC"); psi.Arguments = "/K TITLE " + usr_n; psi.WorkingDirectory = Path.GetDirectoryName(psi.FileName); } try { Process.Start(psi); } catch(Win32Exception ex) { MessageBox.Show(ex.Message, psi.FileName); } } else { if(argv.Length > 0) { try { Process.Start("\"" + argv[0] + "\""); } catch(Win32Exception ex) { MessageBox.Show(ex.Message, argv[0]); } } else { ProcessStartInfo psi = new ProcessStartInfo(); psi.FileName = Environment.GetEnvironmentVariable("COMSPEC"); psi.Arguments = "/K TITLE " + usr_n; psi.WorkingDirectory = Path.GetDirectoryName(psi.FileName); Process.Start(psi); } } return 1; } } }

to co najważniejsze w tym kodzie dla nas to dwie linijki: string usr_n = "su"; //<---- nazwa użytkownika string usr_p = "psw"; //<---- hasło
w te dwa miejsca wpisujemy naszego użytkownika i hasło; Można się wzdrygnąć, że hasło tak po prostu sobie tutaj zapisujemy czystym tekstem. Możemy tak zrobić - to hasło to nie jest żadna tajemnica - i tak musimy zakładać, że Windows/IE/FF/whatever są dziurawe i złośliwe oprogramowanie ma szanse się uruchomić z poświadczeniami su - na to nic nie poradzimy, to działka twórców oprogramowania by łatać dziury - czy antywirusów by odpowiednio zareagować na ich próbę wykorzystania. Naszym zadaniem jest jedynie zablokować możliwości manewru robakowi, który już zdołał uruchomić się w systemie. Stąd nawet poznanie przez kogoś/coś hasła do su nie będzie się różnić niczym w poruszaniu się po koncie jak w przypadku infekcji robakiem z uprawnieniami tego konta.

Ale do rzeczy - kompilowanie kodu odbywa się przez uruchomienie c.bat - jeśli wszystko pójdzie dobrze, utworzy się w tym samym katalogu plik RunAsSu.exe. I tu rzecz bardzo ważna do nadmienienia a wynikająca z ograniczeń naszej aplikacji - z poziomu roboczego konta uruchomienie aplikacji z innymi poświadczeniami (su) jest możliwe tylko w przypadku uruchamiania plików wykonywalnych (*.exe), natomiast - linki do programów, pliki graficzne, tekstowa, i wszystkie inne z danymi, które są skojarzone z otwierającymi je aplikacjami musi otwierać w dwóch krokach. Robi to przez uruchomienie siebie samej z poświadczeniami su, i dopiero z tymi poświadczeniami może otwierać dowolne pliki niewykonywalne skojarzone z innymi aplikacjami (np. *.txt -> notatnik). Ponieważ su nie ma praw dostępu do naszego pulpitu, nie może uruchomić samej siebie z tymi uprawnieniami, stąd musimy RunAsSu.exe umieścić gdzieś, gdzie su ma przynajmniej dostęp do odczytu i uruchamiania. Może to być jakiś specjalnie do tego celu stworzony katalog na C:\ i dla wygody wyprowadzony skrót na nasz pulpit, lub wygodniej - wrzucić RunAsSu.exe do %ALLUSERSPROFILE%\pulpit - aplikacja pojawi się na naszym pulpicie, ale fizycznie będzie na pulpicie publicznym dostępnym do odczytu dla wszystkich użytkowników - w tym i dla su. W takiej konfiguracji możemy odpalić dowolny plik przeciągając go na nasz RunAsSu.exe na pulpicie. Pamiętać jednak należy, że np. wszystkie pliki które mamy na pulpicie nie uruchomią się, z racji tego, że su nie ma do naszego pulpitu dostępu nawet do odczytu - można mu ten dostęp dać, ale to już pewne ryzyko, że złośliwy kod będzie w stanie coś odczytać z katalogu naszego pulpitu.
Po uruchomieniu przez RunAsSu np. IE możemy sprawdzić w taskmanagerze z jakimi uprawnieniami się odpalił - powinniśmy zobaczyć go jako su. Inaczej może być z Firefoxem - jeśli nie mamy jeszcze żadnej uruchomionej instancji, to odpali się prawidlowo z uprawnieniami su, natomiast jeśli jest już uruchomiona jedna instancja, to niezależnie od tego z jakiegos poświadczenia spróbujemy uruchomić drugą instancję, zostanie ona uruchomiona z poświadczeniami z tej pierwszej instacji. Jest to zachowanie dosyć specyficzne, co z resztą przejawia się też tym, że FF nie potrafi odpalić swojej drugiej instancji jeśli uruchamiamy ją po zalogowaniu się na drugiego użytkownika korzystając z opcji przelogowania się.
Kilka słów jeszcze odnośnie wygody użytkowania takiego rozwiązania.
Przeciąganie aplikacji z menu start na RunAsSu może uruchomić(mieć do niej prawo dostępu)daną aplikację lub też nie i krzyknąć o braku dostępu, w zależności od tego, czy dane skróty w menu start były umieszczone w profilu %ALLUSERSPROFILE% czy w profilu konta z którego była instalowana aplikacja. Niekiedy instalatory pytają o to, czy skróty mają być dostępne dla wszystkich userów, czy tylko dla instalującego i od tego zależy w którym profilu w menu start fizycznie znajdą się skróty. Niekiedy nie pytają i robią jak im się podoba. Ja dla wygody skróty do wszystkich często używanych aplikacji które uruchamiam z su mam w specjalnym katalogu na "C:/su/links/" który jest podłączony jako pasek narzędzi do taskbaru (prawy na taskbarze -> paski narzędzi -> nowy pasek narzędzi -> katalog na "c:\su\links" ze skrótami). Korzystając z Firefoxa z su, jedyne co zrobiłem, to ustawiłem sobie katalog pobierania gdzieś 'blisko pod myszą', tj. 'c:/su/download' , zlinkowałem na pulpit i odmówiłem mu praw uruchamiania plików wykonywalnych.
Tak mniej więcej wyglądają moje preferencje jeśli chodzi o pracę z ograniczonym kontem su, dopasowałem je sobie w ten sposób, by nie była to tylko sztuka dla sztuki, a praktycznie sprawdzające się rozwiązanie. Nie każdemu może się to wydawać wygodne, czy nawet sensowne, już nie mówiąc o kwestii przyzwyczajenia do zmian - ale nic nie stoi na przeszkodzie, żeby sobie pracę z kontem su dostosować pod swoje preferencje.

Osobiście na konto administracyjne 'jawnie' z ekranu logowania nie wchodzę prawie nigdy, używam prywatnego konta standardowego/ograniczonego jako konta roboczego, do którego się loguję po starcie windowsa, a dodatkowo konto su do czynności, które uznaję za ryzykowne. Do zadań wymagających większych uprawnień, uruchamiam cmd z poświadczeniami administracyjnymi - w mniej więcej w podobny sposób jak z su - a dostęp do różnych elementów systemu uzyskać można przez szereg apletów *.msc, *.cpl, np. sysdm.cpl uruchamia właściwości "Moj Komputer", desk.cpl - właściwości ekranu, services.msc - applet z listą usług, regedit - wiadomo, itp. - można je sobie wylistować przez cmd-> dir %windir%\system32\*.cpl, czy zwykłe wyszukaj w starcie. Konsekwencją takiego 'skonfigurowania' sobie windowsa, pozbyłem się antywirusa, jako zbędnego elementu - z resztą przez te wszystkie lata krzyknął mi raptem kilka razy i to najczęściej, gdy dema gier z zaufanych stron próbowały przemycić jakiś ad-ware, czyli de facto nic groźnego, choć niepotrzebnego.

Koniec cz.2 - choć do napisania zostało jeszcze trochę, ale ze względu na zbliżające się święta czas się skurczył a i sił mniej.

c.d.n.

PS.1 - Ustawianie uprawnień w XP Home - niestety, explorer pod właściwościami dla plików/folderów nie wyświetla apletu 'Zabezpieczenia' (XP Professional wyświetla!)- choć ogólnie sam aplet jest w systemie, ale dostępny tylko przy wejściu do windy w 'trybie awaryjnym'. Jeśli potrzeba ustawiania go z explorera można zainstalować dostępny jeszcze z linii starych windowsów NT pakiet, który tę zakładkę przywraca przy pracy poza trybem awaryjnym - paczkę taką można znaleźć na serwerze MS, ale z racji, że nie wiem jak z legalnością takiego rozwiązania, nie podam linku, bo nie chcę namawiać do przestępstwa ;-). Do prostego nadawania uprawnień można wykorzystać jeszcze cacls.exe z poziomu cmd.

PS.2 - Dla osób które nie lubią za dużo machać myszą, pole do popisu pozostawia zwykłe otwarcie RunAsSu.exe - które odpali cmd.exe z uprawnieniami su. Przy odrobienie chęci, można podany wyżej kod zmienić, by po otwarciu cmd.exe bieżącym katalogiem był np. "c:/su/apps/", w którym można sobie zdefiniować kilka skrótów np. dwuliterowych do odpalania najczęściej wykorzystywanych aplikacji. U mnie wygląda to tak, że np. pod ff.bat mam uruchomienie firefoxa, co po odpaleniu konsoli ogranicza się do wpisania 'ff' by go uruchomić, 'wa' i odpala się winamp, 'mpc' - media player classi home cinema', itd; przykładowy ff.bat do odpalenia FF: @pushd "%ProgramFiles%\Mozilla Firefox" @start /I firefox.exe @popd @cls

start /I w praktyce powoduje, że uruchomiony program zwraca od razu sterowanie do cmd, wiec można cmd używać od razu do dalszej pracy.
 

Komentarze

0 nowych
webnull   9 #1 23.12.2010 13:00

"net user su psw /add"

To raczej nie jest bezpiecznie, ponieważ w historii powłoki można odnaleźć hasło użytkownika.

Tormiasz   6 #2 23.12.2010 16:40

Bezpieczny Polak tak jak statystyczny klient, nie istnieje :)

Ogólnie wpis ciekawy. Fajne rozwiązanie na zabezpieczenie w pewnym stopniu swoich okienek.

  #3 23.12.2010 19:42

Osobiście popieram, wpis godny uwagi, co potwierdza fakt że Windows też jest bezpieczny, jak się tylko pod maskę jego zajrzy to jest tak samo bezpieczny jak linuxowe systemy, w których zresztą też grzebie się pod maską, tylko niewiele osób wie że Windows ma w sobie oprócz wyglądu, coś takiego jak np. cmd, który ma zbliżone możliwości do konsoli unixowych, ale kto by wiedział, ogólnie podsumuję to tak, system w zakresie bezpieczeństwa ma drugorzędne znaczenie, to od użytkownika zależy poziom bezpieczeństwa na komputerze, dlatego zachęcam autora do kontynuacji wpisów związanych z tą tematyką.

przemek1234   7 #4 24.12.2010 09:40

Na Viście nie trzeba tego robić, bo tam domyślnie programy uruchamiają się bez uprawnień admina, program może o nie poprosić specjalną flagą w pliku manifest, wtedy użytkownik jest pytany o zgodę (można przestawić, że każe mu wpisać swoje hasło, tak jak sudo na Linuksie). Jeżeli chcemy odpalić jako administrator program, który nie ma flagi z winy programisty, a wymaga uprawnień administratora to dajemy PPM - Uruchom jako administrator. Szkoda tylko, że większość ludzi wyłącza tą funkcję, bo uważają, że ich denerwuje.

Zulowski   8 #5 24.12.2010 14:39

"ma w sobie oprócz wyglądu, coś takiego jak np. cmd, który ma zbliżone możliwości do konsoli unixowych,"
Brawo Sławekn :D

kwidzius   2 #6 25.12.2010 16:44

bezpieczny windows cz3:

zainstaliwac linuxa i pozbyc sie windowsa

przemek1234   7 #7 25.12.2010 19:39

@kwidzius:
Nie troluj, Windows wcale nie jest mniej bezpieczny od Linuksa, jak się go dobrze używa i ma aktualnego.

kwidzius   2 #8 26.12.2010 12:32

Spoko. pytanie tylko ile osob potrafi 'bezpiecznie' uzywac windowsa. 95% ktore znam nawiet nie wiedza jaki system uzywaja.

  #9 26.12.2010 15:29

@przemek1234:
"Na Viście nie trzeba tego robić, bo tam domyślnie programy uruchamiają się bez uprawnień admina(...)"
Wydaje mi się, że nie zrozumiałeś, o co chodziło autorowi artykułu. Nie chodzi o to, aby program uruchamiał się bez uprawnień administratora (bo, o ile pracujesz na koncie zwykłego użytkownika, to i tak jest to standardowe działanie czy to na Viście, 7 czy na XP) ale chodzi o to, aby program był uruchamiany na koncie zwykłego użytkownika z uprawnieniami innego zwykłego użytkownika. "RunAsSu" uruchamia na Twoim zwykłym koncie program jako inny zwykły użytkownik po to, aby ten nie miał dostępu do danych zgromadzonych na Twoim profilu.

@Sławekn:
"(...)niewiele osób wie że Windows ma w sobie oprócz wyglądu, coś takiego jak np. cmd, który ma zbliżone możliwości do konsoli unixowych(...)"
Nie żartuj sobie :D Przepaść między konsolą Windowsa a konsolą w typowym systemie unixowym jest ogromna. Windows jest systemem projektowanym z nastawieniem na obsługę przez środowisko graficzne, natomiast w takim np. Linuksie środowisko graficzne to tylko dodatek, w którym jakiekolwiek narzędzie graficzne są w zasadzie nakładkami na konsolę i równie dobrze można się obejść bez uruchamiania "okienek".

webnull   9 #10 26.12.2010 17:47

@Sławekn
"Windows ma w sobie oprócz wyglądu, coś takiego jak np. cmd, który ma zbliżone możliwości do konsoli unixowych"

Bzdura, znam cmd bardzo dobrze, a konsolę Uniksową jeszcze lepiej.

  #11 26.12.2010 21:38

webnull >>
myslisz sie, konsola w windows dorównuje tej unixowej. oprócz cmd mamy jeszcze powershell

  #12 27.12.2010 10:34

"myslisz sie, konsola w windows dorównuje tej unixowej. oprócz cmd mamy jeszcze powershell"

Uhaaaaa, normalnie mam ubaw na parę tygodni... uwierz powershell to tylko namiastka o cmd szkoda wspominać!

  #13 27.12.2010 11:04

@ghostQQ

Masz rację ale dopiero po wprowadzeniu powershell komenda w Windowsie nie była już więcej żenującym reliktem nie zdatnym na wiele. Samo cmd jest piekielnie proste jeśli nie prostackie, powershell z tego co widziałem jest cał?iem niezłe ale ocenę pozostawiam tym co się znają na powershellu.

Bash czy zsh wciąga noskiem windosowskie cmd.

  #14 27.12.2010 11:51

Panowie, osoby cierpiące na brak zakładki 'Security' w XP Home mogą skorzystać z następującego programiku:
http://www.fajo.de/main/en/software/fajo-xp-fse
Program jest od lat dostępny i zawsze używałem go na maszynach z XP Home.
Jest też jeszcze co najmniej jedno rozwiązanie od jakiejś rosyjskiej firmy, ale niestety nie pamiętam nazwy w tej chwili. Oferuje ono możliwość wygodnego wglądu w ACL dla wielu plików/folderów/użytkowników, w związku z czym może być przydatne na każdym Windowsie, nie tylko XP Home.

_qaz7   6 #15 27.12.2010 18:44

żeby mówić, że powershell to namiastka, to trzeba mieć o nim blade pojęcie. powershell to w zasadzie skryptowy .NET z pipe-sami. O ile w linuksie pracuje się głownie na strumieniach tekstu, o tyle w powershellu pracuje się już na obiektach .NET, stąd przez pipe można przekazywać np. całą kolekcję dowolnych obiektów, programować wielowątkowo, wykorzystywać WinFormsy, przez reflections korzystać z całego WinApi. Jak ktoś ma ze 1-2 dni zaparcia i przeglądnie sobie ze zrozumieniem np. "Mastering-PowerShell.pdf" - nie wróci już raczej do biednych batów z cmd.

  #16 03.01.2011 21:13

Po co ci konsola, jak przeciętny kowalski, używając pc, ma czasu na bawienie się w konsole godzinami, tylko po to aby mieć bezpieczny system, to mija się z celem, Jakby linux bł tak samo dostępny, na tyle sprzętów co windows, to by tak bardzo się tym bezpieczeństwem nie chwalił, nawet wydajnościowo, linux z KDe 4.5 jest wolniejszy od 7, co do gnome, to sytuacja wygląda inaczej, a po wyłączeniu aero, ( i pewnym triku, z menadżerem okien w windowsie) to system dostaje kopa. Więc wydajnościowo niema tu różnicy.