plik

dla początkujących

wrzesień 2004

Bezpieczeństwo

Linuksa

Piotr Machej

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:

autorzy@lpmagazine.org

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ł

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

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

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

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

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

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ą

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

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

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

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

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

. 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

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

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,

/bin/cp, /bin/netstat,

/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

/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

powinno dać wynik

podobny do tego:

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

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),

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

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/