dla początkujących

56

wrzesień 2004

Bezpieczeństwo

Linuksa

Piotr Machej

J

ednym z podstawowych argumen-
tów używanych przez zwolenników
Linuksa w dyskusjach z użytkowni-
kami Windows jest to, że Linux jest

bezpieczny. Ale czy rzeczywiście tak jest?
Nie do końca. W przypadku każdego sys-
temu operacyjnego należy podjąć pewne
kroki, które utrudnią zadanie ewentual-
nym czarnym charakterom.

Przykład użycia

Nareszcie zaczęło się lato. Wydawałoby
się, że wszystkich wywieje nad wodę, ale
nie – nadal wielu ludzi woli (niektórzy
nie mają wyjścia) ślęczeć przed moni-
torami. Niektórym rosnąca temperatura
podgrzewa krew i skłania do niezbyt
rozsądnych czynów. Jeden z takich osob-
ników postanowił zabawić się kosztem
mojego znajomego, włamując mu się na
konto i przerabiając jego stronę WWW.

Znajomy bardzo się zdziwił, zmartwił

i zdenerwował (to łagodne określenia
stanu faktycznego), po czym przybiegł
do mnie domagając się, abym pomógł
mu się zemścić. Gdy już się uspokoił,
porozmawialiśmy chwilę. Okazało się,
że włamanie mogło nie mieć miejsca,
gdyby bardziej dbał o swój system. Czy
można się dziwić, że ktoś nie skorzystał
z zaproszenia, jakim jest karteczka
z hasłem wywieszona na monitorze sto-
jącym w pokoju w akademiku? Tym bar-
dziej, że znajomy korzysta z tego samego
hasła dosłownie wszędzie, nawet przy
logowaniu na konto bankowe (sic!).

Zamiast mścić się na włamywaczu,

po cichu podziękowaliśmy mu, że nie
przelał sobie dosyć pokaźnej sumki
zaoszczędzonej na wakacyjny wyjazd
i od razu zabraliśmy się za lepsze zabez-
pieczanie systemu.

Bezpieczeństwo lokalne

Zawsze należy pamiętać o jednej zasadzie
– ten, kto ma fizyczny dostęp do kompu-
tera, ma również dostęp do zainstalowa-
nego na nim systemu i przechowywanych
danych. Z tego powodu bardziej istotne

serwery są przechowywane w specjalnie
zabezpieczonych pomieszczeniach, do
których mają wstęp tylko upoważnione
osoby. Niemniej, można utrudnić zada-
nie osobie, która chciałaby grzebać nam
w systemie pod naszą nieobecność. Dzięki
temu włamanie się może zająć jej na tyle
dużo czasu, że okaże się nieopłacalne.

Hasło systemowe

Zazwyczaj pierwszą zaporą stojącą na
drodze do systemu jest hasło użytkowni-
ka. Od nas zależy, na ile ta zapora będzie
skuteczna. Przykładowo, jeśli nasz zna-
jomy usiądzie przy naszym komputerze,
może próbować odgadnąć hasło. Zacznie
od daty urodzenia, imion rodziców,
nazwiska, jak również od rzucających
się w oczy napisów znajdujących się
w okolicy. Z tego powodu nigdy nie należy
tworzyć takich ani podobnych haseł.

Włamywacz może również w jakiś

sposób uzyskać dostęp do pliku z hasłami
(zazwyczaj zaszyfrowanymi), a następnie
z pomocą odpowiedniego programu
odgadnąć użyte w nim hasła. Takie pro-
gramy stosują metody słownikowe (wy-
próbowywane są kolejne słowa znajdujące
się w olbrzymich plikach tekstowych), jak
również brutalne ataki (program sprawdza
kolejne kombinacje znaków). Mamy kolej-
ną wskazówkę, jakich haseł nie używać
– słów znajdujących się w słownikach
(zarówno polskich, jak i angielskich), jak
również prostych, krótkich zlepków liter.
Dodatkowo, nie powinniśmy używać

O autorze

Autor ukończył studia na kierunku

Informatyka na Politechnice

Opolskiej. Z Linuksem (i ogólnie

systemami uniksowymi) ma

styczność od wielu lat. Obecnie

administruje dwoma sieciami

blokowymi. Wolne chwile dzieli

pomiędzy jazdy konne, pływanie,

czytanie książek i mang oraz oglą-

danie anime. Kontakt z autorem:

[e-mail]

Na płycie CD/DVD

Na płycie CD/DVD znajdują się

programy do wykonywania kopii

zapasowych danych.

CD/DVD

Po uruchomieniu dystrybucji
Linux+ Live CD/DVD można

przetestować omawiane

zagadnienia.

Rysunek 1.

Slang hakerski jest świetnym

sposobem na tworzenie trudnych do
odgadnięcia haseł

57

bezpieczeństwo Linuksa

dla początkujących

www.lpmagazine.org

haseł bardzo krótkich – rozsądne mini-
mum to 8 znaków. Bardzo złymi hasłami
są np. słowa ala i domek.

Skoro już wiemy, jakich haseł nie

należy używać, możemy się zastanowić,
jakich można użyć. Przede wszystkim
musi to być hasło łatwe do zapamię-
tania. Dzięki temu unikniemy pokusy
zapisywania go na karteczce przyklejo-
nej do monitora (niestety, jest to bardzo
częsta praktyka). Przykładowo, weźmy
hasło L,Om,Tjjz. Trudne do odgadnięcia?
Wystarczająco – ma 10 znaków, z czego
część to wielkie i małe litery, a są też
kropki i przecinki. Nie jest to słowo, więc
atak słownikowy się nie uda. Złamanie
takiego hasła brutalnym atakiem jest
możliwe, ale wymaga dosyć dużo czasu
i silnego komputera. A co z łatwością
zapamiętania? Chyba każdy zna ten cytat:
Litwo, Ojczyzno moja, Ty jesteś jak zdro-
wie... Jak widać, wzięliśmy z tego cytatu
pierwsze litery każdego słowa i znaki
przestankowe. W ten sposób można
wykorzystać praktycznie dowolny cytat.

Można spróbować innej metody.

Popatrzmy na takie hasło: 3,14jMl3k0.
Również trudne do odgadnięcia, ale do
zapamiętania wystarczy nam popularne
hasło reklamowe: Pij mleko. Litery Pi
zamieniliśmy na 3,14, usunęliśmy spację,
a słowo mleko zaczęliśmy wielką literą
i dodatkowo zamieniliśmy e na 3 i o na
cyfrę 0. Ostatnie dwie podmiany liter
pochodzą z dosyć popularnego w Inter-
necie slangu zwanego 1337 (leet, od elite).
Więcej na ten temat można poczytać
na stronach http://www.urbandictionary.
com/define.php?term=1337 i http://en.
wikipedia.org/wiki/Leet.

Jeszcze inna metoda, pozwalająca na

łatwe zapamiętanie haseł, to wciskanie
klawiszy znajdujących się o poziom wyżej
(lub niżej, lub o dwa w lewo itp.) od
klawisza, o którym myślimy. Przykłado-
wo, zapamiętujemy sobie słowo haselko,

a wpisujemy yqw3oi0 (klawisz [y] jest nad
[h], [q] nad [a] i tak dalej).

Oczywiście, każdy może wymyślić

własne hasło stworzone inną metodą.
Ważne jest, aby było łatwe do zapamię-
tania i trudne do odgadnięcia.

Należy pamiętać o tym, aby co jakiś

czas zmieniać swoje hasło. Szczególnie,
jeśli podejrzewamy, że ktoś mógł zoba-
czyć, jak je wpisujemy lub w inny sposób
je zdobyć – wtedy należy je zmienić
natychmiast (dla przypomnienia – służy
do tego polecenie

passwd

w konsoli tek-

stowej). Nie należy pozwalać, aby ktoś
pod naszą nieobecność mógł korzystać
z otwartej sesji. Przykładowo, w menu
KDE istnieje opcja Zablokuj ekran. Jej
użycie powoduje, że aby ponownie roz-
począć pracę, należy podać hasło zalogo-
wanego użytkownika.

Hasło LILO i GRUB

Wydawałoby się, że mając dobre hasło,
jesteśmy zabezpieczeni przed użytkow-
nikiem, który chciałby uzyskać dostęp do
naszego systemu. Nic bardziej błędnego.
Osoba mająca fizyczny dostęp do kom-
putera może wcisnąć przycisk RESET na
obudowie. Jeśli korzystamy z menedże-
ra ładowania LILO lub GRUB, to może
dopisać do parametrów wywołania jądra
słowo single (np. wpisując w tekstowym
LILO polecenie

linux single

). Spowoduje

to uruchomienie systemu w trybie jedne-
go użytkownika i przyznanie intruzowi
praw administratora bez konieczności
podawania hasła (sic!). W tym momencie
może zrobić z systemem wszystko – zmie-
nić hasło administratora (

passwd

), innego

użytkownika (

passwd nazwa_użytkownika

),

zainstalować tylną furtkę (ang. backdoor),
umożliwiającą mu ponowne uzyskanie
praw administratora (tym razem już bez
resetowania komputera), czy po prostu
skasować wszystkie pliki.

Jak się przed tym ustrzec? Jeśli pod-

czas instalacji dystrybucji zainstalowaliśmy
LILO, to będziemy musieli zmodyfikować
plik /etc/lilo.conf. W tym celu urucha-
miamy dowolny emulator terminala (np.
Terminal lub Multi Gnome Terminal).
Musimy uzyskać uprawnienia admini-
stratora, więc korzystamy z polecenia

su

i podajemy hasło użytkownika root.

Teraz możemy modyfikować plik konfi-
guracyjny w naszym ulubionym edytorze
(np.

vi /etc/lilo.conf

lub

mcedit /etc/

lilo.conf

). Na początku pliku dopisujemy

dwie linie o następującej treści:

password=hasło
restricted

Oczywiście, zamiast hasło wpisujemy
odpowiadające nam hasło. Należy
pamiętać, że umieszczone tu hasło jest
widoczne na ekranie, więc nie powinno
być takie samo, jak na którymkolwiek
koncie. Po zapisaniu zmian w pliku
należy uaktualnić dane w sektorze
startowym. W tym celu wydajemy pole-
cenie

/sbin/lilo

. Nie wolno tego kroku

pominąć, gdyż możemy mieć proble-
my z uruchomieniem systemu. Od tej
pory, jeśli przy uruchamianiu systemu
chcielibyśmy zmienić parametry wywo-
łania jądra, to zostaniemy zapytani
o hasło. Pominięcie w pliku /etc/lilo.conf
słowa restricted spowodowałoby, że
o hasło bylibyśmy pytani przy każdym
uruchomieniu systemu, niezależnie,
czy zmienialibyśmy parametry wywo-
łania.

W przypadku GRUB-a postępujemy

podobnie. Tym razem edytujemy plik
/boot/grub/grub.conf

(w

przypadku

Auroksa – w innych dystrybucjach plik
może znajdować się gdzie indziej). Na
jego początku dopisujemy linijkę o treści:

password hasło

.

Po zapisaniu zmian, jeśli ktoś zechce

podczas uruchamiania modyfikować
jakiekolwiek parametry, będzie musiał
podać hasło.

W przypadku obydwu plików (/etc/

lilo.conf i /boot/grub/grub.conf ) należy
upewnić się, że jedynie właściciel pliku
ma prawa do odczytu. Po co nam hasło,
jeśli każdy z użytkowników może je
odczytać. Dlatego wykonujemy następu-
jące polecenia:

chmod go-rwx /etc/lilo.conf
chmod go-rwx /boot/grub/grub.conf

Rysunek 2.

W Internecie jest wiele

serwisów dotyczących bezpieczeństwa,
głównie w języku angielskim

Rysunek 3.

Listy kontroli dostępu można

już wykorzystywać w Linuksie, choć nadal
standardem jest kontrola na poziomie
pliku

58

dla początkujących

wrzesień 2004

Bliższe objaśnienie tych poleceń znajduje
się w dalszej części artykułu, w rozdziale
Ochrona plików.

Hasło BIOS-u

Poczyniliśmy już tyle przygotowań,
a jednak nadal można dosyć łatwo spe-
netrować nasz system. Wystarczy, że
ktoś przyniesie swoją dyskietkę startową
i wskaże odpowiednią partycję z syste-
mem. Może również skorzystać z dowol-
nej dystrybucji uruchamianej z płyty CD
lub DVD – po jej uruchomieniu może
podmontować naszą partycję z syste-
mem i wprowadzić odpowiednie zmiany
(np. zmienić hasło administratora).

I na to jest sposób. W każdym kom-

puterze mamy możliwość założenia
hasła, o które jesteśmy pytani podczas
uruchamiania komputera lub przy próbie
zmiany konfiguracji. W naszym przypad-
ku powinno wystarczyć wyłączenie moż-
liwości startowania systemu z dyskietki
lub płyty oraz zabezpieczenie hasłem
możliwości zmian w konfiguracji. Ze
względu na różnorodność BIOS-ów, naj-
lepiej w tym celu zapoznać się z instruk-
cją dołączoną do komputera.

Włamywacz, który chciałby ominąć

to zabezpieczenie, musiałby otworzyć
obudowę komputera w celu zresetowa-
nia pamięci CMOS (zależnie od modelu
płyty, można tego dokonać wyciągając
baterię lub korzystając z odpowiedniej
zworki na płycie głównej). Może też
skorzystać z tzw. hasła uniwersalnego,
ale znalezienie hasła pasującego akurat
do naszej wersji BIOS nie jest takie
proste.

Ochrona plików

Rozważaliśmy dotąd działania osoby,
która próbuje uzyskać dostęp do naszego

systemu. Pamiętajmy jednak, że Linux jest
systemem wieloużytkownikowym – rów-
nocześnie może korzystać z niego wiele
osób. Założenie, że każdy, kto legalnie
korzysta z systemu, jest grzecznym
użytkownikiem, jest błędne. Często nie
wiemy, kim są inni użytkownicy i jakie
mają zamiary. Dlatego musimy uważać,
w jaki sposób chronimy dane umiesz-
czone w systemie. Pozwalają nam na to
prawa dostępu do plików oraz możli-
wość definiowania grup użytkowników.
Niestety, domyślny system praw dostępu
do plików nie jest zbyt doskonały, ale
póki nie zostanie dopracowany system
list kontroli dostępu (ACL – Access
Control List), musi nam wystarczyć.

Prawa dostępu

Na początku trzeba przyzwyczaić się
do myśli, że Linux wszystko traktuje
jako pliki. Zapisany na dysku obrazek
czy dokument tekstowy są plikami (to
jest naturalne), ale plikiem jest również
katalog i, co ciekawsze, urządzenie pod-
łączone do komputera. Przykładowo,
pierwszy dysk twardy to plik /dev/hda,
a umieszczona na nim partycja to /dev/
hda1. Z kolei napędowi CD-ROM odpo-
wiada plik /dev/cdrom. Dla nas oznacza
to tyle, że kontrolując prawa dostępu do
plików możemy równocześnie kontrolo-
wać dostęp do wielu urządzeń.

Uprawnienia do plików możemy

przydzielać właścicielowi pliku, grupie
oraz wszystkim pozostałym. Możliwe
uprawnienia to prawo do odczytu, zapisu

i wykonywania. Zobaczmy to na prak-
tycznym przykładzie. W oknie terminalu
wpiszmy polecenie

ls -l /etc/passwd

.

Powinniśmy uzyskać wynik podobny do
poniższego:

-rw-r--r-- 1 root root

S

1966 cze 30 12:10 /etc/passwd

To, co nas w tej chwili interesuje, to ciąg
-rw-r--r-- oraz dwa wyrazy root. Pierw-
szy wyraz root wskazuje, że właścicielem
pliku /etc/passwd jest użytkownik root.
Natomiast drugi mówi, że grupą, która
ma uprawnienia do tego pliku, jest grupa
o nazwie root. Więcej o grupach dowie-
my się w dalszej części artykułu. Na razie
skupimy się na ciągu -rw-r--r--, określają-
cym uprawnienia do pliku.

Pierwszy myślnik tego ciągu wskazu-

je, że /etc/passwd jest zwykłym plikiem.
W przypadku katalogów w tym miejscu
znajduje się litera d, ale można spotkać
się jeszcze z literami b (urządzenie bloko-
we) i c (urządzenie znakowe).

Następne trzy znaki to prawa

przyznane właścicielowi pliku (w tym
przypadku użytkownikowi root). Ma
on możliwość czytania pliku (r – Read)
i zapisywania go (w – Write). Nie ma
natomiast możliwości wykonywania pliku
– nie potrzebuje jej, gdyż plik /etc/passwd
nie jest programem ani skryptem. Gdyby
był, to na trzeciej pozycji, zamiast myślni-
ka, znajdowałaby się litera x (eXecute).

Analogicznie, kolejne trzy znaki okre-

ślają uprawnienia przysługujące grupie

Rysunek 4.

Do zarządzania

użytkownikami i grupami można również
wykorzystać interfejsy graficzne

Rysunek 5.

O wykrytych lukach w bezpieczeństwie możemy się również dowiedzieć

z polskich serwisów

59

bezpieczeństwo Linuksa

dla początkujących

www.lpmagazine.org

(w tym przypadku grupie root) – ma ona
tylko prawo do odczytu pliku. Takie same
prawa mają wszyscy pozostali użytkownicy,
co jest określone przez ostatnie trzy znaki.

Należy zwrócić uwagę, że w przypad-

ku katalogów prawa dostępu mają nieco
inne znaczenie: prawo odczytu pozwala
na odczyt zawartości katalogu, prawo
zapisu pozwala na tworzenie i kasowa-
nie plików w katalogu, natomiast prawo
wykonywania pozwala na wchodzenie
do katalogu (np. komendą

cd

).

Jak to wykorzystać w praktyce?

Omówmy to na przykładzie naszego
katalogu domowego. Przede wszystkim
powinniśmy zadbać, aby nikt nie miał
dostępu do naszych danych. W tym celu
zmniejszamy prawa dostępu do naszego
katalogu poleceniem

chmod go-rwx ~/

.

Składnia polecenia może wydawać się
trudna, ale szybko się do niej przyzwy-
czaimy. Po chmod (nazwa polecenia
zmieniającego uprawnienia do pliku)
mamy litery go. Oznaczają one, że zmie-
niamy uprawnienia dla grupy (g – group)
i wszystkich pozostałych użytkowników
(o – others). Następujący po niej znak
minusa oznacza, że usuwamy upraw-
nienia określone następnymi literami.
W tym przypadku usuwamy uprawnienia
do odczytu (r), zapisu (w) i wykonywania
(x). Ostatni parametr to nazwa pliku lub
katalogu, którego dotyczy polecenie.

W analogiczny sposób powinniśmy

postąpić z katalogami i plikami umiesz-
czonymi w naszym katalogu domowym.
Jeśli jesteśmy pewni, że chcemy zmienić

uprawnienia wszystkich plików i kata-
logów, możemy dokonać tego jednym
poleceniem:

chmod -R go-rwx ~/

. W tym

przypadku użyliśmy dodatkowej opcji

-R

, która sprawia, że prawa są ustawia-

ne rekursywnie dla wszystkich plików
i katalogów.

Co się jednak dzieje, gdybyśmy chcie-

li, aby inni użytkownicy mieli dostęp do
pewnych plików w naszym katalogu?
Przykładowo, chcemy stworzyć własną
stronę WWW i umieścić ją w katalogu
~/public_html/. Do tego katalogu muszą
mieć dostęp inni użytkownicy, a co naj-
mniej serwer WWW. Najlepiej ustawić
następujące prawa:

chmod u=rwx,go=x

~/public_html/

. Tym razem skorzystaliśmy

ze znaku

=

, który powoduje ustawienie

dokładnie takich praw, jakie podaliśmy.
W naszym przypadku użytkownik (u)
będzie miał wszystkie prawa do katalogu,
natomiast grupa i inni (go po przecinku)
będą mogli tylko wchodzić do katalogu.
Umieszczając w nim pliki musimy zadbać,
aby miały prawa -rwxr--r--, natomiast
podkatalogi powinny mieć prawa -rwx-
-x--x. Na koniec musimy zrobić jeszcze
jedną rzecz, a mianowicie ustawić prawo
wejścia do naszego katalogu domowego
dla innych użytkowników. Jeśli nie wyko-
namy polecenia

chmod go+x ~/

, to nie będą

oni mogli uzyskać dostępu do plików
zawartych w katalogu ~/public_html/.

Dużym ułatwieniem w zarządza-

niu prawami dostępu jest ustawienie
domyślnych praw nadawanych plikom
i katalogom. Służy do tego polecenie

umask. Jeśli wywołamy je w postaci

umask -S u=rwx,g=,o=

, to utworzone od

tego momentu katalogi będą miały prawa
-rwx------, natomiast pliki: -rw-------.
Warto to polecenie dopisać do jednego ze
skryptów uruchamianych podczas logo-
wania, np. ~/.bash_profile. Dokonujemy
tego otwierając go w naszym ulubionym
edytorze tekstu (np.

vi ~/.bash_profile

)

i dopisując na jego końcu linię o treści:

umask -S u=rwx,g=,o=

.

Grupy

Wiemy już, jak chronić pliki. Czasem
chcielibyśmy, aby określone osoby
miały do nich dostęp, a inne nie.
W poprzednim rozdziale mówiliśmy
o przyznawaniu uprawnień do plików
grupie użytkowników. Niestety, dodawa-
nie użytkowników do grup jest możliwe
tylko z uprawnieniami administratora,
co czyni tę technikę nieco niewygodną.
Niemniej, warto ją poznać.

Załóżmy, że w systemie mamy trzech

użytkowników: jacek, wacek i placek.
Użytkownicy jacek i wacek pracują
nad wspólnym projektem, dlatego też
potrzebują katalogu, w którym mogliby
je przechowywać. Postanowili, że umiesz-
czą je w podkatalogu projekt/ katalogu
domowego użytkownika jacek. Nie chcą
jednak, aby użytkownik placek mógł
tam zaglądać. Poszli do administratora
i poprosili go o założenie odpowiedniej
grupy. Administrator akurat miał chwilę
czasu, więc ze swojego konta (jak zwykle
pracował na koncie zwykłego użytkow-
nika) wydał polecenie

su

i wpisał swoje

hasło. Następnie utworzył nową grupę
o nazwie projekt:

groupadd projekt

. Jej

istnienie można sprawdzić przegląda-
jąc plik /etc/group, np. poleceniem

cat

/etc/group

. Teraz pozostało mu dopisanie

użytkowników do grupy. Dokonał tego
poleceniami:

usermod -G projekt jacek

oraz

usermod -G projekt wacek

. Polecenie

takie powoduje, że wskazany użytkownik
jest przypisywany do grup wymienionych
w opcji -G. Jeśli należał do innych, niewy-
mienionych grup, to jest z nich usuwany.
Z tego powodu lepiej wywołać polecenia

groups jacek

i

groups wacek

zarówno

przed, jak i po użyciu polecenia usermod.
Pozwoli to na sprawdzenie, do jakich grup
należą wskazani użytkownicy, oraz czy
wykonanie polecenia dało oczekiwany
przez nas skutek.

Teraz już użytkownik jacek może

w swoim katalogu utworzyć podkatalog

Rysunek 6.

Osobom mniej obeznanym z językiem angielskim z pewnością przyda się

polskie tłumaczenie wiadomości z BugTraq

60

dla początkujących

wrzesień 2004

projekt/ (poleceniem

mkdir

~jacek/

projekt/

). Następnie musi wskazać,

że katalog ten należy do niego i do
grupy projekt. Czyni to poleceniem

chown jacek:projekt ~jacek/projekt/

.

Powinien jeszcze zadbać, aby członko-
wie grupy mogli swobodnie pracować
w tym katalogu. W tym celu ustawia prawa
dostępu poleceniem

chmod ug=rwx,o-rwx

~jacek/projekt/

. Jeśli dotychczas tego nie

zrobił, musi również umożliwić wstęp
do swojego katalogu, o czym mówiliśmy
w poprzednim rozdziale (służy do tego
polecenie

chmod o+x ~jacek/

).

Czas zacząć pracę. Jeśli teraz któryś

z użytkowników jacek lub wacek utwo-
rzy nowy plik w tym katalogu (np.
poleceniem

touch plik1

), to jako grupa

właściciela pliku będzie podana (zależnie
od systemu) grupa o nazwie users lub
o nazwie takiej, jak nazwa użytkownika.
A nam przecież zależy na tym, aby jacek
i wacek mogli wspólnie korzystać z tych
plików – powinny one należeć do grupy
projekt. Dlatego przed rozpoczęciem
pracy w tym katalogu każdy z użytkow-
ników powinien wydać polecenie

newgrp

projekt

. Od tej pory tworzone przez niego

pliki będą miały ustawioną grupę właści-
ciela projekt. Warto również od razu usta-
wić opcję umask:

umask ug=rwx,o=

, dzięki

czemu właściciel i grupa będą mieli pełne
prawa do tworzonych plików, natomiast
inni (np. użytkownik placek) nie.

Specjalne prawa

Tym, co nie daje spokoju wielu admi-
nistratorów, to programy z ustawionym
bitem SUID (Set User ID) lub SGID
(Set Group ID). Ich istnienie powoduje,
że (w skrócie) program nie jest wyko-
nywany z uprawnieniami użytkownika
uruchamiającego polecenie, lecz z upraw-
nieniami (odpowiednio) właściciela pliku
lub jego grupy. Sztandarowym przykła-
dem pliku z ustawionym bitem SUID jest
program passwd. Najłatwiej to sprawdzić
wydając polecenie

ls -l `which passwd`

.

Powinniśmy uzyskać wynik zbliżony do
poniższego:

-r-s--x--x 1 root root

S

16336 lut 13 2003 /usr/bin/passwd

Należy zwrócić uwagę na literę s znaj-
dującą się na pozycji, gdzie zwykle jest
zapisywane prawo do wykonywania (x)
pliku przez użytkownika. To właśnie
ona mówi nam, że plik ma ustawiony bit

SUID. Gdyby znajdowała się na pozycji
odpowiadającej prawu wykonywania
przez grupę, to oznaczałoby to, że usta-
wiony jest bit SGID. Powód ustawienia
bitu SUID dla programu passwd jest
prozaiczny – plik /etc/passwd, w którym
przechowywane są informacje o użyt-
kownikach, jest dostępny do odczytu dla
wszystkich, ale zapisywać w nim może
tylko użytkownik root. Ponieważ każdy
z użytkowników musi mieć możliwość
zmiany swojego hasła, więc konieczne
jest wykonywanie programu passwd
z uprawnieniami administratora.

Czy takie pliki mogą nam zaszko-

dzić? Tak. Każdy plik z ustawionym
bitem SUID to potencjalne zagrożenie.
Jeśli będzie w nim jakiś błąd, to może
to doprowadzić do tego, że niegrzeczny
użytkownik uzyska na stałe uprawnienia
właściciela pliku. Niemniej, część plików
z ustawionymi bitami SUID lub SGID jest
konieczna do funkcjonowania systemu.
W przypadku innych (np. polecenie
mount) jest to raczej kwestia wygody
w używaniu systemu.

Listę znajdujących się w systemie

plików z ustawionymi wspomnianymi
bitami możemy uzyskać wydając jako
administrator następujące polecenie:

find

/ -perm +6000 > ~/spis_suidy_sgidy.txt

Po dłuższym oczekiwaniu (polece-

nie to przeszukuje cały system plików
w poszukiwaniu plików z ustawio-
nym bitem SUID lub SGID), w pliku
~/spis_suidy_sgidy.txt zostaną umiesz-
czone nazwy plików spełniających ten
warunek. Można się zdziwić ich liczbą
– oprócz narzędzi administracyjnych,
z bitów SUID często korzystają gry.
Podczas administracji systemem należy
zwrócić baczną uwagę na to, czy pliki
te nie zostały przez kogoś podmienione.
Taka podmiana może świadczyć o sku-
tecznym włamaniu na serwer. Możemy
też, w miarę możliwości, pozdejmować
bity SUID i SGID. Rozdział Polecenie
sudo zawiera opis jednej z metod zastą-
pienia funkcjonalności bitów SUID.
Samo zdejmowanie bitów dokonujemy
znanym nam już poleceniem chmod
(np. dla przypadku programu /bin/
mount):

chmod u-s /bin/mount

Analogicznie, w przypadku bitu SGID,
zamiast u-s stosujemy g-s. Należy pamię-
tać, że takie zmiany mogą znacząco

ograniczyć wygodę korzystania z sys-
temu – może się zdarzyć, że większość
funkcji będzie można wykonać tylko
z uprawnieniami użytkownika root.

Praca z uprawnieniami

administratora

Podczas instalacji dystrybucji Linuksa
mamy możliwość ustalenia hasła admi-
nistratora (użytkownika root) oraz utwo-
rzenia jednego lub więcej kont zwykłych
użytkowników. Zawsze należy pamiętać,
aby unikać pracy z uprawnieniami admini-
stratora. Jeśli jest to możliwe, powinniśmy
pracować na koncie zwykłego użytkow-
nika, a konta root (lub innego uprzywile-
jowanego) używać tylko w wyjątkowych
przypadkach. Takie przypadki to insta-
lacja oprogramowania lub dodawanie
nowych użytkowników. Zasady tej należy
przestrzegać nawet wtedy, gdy jesteśmy
jedynymi użytkownikami komputera.
Powód jest prosty – konto administrato-
ra daje nieograniczone możliwości, więc
jedna nieprzemyślana komenda (lub
polecenie wydane w złym katalogu) może
spowodować bardzo duże straty, z utratą
wszystkich danych włącznie.

Nie musimy logować się na konto

root, gdyż możemy uzyskać jego przy-
wileje korzystając z polecenia

su

. Po jego

wydaniu zostaniemy zapytani o hasło
użytkownika root. Jeśli podamy je pra-
widłowo, to od tej chwili aż do wydania
polecenia

exit

pracujemy z uprawnienia-

mi tego użytkownika. Jeśli zależy nam
na tym, aby nie tylko mieć odpowiednie
przywileje, ale również dostęp do zmien-
nych środowiskowych wykorzystywa-
nych przez administratora, to musimy
jako argument polecenia wpisać myślnik:

su -

. Dzięki temu możemy również korzy-

stać ze zdefiniowanych przez tego użyt-
kownika aliasów i ścieżek dostępu.

Poleceniem su możemy nie tylko stać

się administratorem, ale również dowol-
nym użytkownikiem – wystarczy podać

Rysunek 7.

Nawet serwery NASA nie były

w stanie oprzeć się włamywaczom

61

bezpieczeństwo Linuksa

dla początkujących

www.lpmagazine.org

jego nazwę jako argument i znać odpo-
wiednie hasło. Przykładowo, jeśli znamy
hasło użytkownika gerard w naszym sys-
temie, to możemy użyć odpowiednio pole-
ceń

su gerard

i

su - gerard

. Jeśli polecenie

su wywołujemy z konta administratora, to
nawet nie musimy podawać hasła użyt-
kownika. Jest to kolejny przykład tego, jak
potężny jest administrator systemu.

Jeśli chcemy wykonać tylko pojedyn-

cze polecenie z uprawnieniami innego
użytkownika, możemy podać je od razu
jako argument polecenia su. Przykładowo,
jeśli chcemy sprawdzić, jakie połączenia
są nawiązane z i do naszego komputera,
możemy wydać polecenie

netstat -ntp

.

Polecenie to wyświetla również nazwę
programu, który odpowiada za dane
połączenie. Nie zobaczymy jednak nazw
programów, które do nas nie należą.
W takim przypadku można skorzystać
z su wydając polecenie:

su -c "netstat

-ntp"

. Po jego wykonaniu od razu wróci-

my do naszej powłoki.

Polecenie sudo

Polecenie su jest wygodne, ale do
korzystania z niego należy znać hasło
administratora. Wiemy już, że uzyska-
nie dostępu do konta użytkownika
root jest praktycznie równoznaczne
z przejęciem kontroli nad całym syste-
mem. Musimy bardzo uważać, komu
udzielamy takiego przywileju. Jeśli
chcemy konkretnym osobom pozwolić
na wykonywanie niektórych poleceń
z uprawnieniami administratora, możemy
to zrobić w inny, bezpieczniejszy sposób.
Pomoże nam w tym polecenie sudo i jego
plik konfiguracyjny /etc/sudoers.

Załóżmy, że użytkownikowi jacek

zechcemy dać możliwość montowania
i odmontowywania napędu CD-ROM,
natomiast użytkownik wacek, jako prawa
ręka administratora, będzie miał oprócz
tego dostęp do szeregu poleceń, takich
jak ifconfig i netstat. Ostatni z użytkow-
ników, placek, to alter ego administratora
– chcemy, aby miał możliwość wykony-
wania wszystkich komend.

W tym celu musimy zmodyfikować

plik /etc/sudoers. Najbezpieczniej jest
dokonać tego z pomocą polecenia

visudo

(należy je wywołać z uprawnieniami
administratora), które zadba, aby podczas
edycji pliku nie doszło do konfliktów
(gdyby ktoś inny próbował akurat edyto-
wać ten plik). W tym pliku umieszczamy
następujące linie:

User_Alias USERS = jacek, wacek
Cmnd_Alias NARZEDZIA = /bin/mkdir,

S

/bin/cp, /bin/netstat,

S

/sbin/ifconfig, /usr/bin/make

Pierwsza z tych linii tworzy alias USERS,
obejmujący użytkowników jacek i wacek,
natomiast druga tworzy alias NARZEDZIA,
obejmujący szereg komend, które mają być
dostępne dla użytkownika wacek. Następ-
nie dodajemy trzy linie odpowiadające
za właściwe przypisanie użytkownikom
komend, które mogą wykonywać:

placek ALL=(ALL) ALL
USERS localhost=/bin/mount

S

/mnt/cdrom,/bin/umount /mnt/cdrom
wacek ALL=NARZEDZIA

Wygląda skomplikowanie? Zaraz wszyst-
ko wyjaśnimy. Najpierw pierwsza linia.
Mówi ona, że użytkownik placek może na
dowolnej maszynie (pierwsze słowo ALL)
wykonywać z uprawnieniami dowolnego
użytkownika (słowo ALL w nawiasie)
wszelkie komendy (ostatnie słowo ALL).
Ze swoich uprawnień korzysta poprze-
dzając komendę poleceniem

sudo

. Przy-

kładowo, wykonanie przez użytkownika
placek polecenia

id

powinno dać wynik

podobny do tego:

uid=508(placek) gid=510(placek)

S

grupy=510(placek)

a polecenie

sudo id

spowoduje, że zosta-

niemy zapytani o hasło. Po podaniu hasła
użytkownika placek (tak, hasła użytkow-
nika, a nie administratora!) powinniśmy
zobaczyć mniej więcej taki wynik:

uid=0(root) gid=0(root) grupy=0(root),

S

1(bin),2(daemon),3(sys),4(adm),

S

6(disk),10(wheel)

Jak widać, rzeczywiście uzyskujemy
przywileje administratora. W podobny
sposób działają pozostałe linie, które
dopisaliśmy do pliku /etc/sudoers.
W ich przypadku pominęliśmy określenie,
z jakimi prawami mogą być wykonywane
polecenia, więc będą one wykonywane
z prawami użytkownika root.

Jeśli chcemy, aby użytkownik mógł

wykonywać określone polecenia bez
konieczności podawania hasła po użyciu
sudo, to w pliku /etc/sudoers należy
w jego linii dodać opcję NOPASSWD.
Przykładowo, dla użytkownika wacek

w naszym pliku linia wyglądałaby tak
(pamiętajmy, edytujemy poleceniem

visudo

!):

wacek ALL=NOPASSWD:NARZEDZIA

Odpowiednie ustawienie pliku /etc/
sudoers pozwala nam na zdjęcie niezbyt
bezpiecznych bitów suid z niektórych
programów (w tym przypadku możemy
zdjąć je z programów /bin/mount i /bin/
umount – o ile tylko nie chcemy, aby inni
użytkownicy też mieli do nich dostęp).
Zapewnia to również większą kontrolę
nad wykorzystywaniem uprawnień przez
użytkowników, gdyż wszystkie próby
użycia polecenia sudo są zapisywane
w dzienniku systemowym.

Zakończenie

Opisane w tym artykule metody
pozwalają na podstawowe zabezpie-
czenie systemu. Pracując z komputerem
należy zdawać sobie sprawę, że nigdy
nie będziemy mogli powiedzieć – "mój
system jest bezpieczny i nikt się do niego
nie włamie". Nie ma też sensu popadać
w paranoję. To, jakich metod zabezpie-
czenia użyjemy, musi przede wszystkim
zależeć od wagi danych, jakie chcemy
chronić. Zupełnie inne zabezpieczenia
będą wymagane w przypadku odcię-
tego od Internetu komputera biurowe-
go, a inne w przypadku serwera sieci
osiedlowej czy głównego komputera
systemu bankowego. Może się zdarzyć,
że nawet nie będziemy chcieli wykorzy-
stać wszystkich z opisanych w artykule
technik. Może też być tak, że przedsta-
wione techniki nie będą wystarczające
i będziemy musieli sięgnąć po bardziej
zaawansowane narzędzia. Gorąco zachę-
cam do bliższego zapoznania się z tema-
tem bezpieczeństwa, gdyż aby dobrze
zabezpieczyć system, potrzebny jest
administrator świadomy zagrożeń.

W Internecie:

• Definicja hasła Leet w Wikipedii:
http://en.wikipedia.org/wiki/Leet
• Definicja hasła Leet w UrbanDictionary:
http://www.urbandictionary.com/

define.php?term=1337

• Strona magazynu Hakin9:

http://www.haking.pl/

• Serwis Hacking.pl:
http://www.hacking.pl/