![[OpenBSD]](../../images/smalltitle.gif){kind=small}
[Spis treści] [Sekcja 9 - Migracja do OpenBSD] [Sekcja 11 - X Window System]
Użytkownicy posiadający już konto w systemie muszą zostać dopisani do grupy "wheel" ręcznie. Robi się tak dla zwiększenia bezpieczeństwa, i należy zachować ostrożność z tym komu daje się taki dostęp. W systemie OpenBSD tylko użytkownicy należący do grupy wheel mają prawo używać polecenia su(1) w celu uzyskania praw roota. Użytkownicy, którzy nie należą do grupy "wheel", nie mogą korzystać z polecenia su(1). Istniejącego użytkownika można dodać do grupy wheel odpowiednio redagując plik /etc/group. Zamieszczony poniżej wpis z tego pliku uwzględnia użytkownika ericj (oraz roota) jako członka grupy "wheel".
Dodając nowego użytkownika za pomocą polecenia adduser(8), można od razu dodać go do grupy wheel po prostu wpisując "wheel" w odpowiedzi na pytanie "Invite user into other groups:". W ten sposób użytkownik zostanie automatycznie dodany do grupy "wheel" w pliku /etc/group:
wheel:*:0:root,ericj
Często chcemy zwiększyć uprawnienia danego użytkownika, ale w sposób kontrolowany, nie umieszczając go w grupie "wheel". Dokładnie w tym celu został stworzony program sudo(8).
W celu skopiowania systemu plików można skorzystać z programów dump(8) i restore(8). Na przykład, aby skopiować zawartość katalogu SRC do katalogu DST wystarczy wydać następujące polecenie:
# cd /SRC; dump 0f - . | (cd /DST; restore -rf - )
Dump został zaprojektowany tak, aby spełniać różnorodne wymagania dotyczące wykonywania kopii zapasowych i może być zbyt skomplikowanym narzędziem, jeżeli chcemy skopiować tylko część (albo nawet całość) systemu plików. Dla prostszych zastosowań szybszy może okazać się program tar(1). Składnia tego polecenia jest bardzo podobna jak w poprzednim przykładzie:
# cd /SRC; tar cf - . | (cd /DST; tar xpf - )
OpenBSD uruchamia demony podczas startu sytemu poprzez rc(8). Korzysta on przy tym z kilku pomocniczych skryptów i plików konfiguracyjnych:
Najważniejszymi plikami, na których powinien skupić się administrator systemu są /etc/rc.conf (albo /etc/rc.conf.local), /etc/rc.local oraz /etc/rc.shutdown. Na początku opiszmy jednak poszczególne czynności wykonywane przez skrypt rc(8):
Po załadowaniu jądra systemu, rozpoczyna pracę /etc/rc:
Większość dostarczonych z systemem OpenBSD demonów i usług można uruchomić podczas startu systemu przez prostą modyfikację pliku konfiguracyjnego /etc/rc.conf. Na początek przyjrzyjmy się domyślnej zawartości pliku /etc/rc.conf. Znajdują się tam linie podobne do tej:
ftpd_flags=NO # for non-inetd use: ftpd_flags="-D"
Zamieszczony powyżej wpis oznacza, ze ftpd nie powinien być uruchamiany przy starcie systemu (a przynajmniej nie przez rc(8), przeczytaj dział Konfigurowanie anonimowego serwera FTP, by dowiedzieć się więcej na ten temat). Tak czy inaczej, każdy wpis zawiera także komentarz opisujący flagi (opcje) NORMALNEJ pracy demona lub usługi. Nie oznacza to, że trzeba uruchamiać tego czy innego demona czy usługę z dokładnie tymi samymi ustawieniami. Zawsze można skorzystać z podręcznika systemowego, aby sprawdzić, jakiej opcji użyć w celu osiągnięcia zamierzonego efektu. Na przykład, poniższa linia pokazuje domyślne ustawienie demona httpd(8).
httpd_flags=NO # for normal use: "" (or "-DSSL" after reading ssl(8))
Jak widać, w tym przypadku httpd może być uruchomiony bez jakichkolwiek opcji. A zatem potrzebny byłby tylko taki wpis: httpd_flags="". W przypadku, gdy chcielibyśmy uruchomić httpd z obsługą ssl (patrz SSL FAQ lub ssl(8)) należało by napisać: httpd_flags="-DSSL".
Dobrym zwyczajem jest w ogóle nie zmieniać /etc/rc.conf. Zamiast tego można utworzyć plik /etc/rc.conf.local i skopiować do niego te linie, które mamy zamiar zmienić w /etc/rc.conf, a potem dostosować je do własnych potrzeb. Znacznie ułatwia to proces aktualizacji -- wszystkie zmiany są zapisane bowiem w tym jednym pliku.
W przypadku demonów lokalnych, czyli doinstalowanych z portów, pakietów czy w dowolny inny sposób, należy korzystać z pliku /etc/rc.local. Na przykład, jeżeli zainstalowaliśmy demona, który znajduje się w /usr/local/sbin/daemonx i chcemy, aby uruchamiał się on przy starcie systemu, to do pliku /etc/rc.local powinniśmy dodać następujący wpis:
if [ -x /usr/local/sbin/daemonx ]; then
echo -n ' daemonx'; /usr/local/sbin/daemonx
fi
(Jeżeli demon nie przechodzi automatycznie do pracy w tle, należy dodać znak "&" po "/usr/local/sbin/daemonx".)
Od tej pory demon będzie uruchamiany zawsze podczas startu systemu. W trakcie tej operacji można zobaczyć komunikaty o błędach (jeżeli się takowe pojawią). Natomiast komunikat bezbłędnego uruchomienia demona będzie wyglądał mniej więcej tak:
Starting local daemons: daemonx.
/etc/rc.shutdown to skrypt, który jest uruchamiany przed zatrzymaniem pracy systemu. Wszystkie polecenia, które mają być wykonane przed zamknięciem OpenBSD powinny być zawarte w tym pliku. Jeżeli wykorzystywane jest zarządzanie energią (apm), można także ustawić "powerdown=YES", co jest odpowiednikiem komendy "shutdown -p".
Proszę spróbować tego:
# grep relay-domains /etc/mail/sendmail.cf
Wynik może wyglądać tak:
FR-o /etc/mail/relay-domains
Jeżeli ten plik nie istnieje, należy go utworzyć i wpisać do niego nazwy hostów, którym zezwala się na przesyłanie poczty przez swój serwer stosując następującą składnię:
.domain.com #Zezwalaj na przekazywanie poczty z/do każdego hosta w domain.com
sub.domain.com #Zezwalaj na przekazywanie poczty z/do domeny sub.domain.com oraz z każdego hosta w tej domenie
10.2 #Zezwalaj na przekazywanie poczty ze wszystkich hostów o adresach IP 10.2.*.*
Na koniec należy wysłać procesowi sendmail sygnał 'HangUP' (jest to sygnał, który zmusza większość demonów do ponownego odczytania swoich plików konfiguracyjnych):
# kill -HUP `head -1 /var/run/sendmail.pid`
Większość problemów związanych z protokołem POP ma swoje źródła w plikach tymczasowych oraz plikach blokady. Jeżeli serwer POP wysyła komunikat o błędzie podobny do tego:
-ERR Couldn't open temporary file, do you own it?
to spróbujmy ustawić prawa do plików w następujący sposób:
prawa w /var
drwxrwxr-x 2 bin mail 512 May 26 20:08 mail
prawa w /var/mail
-rw------- 1 username username 0 May 26 20:08 username
Należy upewnić się, że dany użytkownik jest właścicielem swojego pliku poczty w katalogu /var/mail (tzn. /var/mail/joe powinien należeć do joe itd.). Teoretycznie nie ma powodu, dla którego miało by być inaczej, ale jeżeli jest, to tu może tkwić problem!
Oczywiście, przyznanie praw do pisania do /var/mail grupie mail może być przyczyną wielu tajemniczych, nie do końca znanych problemów związanych z bezpieczeństwem. Istnieje duże prawdopodobieństwo, że nigdy nie będzie z tym kłopotów, jeśli jednak serwer stanowi znaczący punkt na mapie Internetu (np. należy do ISP) mogą się takowe pojawić! W kolekcji portów można znaleźć kilka różnych serwerów POP, zalecane jest jednak używanie popa3d, który jest dostępny już w podstawowej instalacji OpenBSD. Może się też zdarzyć, że zostaną określone nieodpowiednie opcje konfiguracji serwera POP (np. blokada plików z kropką). Być może wystarczy jedynie zmienić katalog, który jest blokowany przez serwer (chociaż wtedy blokowanie miałoby sens tylko dla demona POP).
Uwaga: Proszę zwrócić uwagę, że OpenBSD nie tworzy automatycznie grupy "mail". Jeżeli zajdzie taka potrzeba, należy utworzyć ją własnoręcznie dodając do pliku /etc/group. Wpis w stylu:
mail:*:6:
Domyślnie Sendmail korzysta z DNS w celu uzyskania informacji o adresach, ignorując plik /etc/hosts. Zachowanie to można zmienić korzystając z pliku /etc/mail/service.switch.
Jeżeli chcemy aby Sendmail przed wysłaniem zapytania do DNS odczytywał plik /etc/hosts, należy utworzyć plik /etc/mail/service.switch, zawierający następujący wpis:
hosts files dns
Jeżeli zaś chcemy, by Sendmail odczytywał TYLKO plik /etc/hosts, użyjemy następującego wpisu:
hosts files
Wysyłamy teraz procesowi Sendmail sygnał HUP:
# kill -HUP `head -1 /var/run/sendmail.pid`
aby zmiany, które wykonaliśmy, zostały uwzględnione.
OpenBSD jest dostarczany z gotowym do użytku serwerem httpd wyposażonym w obsługę SSL oraz biblioteki RSA. Aby móc korzystać z SSL w httpd(8), należy najpierw utworzyć certyfikat. Będzie on przechowywany w /etc/ssl/, a odpowiadający mu klucz w /etc/ssl/private/. Opisane poniżej kroki zostały częściowo zaczerpnięte ze strony podręcznika systemowego ssl(8). Tam też znajdują się dalsze informacje. Ta sekcja FAQ jedynie zarysowuje sposób tworzenia certyfikatów RSA dla serwerów WWW, pomija zaś certyfikaty DSA. Aby dowiedzieć się więcej na ten temat, przeczytaj stronę podręcznika ssl(8).
Na początku należy utworzyć klucz oraz certyfikat serwera korzystając z OpenSSL:
# openssl genrsa -out /etc/ssl/private/server.key 1024
Jeżeli klucz ma zostać zaszyfrowany hasłem, które trzeba będzie wpisać przy uruchamianiu serwerów, zamiast poprzedniego polecenia używamy tego:
# openssl genrsa -des3 -out /etc/ssl/private/server.key 1024
Kolejnym krokiem jest wygenerowanie prośby o podpis certyfikatu (ang. Certificate Signing Request), która jest wykorzystywana przez Instytucję Uwierzytelniającą (ang. Certifying Authority) do podpisania certyfikatu. Robi się to za pomocą polecenia:
# openssl req -new -key /etc/ssl/private/server.key -out /etc/ssl/private/server.csr
Plik server.csr może zostać następnie przekazany Instytucji Uwierzytelniającej, która podpisze klucz. Jedną z takich instytucji jest Thawte Certification, której strona znajduje się pod adresem http://www.thawte.com/.
Jeżeli nie stać Cię na certyfikat Thawte, albo chcesz sam podpisać swój certyfikat, możesz to zrobić w następujący sposób:
# openssl x509 -req -days 365 -in /etc/ssl/private/server.csr \
-signkey /etc/ssl/private/server.key -out /etc/ssl/server.crt
Po wygenerowaniu plików /etc/ssl/server.crt oraz /etc/ssl/private/server.key, bez przeszkód będzie można uruchomić httpd(8) z opcja -DSSL (patrz sekcja nt. rc(8) w tym FAQ), co zezwala na przeprowadzanie transakcji na porcie 443.
Bezpośrednie modyfikacje pliku /etc/passwd zostaną zignorowane. OpenBSD generuje /etc/passwd dynamicznie za pomocą pwd_mkdb(8). Głównym plikiem haseł w systemie OpenBSD jest /etc/master.passwd. Cytując za pwd_mkdb(8):
PLIKI
/etc/master.passwd obecnie obowiązujący plik haseł
/etc/passwd plik haseł w formacie 6-tej Edycji
/etc/pwd.db niezabezpieczony plik bazy haseł
/etc/pwd.db.tmp plik tymczasowy
/etc/spwd.db zabezpieczony plik bazy haseł
/etc/spwd.db.tmp plik tymczasowy
W tradycyjnym pliku haseł w systemach Unix, takim jak /etc/passwd, cała jego zawartość, włączając w to zaszyfrowane hasło użytkownika, jest dostępna dla każdego, kto posiada konto w systemie (plik ten jest głównym celem ataków programów takich jak Crack). 4.4BSD wprowadził plik master.passwd, który posiada rozszerzony format (z dodatkowymi opcjami w stosunku do /etc/passwd) i tylko root posiada prawo do odczytu tego pliku. W celu przyspieszenia dostępu do danych, wywołania biblioteczne zazwyczaj odczytują pliki /etc/pwd.db i /etc/spwd.db (zamiast /etc/master.passwd).
OpenBSD posiada narzędzie, które służy do modyfikacji pliku haseł. Nazywa się ono vipw(8). Do modyfikacji /etc/master.passwd vipw korzysta z vi (albo Twojego ulubionego edytora zdefiniowanego za pomocą zmiennej środowiskowej $EDITOR). Po dokonaniu zmian vipw utworzy na nowo /etc/passwd, /etc/pwd.db oraz /etc/spwd.db tak, aby uwzględniały one wprowadzone zmiany. vipw zakłada także blokady na te pliki tak, by dwie osoby nie modyfikowały ich naraz.
OpenBSD posiada dwa polecenia pozwalające w łatwy sposób dodać użytkownika do systemu:
Można także dodawać użytkowników ręcznie za pomocą vipw(8), ale zwykle jest to bardziej skomplikowane.Najprostszym sposobem na dodanie użytkownika w OpenBSD jest użycie skryptu adduser(8). Można go skonfigurować redagując plik /etc/adduser.conf. adduser(8) sprawdza spójność plików /etc/passwd, /etc/group oraz baz danych powłoki. Tworzy także niezbędne wpisy oraz katalog $HOME. Potrafi nawet wysłać użytkownikowi wiadomość powitalną. Oto przykład dodania użytkownika testuser do systemu. Jego katalog $HOME (domowy) będzie umieszczony w /home/testuser. Przydzielimy go do grupy guest, oraz ustawimy domyślną powłokę na /bin/ksh.
# adduser
Use option ``-silent'' if you don't want to see all warnings and questions.
Reading /etc/shells
Reading /etc/login.conf
Check /etc/master.passwd
Check /etc/group
Ok, let's go.
Don't worry about mistakes. I will give you the chance later to correct any input.
Enter username []: testuser
Enter full name []: Test FAQ User
Enter shell csh ksh nologin sh [sh]: ksh
Uid [1002]: Enter
Login group testuser [testuser]: guest
Login group is `guest''. Invite testuser into other groups: guest no
[no]: no
Login class auth-defaults auth-ftp-defaults daemon default staff
[default]: Enter
Enter password []: Type password, then Enter
Enter password again []: Type password, then Enter
Name: testuser
Password: ****
Fullname: Test FAQ User
Uid: 1002
Gid: 31 (guest)
Groups: guest
Login Class: default
HOME: /home/testuser
Shell: /bin/ksh
OK? (y/n) [y]: y
Added user ``testuser''
Copy files from /etc/skel to /home/testuser
Add another user? (y/n) [y]: n
Goodbye!
Do skasowania użytkownika z systemu służy polecenie rmuser(8). Usunie ono wszelkie ślady bytności użytkownika w systemie - wszystkie jego wpisy w crontab(1), katalog domowy (jeśli jego właścicielem jest użytkownik), jego pocztę. Oczywiście, również wpisy w /etc/passwd oraz /etc/group zostaną usunięte. Oto przykład usunięcia użytkownika dodanego przez nas przed chwilą. Proszę zauważyć, że rmuser(8) pyta się o login użytkownika oraz czy usuwać jego katalog domowy.
# rmuser
Enter login name for user to remove: testuser
Matching password entry:
testuser:$2a$07$ZWnBOsbqMJ.ducQBfsTKUe3PL97Ve1AHWJ0A4uLamniLNXLeYrEie:1002
:31::0:0:Test FAQ User:/home/testuser:/bin/ksh
Is this the entry you wish to remove? y
Remove user's home directory (/home/testuser)? y
Updating password file, updating databases, done.
Updating group file: done.
Removing user's home directory (/home/testuser): done.
Niżej opisane narzędzia są mniej interaktywne niż polecenie adduser(8), co ułatwia korzystanie z nich w skryptach powłoki.
Na narzędzia te składają się następujące programy:
Ponieważ program user(8) nie jest interaktywny, najłatwiejszym sposobem dodania użytkownika jest użycie komendy adduser(8). Polecenie /usr/sbin/user to tylko fronton (ang. front-end) poleceń /usr/sbin/user*. Dlatego też można używać zarówno user add jak i useradd. Wybór należy do Ciebie - składnia komend pozostaje w obu przypadkach identyczna.
W kolejnym przykładzie dodamy tego samego użytkownika z takimi samymi ustawieniami jak w przykładzie wyżej prezentującym polecenie adduser. useradd(8) będzie dużo prostszy w obsłudze, jeśli najpierw zaznajomimy się z domyślnymi ustawieniami. Znajdują się one w pliku /etc/usermgmt.conf, zaś wyświetlić je można pisząc:
$ user add -D
group users
base_dir /home
skel_dir /etc/skel
shell /bin/csh
inactive 0
expire Null (unset)
range 1000..60000
Powyższe ustawienia, jeśli nie zostaną zmienione, będą wykorzystane przy dodawaniu użytkownika z pomocą poleceń user add/useradd. Żeby było ciekawiej, w naszym przykładzie umieścimy użytkownika w grupie guest, nie w users. Ostatnią przeszkodą, o jakiej musimy pamiętać jest fakt, że hasło, które przekażemy programowi user add/useradd musi być już zaszyfrowane. Zatem najpierw należy użyć programu encrypt(1), służącego do szyfrowania haseł. OpenBSD używa do kodowania haseł sześciorundowego algorytmu Blowfish. Oto przykład pokazujący jak można otrzymać zaszyfrowane hasło gotowe do wykorzystania w programie useradd(8):
$ encrypt -p -b 6
Enter string:
$2a$06$YOdOZM3.4m6MObBXjeZtBOWArqC2.uRJZXUkOghbieIvSWXVJRzlq
Mamy już zakodowane hasło, możemy więc dodać użytkownika:
# user add -p '$2a$06$YOdOZM3.4m6MObBXjeZtBOWArqC2.uRJZXUkOghbieIvSWXVJRzlq' -u 1002 \
-s /bin/ksh -c "Test FAQ User" -m -g guest testuser
Uwaga: Hasło należy umieścić w parze apostrofów (' '), a nie cudzysłowów (" "); w przeciwnym razie zostanie ono zinterpretowane przez powłokę przed wysłaniem do user(8). Opcja -m jest konieczna by system utworzył katalog domowy użytkownika i skopiował do niego pliki z /etc/skel.
By sprawdzić, czy użytkownik został poprawnie dodany do systemu, można posłużyć się wieloma narzędziami. Zamieszczone poniżej przykłady pokazują jak szybko upewnić się, że wszystko wykonane zostało poprawnie.
$ ls -la /home
total 14
drwxr-xr-x 5 root wheel 512 May 12 14:29 .
drwxr-xr-x 15 root wheel 512 Apr 25 20:52 ..
drwxr-xr-x 24 ericj wheel 2560 May 12 13:38 ericj
drwxr-xr-x 2 testuser guest 512 May 12 14:28 testuser
$ id testuser
uid=1002(testuser) gid=31(guest) groups=31(guest)
$ finger testuser
Login: testuser Name: Test FAQ User
Directory: /home/testuser Shell: /bin/ksh
Last login Sat Apr 22 16:05 (EDT) on ttyC2
No Mail.
No Plan.
Dodatkowo, user(8) dostarcza własne narzędzie do podglądu parametrów użytkownika o nazwie userinfo(8).
$ userinfo testuser
login testuser
passwd *
uid 1002
groups guest
change Wed Dec 31 19:00:00 1969
class
gecos Test FAQ User
dir /home/testuser
shell /bin/ksh
expire Wed Dec 31 19:00:00 1969
W celu usunięcia użytkownika za pomocą polecenia z zestawu user(8), należy skorzystać z komendy userdel(8). Jest to bardzo proste, a jednocześnie przydatne polecenie. By usunąć użytkownika dodanego w poprzednim wystarczy napisać:
# userdel -r testuser
Proszę zwrócić uwagę na opcję -r, która każe systemowi usunąć nie tylko samego użytkownika, ale też jego katalog domowy. Alternatywnie, zamiast -r można użyć flagi -p, która tylko blokuje konto użytkownika, bez usuwania jakichkolwiek informacji o nim.
Istnieje na to kilka sposobów. Bardzo powszechne jest rozwiązanie polegające na dodaniu pliku "/usr/bin/false" do "/etc/shells". Jeżeli następnie domyślna powłoka użytkownika ustawiona zostanie właśnie na "/usr/bin/false", to nie będzie on mógł zalogować się do systemu w trybie interaktywnym. Będzie mógł natomiast zalogować się przez FTP. Możesz także, korzystając poprzez ftpchroot ograniczyć dostęp użytkowników ftp tylko do ich katalogów domowych.
Kwoty wykorzystywane są do ograniczania przestrzeni dyskowej dostępnej użytkownikom. Jest to szczególnie pomocne, gdy zasoby dyskowe są mocno ograniczone. Limity można narzucić zarówno pojedynczemu użytkownikowi jak i całej grupie.
Pierwszym krokiem do ustawienia kwot jest sprawdzenie czy opcja "option QUOTA" została włączona w twojej konfiguracji kernela. Jest ona domyślnie ustawiona w jądrze GENERIC. Następnie należy wskazać w pliku /etc/fstab, systemy plików na których chcesz włączyć kwoty. Do tego służą słowa kluczowe userquota oraz groupquota. W korzeniu wybranych systemów plików domyślnie tworzone są pliki quota.user oraz quota.group, które zawierają niezbędne informacje o kwotach. Nie ma przeszkód, by pliki te znajdowały się w dowolnym innym katalogu lub nawet inaczej się nazywały. Robi się to dodając w pliku /etc/fstab; przykładowo "userquota=/var/quotas/quota.user". Poniżej znajduje się przykład pliku /etc/fstab z jednym systemem plików z włączonymi kwotami i plikiem kwot nie niestandardowej lokalizacji:
/dev/wd0a / ffs rw,userquota=/var/quotas/quota.user 1 1
Teraz można już przyznawać użytkownikom kwoty. Służy do tego narzędzie o nazwie edquota(8). Wpisując "edquota <user>" do konfigurowania kwot użyty zostanie edytor vi(1), chyba że za pomocą zmiennej środowiskowej EDITOR ustawimy jako domyślny inny edytor. Dla przykładu:
# edquota ericj
spowoduje wyświetlenie mniej więcej takiej informacji:
Quotas for user ericj:
/: blocks in use: 62, limits (soft = 0, hard = 0)
inodes in use: 25, limits (soft = 0, hard = 0)
Aby wprowadzić ograniczenia wystarczy zredagować ten plik. Np.:
Quotas for user ericj:
/: blocks in use: 62, limits (soft = 1000, hard = 1050)
inodes in use: 25, limits (soft = 0, hard = 0)
W powyższym przykładzie ustawiliśmy limit miękki (ang. soft limit) na 1000 bloków, zaś limit twardy (ang. hard limit) na 1050 bloków. Różnica między limitem miękkim a twardym polega na tym, że ten pierwszy może zostać na jakiś czas przekroczony. Czas ten ustala się stosując opcję -t w poleceniu edquota(8). Gdy okres ten jednak minie, limit miękki jest traktowany identycznie jak limit twardy, co powoduje częste błędy alokacji.
Po ustawieniu kwot należy je jeszcze włączyć. Robi się to za pomocą polecenia quotaon(8). Przykład:
# quotaon -a
Spowoduje to wczytanie /etc/fstab i włączenie kwot na wybranych systemach plików. Do wyświetlania kwot służy polecenie quota(1). Wywołanie "quota <user>" dostarczy informacji na temat kwot wybranego użytkownika. Wywołanie komendy quota(1) bez dodatkowych argumentów zwróci nasze własne statystyki. Oto przykład:
# quota ericj
Spowoduje to wypisanie informacji podobnej do tej:
Disk quotas for user ericj (uid 1001):
Filesystem blocks quota limit grace files quota limit grace
/ 62 1000 1050 27 0 0
Kwoty ustawione w /etc/fstab włączają się domyślnie podczas startu systemu. Natomiast wyłączyć można je pisząc:
# quotaoff -a
KerberosV jest domyślnie preinstalowanym składnikiem systemu.
Więcej informacji o KerberosV można uzyskać za pomocą polecenia:
# info heimdal
Dzięki anonimowemu FTP nawet użytkownicy nie posiadający konta mogą mieć dostęp do naszych plików. Poniżej podpowiadamy jak skonfigurować anonimowy serwer FTP.
Najpierw należy stworzyć w systemie konto o nazwie ftp. Hasło do tego konta nie powinno być wartościowe, tzn. nie powinniśmy używać go nigdzie indziej. W naszym przykładzie dla tego konta ustalimy katalog domowy /home/ftp, ale można użyć tez innego katalogu. Gdy ktoś zaloguje się na nasz anonimowy serwer FTP, demon ftp zmieni środowisko za pomocą polecenia chroot, na katalog domowy użytkownika ftp. Więcej na ten temat można dowiedzieć się na stronach podręcznika systemowego ftpd(8) oraz chroot(2). Oto przykład dodania użytkownika o nazwie ftp. Używamy tutaj polecenia: adduser(8). Należy także dodać linię /usr/bin/false do pliku /etc/shells. Jest to "powłoka", którą nadajemy użytkownikowi ftp. Dzięki temu nie będą się oni mogli zalogować, nawet jeśli ustawimy im puste hasło.
echo /usr/bin/false >> /etc/shells
# adduser
Use option `-silent'' if you don't want to see all warnings and questions.
Reading /etc/shells
Reading /etc/login.conf
Check /etc/master.passwd
Check /etc/group
Ok, let's go.
Don't worry about mistakes. I will give you the chance later to correct any input.
Enter username []: ftp
Enter full name []: anonymous ftp
Enter shell csh false ksh nologin sh tcsh zsh [sh]: false
Uid [1002]: Enter
Login group ftp [ftp]: Enter
Login group is `ftp''. Invite ftp into other groups: guest no
[no]: no
Login class auth-defaults auth-ftp-defaults daemon default staff
[default]: Enter
Enter password []: Enter
Set the password so that user cannot logon? (y/n) [n]: y
Name: ftp
Password: ****
Fullname: anonymous ftp
Uid: 1002
Gid: 1002 (ftp)
Groups: ftp
Login Class: default
HOME: /home/ftp
Shell: /usr/bin/false
OK? (y/n) [y]: y
Added user ``ftp''
Copy files from /etc/skel to /home/ftp
Add another user? (y/n) [y]: n
Goodbye!
Mamy już dodanego użytkownika ftp; stworzony został także jego katalog domowy - /home/ftp. Należy dokonać jednak jeszcze kilku zmian, by konto było gotowe do obsługi anonimowego FTP. Ponownie odsyłamy do podręcznika systemowego programu ftpd(8).
Nie ma potrzeby zakładania katalogów /home/ftp/usr czy /home/ftp/bin.
Proszę zwrócić uwagę na to, by właścicielem wszystkich katalogów był root. Oto listing pokazujący jak powinny wyglądać stworzone katalogi:
# pwd
/home
# ls -laR ftp
total 5
dr-xr-xr-x 5 root ftp 512 Jul 6 11:33 .
drwxr-xr-x 7 root wheel 512 Jul 6 10:58 ..
dr-x--x--x 2 root ftp 512 Jul 6 11:34 etc
dr-xr-xr-x 2 root ftp 512 Jul 6 11:33 pub
ftp/etc:
total 43
dr-x--x--x 2 root ftp 512 Jul 6 11:34 .
dr-xr-xr-x 5 root ftp 512 Jul 6 11:33 ..
-r--r--r-- 1 root ftp 316 Jul 6 11:34 group
-r--r--r-- 1 root ftp 40960 Jul 6 11:34 pwd.db
ftp/pub:
total 2
dr-xr-xr-x 2 root ftp 512 Jul 6 11:33 .
dr-xr-xr-x 5 root ftp 512 Jul 6 11:33 ..
W przypadku ftpd można wybrać czy uruchamiać go z inetd(8), czy ze skryptów rc. Nasze przykłady pokażą jak uruchomić demona z pomocą inetd.conf. Na początku musimy jednak poznać pewne opcje ftpd. Standardowa linia z /etc/inetd.conf wygląda tak:
ftp stream tcp nowait root /usr/libexec/ftpd ftpd -US
W naszym przypadku ftpd jest przywoływany z opcją -US. Spowoduje to logowanie anonimowych połączeń do /var/log/ftpd, zaś sesji równoległych do /var/run/utmp. Sprawi to także, że sesje te będą widoczne przez polecenie who(8). Można również akceptować tylko i wyłącznie anonimowe połączenia, korzystając z opcji -A. Oto odpowiedni wpis (używamy także opcji -ll która powoduje, że każde połączenie jest logowane do sysloga, włączając w to komendy ftp takie jak get, retrieve itd):
ftp stream tcp nowait root /usr/libexec/ftpd ftpd -llUSA
Uwaga: W przypadku, gdy przewidywane jest bardzo duże obciążenie serwera ftp, zaleca się nie wywoływać ftpd z poziomu inetd.conf. Najlepiej jest wówczas wykomentować odpowiednią linię z pliku inetd.conf i uruchomić ftpd z poziomu rc.conf.local z włączoną opcją -D. Sprawi to, że demon będzie działał szybciej, niż gdyby został uruchomiony z inetd.conf. Oto przykład pokazujący jak uruchomić demona ftp z poziomu rc.conf.local:
ftpd_flags="-DllUSA" # for non-inetd use: ftpd_flags="-D"
Zadziała to oczywiście tylko wtedy, jeśli wcześniej wykomentowano odpowiedni wpis z /etc/inetd.conf oraz nakazano demonowi intetd ponownie przeczytać swój plik konfiguracyjny.
Domyślnie logując się przez ftp, użytkownicy mogą zmienić katalog na każdy do którego mają dostęp. W niektórych przypadkach może to być niepożądane. Istnieje możliwość ograniczenia tego co użytkownicy widzą w sesji ftp, poprzez chrootowanie ich w ich katalogach domowych.
Jeżeli chcesz zezwolić tylko na chrootowane połączenia ftp, przyjżyj się opcji -A w ftpd(8).
Jeżeli chcesz ograniczyć ich bardziej delikatnie, login.conf(5). oraz ftpd(8). mogą to ułatwić.
Użytkownicy w klasie logowania z ustawioną zmienną ftp-chroot będą chrootowani automatycznie. Dodatkowo, możesz dodawać nazwy użytkowników do pliku /etc/ftpchroot by chrootować tych użytkowników. Wystarczy by dany login był wpisany w jednej z tych dwóch lokalizacji.
Nawet w OpenBSD zdarzają się błędy. Niektóre błędy mogą doprowadzić problemów z niezawodnością (tj. coś może spowodować, że system przestanie pracować jak zaplanowano). Inne błędy mogą doprowadzić do problemów z bezpieczeństwem (te mogą pozwolić innym na "użycie" twojego komputera w niezamierzony sposób). Gdy zostanie wykryty błąd krytyczny, poprawka zostaje dodana do drzewa źródłowego wersji current, oraz wydawane są łatki dla każdej wspieranej wersji OpenBSD. Łatki te pojawiają się na stronie errat i są dzielone na "wspólne", obejmujące wszystkie platformy , oraz erraty działające w ramach jednej lub kilku, ale nie wszystkich, platform.
Proszę zwrócić uwagę na to, że łatki nie są jakimiś nowymi dodatkami do OpenBSD; są tworzone tylko wtedy, gdy powstanie problem związany z niezawodnością lub bezpieczeństwem systemu. Dlatego też łatki z reguły powinny być jak najszybciej aplikowane na objętych nimi maszynach (co często NIE oznacza wszystkich maszyn, w zależności od ich przeznaczenia).
Są trzy możliwości uaktualnienia systemu z poprawionym kodem:
Wszystkie łatki publikowane na stronie errat są przeznaczone do aplikowania na wskazany kod źródłowy danej wersji systemu (ang. release system). Łatki znalezione w najnowszym drzewie CVS mogą dodatkowo spowodować zmiany, które byłyby niepożądane w podstawowej wersji systemu. To jest bardzo ważne: jeżeli instalowałeś system ze "snapshota", sprawdziłeś źródła w czasie gdy pobierałeś snapshot i usiłowałeś załatać je korzystając z opublikowanej łatki, może lepiej zachowaj wersję przed użyciem łaty, jako że kod może ulec zmianie.
Łaty dla systemu OpenBSD są rozpowszechniane jako "ujednolicone diff'y", które są plikami tekstowymi zawierającymi różnice w stosunku do oryginalnego kodu źródłowego. NIE są dystrybuowane w formie binarnej! Oznacza to, że aby załatać swój system musimy mieć kod źródłowy wersji RELEASE OpenBSD. W szczególności powinieneś posiadać pełne dostępne drzewo źródeł. Jeżeli korzystasz z wersji dostępnej z oficjalnych płyt CD, źródła znajdują się na płycie 3, są także dostępne jako pliki z serwerów FTP. Zakładamy że posiadasz pełne i sprawdzone źródła.
W ramach naszego przykładu, przyjżymy się łatce 001 dla OpenBSD 3.6 dotyczącej sterownika st(4) obsługującego napędy taśmowe. Bez wspomnianej łatki, odzyskiwanie danych z backupu jest dość kłopotliwe. Osoby korzystające z napędów taśmowych potrzebują tej łatki, jakkolwiek w przypadku osób nie korzystających z napędu taśmowego nie ma szczególnego powodu na instalowanie tej łatki. Przyjżyjmy się łatce:
# more 001_st.patch
Apply by doing:
cd /usr/src
patch -p0 < 001_st.patch
Rebuild your kernel.
Index: sys/scsi/st.c
===================================================================
RCS file: /cvs/src/sys/scsi/st.c,v
retrieving revision 1.41
retrieving revision 1.41.2.1
diff -u -p -r1.41 -r1.41.2.1
--- sys/scsi/st.c 1 Aug 2004 23:01:06 -0000 1.41
+++ sys/scsi/st.c 2 Nov 2004 01:05:50 -0000 1.41.2.1
@@ -1815,7 +1815,7 @@ st_interpret_sense(xs)
u_int8_t skey = sense->flags & SSD_KEY;
int32_t info;
if (((sense->flags & SDEV_OPEN) == 0) ||
+ if (((sc_link->flags & SDEV_OPEN) == 0) ||
(serr != 0x70 && serr != 0x71))
return (EJUSTRETURN); /* let the generic code handle it */
# cd /usr/src
# patch -p0 < 001_st.patch
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|Apply by doing:
| cd /usr/src
| patch -p0 < 001_st.patch
|
|Rebuild your kernel.
|
|Index: sys/scsi/st.c
|===================================================================
|RCS file: /cvs/src/sys/scsi/st.c,v
|retrieving revision 1.41
|retrieving revision 1.41.2.1
|diff -u -p -r1.41 -r1.41.2.1
|--- sys/scsi/st.c 1 Aug 2004 23:01:06 -0000 1.41
|+++ sys/scsi/st.c 2 Nov 2004 01:05:50 -0000 1.41.2.1
--------------------------
Patching file sys/scsi/st.c using Plan A...
Hunk #1 succeeded at 1815. <-- Szukaj takiej informacji!
done
W tym momencie, możesz przystąpić do budowy jądra, zainstalowania go i zrestartowania systemu.
Nie wszystkie łaty dotyczą jądra. W niektórych przypadkach, będziesz musiał przebudować pojedyńcze narzędzia. W innych będziesz potrzebował przebudować wszystkie narzędzia statycznie zlinkowane z łataną biblioteką. Zastosuj się do informacji w nagłówku łaty, a gdy masz wątpliwości przebuduj cały system
Łaty nie mające zastosowania dla twojego określonego systemu, zazwyczaj nie powinny być nakładane. Dla przykładu, jeżeli nie posiadasz napędu taśmowego, nie odniesiesz żadnej korzyści z opisanej wyżej łaty. Jakkolwiek, łaty mogą przypuszczalnie być zakładane "w kolejności" - istnieje możliwość, że późniejsza łatka jest powiązana z jedną z wcześniejszych. Bądź uważny jeżeli postanowisz "grymasić" z łatkami które nakładasz, i w przypadku wątpliwości, nałóź je wszystkie w kolejności.
W systemie OpenBSD, serwer HTTP Apache ( httpd(8)) jest uruchamiany domyślnie w środowisku zmodyfikowanym poleceniem chroot(2). Chociaż jest to wspaniałe z punktu widzenia bezpieczeństwa systemu, mogą się z tym wiązać pewne niespodzianki dla osób nieprzygotowanych na taką zmianę.
Nie owijając w bawełnę trzeba powiedzieć, że uruchamianie serwera Apache w środowisku chroot(2) jest czymś nowym. Dlatego też wiele starszych programów czy ustawień systemowych przestanie działać, bez kilku przeróbek. Ponadto musimy pamiętać, że bezpieczeństwo i wygoda często nie są kompatybilnymi założeniami. Implementacja Apache w OpenBSD nie jest kompromisem bezpieczeństwa względem funkcjonalności i "wygody".
# apachectl stop
zmień nazwy swoich logów
# apachectl start ; sleep 10 ; apachectl start
Na początek instalujemy pakiet wwwcount. Konfigurujemy go i testujemy, a także odkrywamy że wydaje się nie działać, otrzymując błąd Apache "Internal Server Error". Następnie zatrzymujemy Apache'a i restartujemy z opcją -u i sprawdzamy, że problemem jest chroot(2), nie konfiguracja.
# apachectl stop
/usr/sbin/apachectl stop: httpd stopped
# httpd -u
# apachectl stop
/usr/sbin/apachectl stop: httpd stopped
# httpd
Dobrym punktem wyjścia byłoby założyć, że wwwcount używa bibliotek i innych plików do których nie ma dostępu przez chroot. Możemy użyć polecenia ldd(1) by sprawdzić zależności jakich wymaga CGI:
# cd /var/www/cgi-bin/
# ldd Count.cgi
Count.cgi:
Start End Type Ref Name
00000000 00000000 exe 1 Count.cgi
03791000 237ca000 rlib 1 /usr/lib/libc.so.30.3
03db4000 03db4000 rtld 1 /usr/libexec/ld.so
# mkdir -p /var/www/usr/lib /var/www/usr/libexec
# cp /usr/lib/libc.so.30.3 /var/www/usr/lib
# cp /usr/libexec/ld.so /var/www/usr/libexec
Teraz program przynajmniej się uruchamia i zwraca nam błąd: "Unable to open config file for reading". Mamy postęp, lecz jeszcze nie skończyliśmy. Normalnie plikiem konfiguracyjnym jest /var/www/wwwcount/conf, jednak w środowisku chroot wydaje się że jest to /wwwcount/conf. Możemy więc albo przekompilować program tak by korzystał z plików w miejscu gdzie są teraz, albo przenieść te dane. Ponieważ zainstalowaliśmy program z pakietu, po prostu przeniesiemy pliki. Aby używać tej samej konfiguracji zarówno w środowisku chroot(2), jak i normalnym, możemy zrobić dowiązanie symboliczne:
# mkdir -p /var/www/var/www
# cd /var/www/var/www
# ln -s ../../wwwcount wwwcount
# tar cf - /usr/local/lib/wwwcount | (cd /var/www; tar xpf - )
Zwróć uwagę, że skopiowaliśmy tylko te pliki które są absolutnie niezbędne. Generalnie, tylko minimalna ilość plików potrzebna do uruchomienia aplikacji powinna być kopiowana do chroot'a.
Nie każdą aplikację można lub powinno się chroot(8)-ować.
Celem jest bezpieczny serwer www, chroot(8) jest tylko narzędziem doskonalącym to zadanie, lecz sam nie jest celem. Pamiętaj, początkowa konfiguracja chroot(2)-owanego Apache'a w OpenBSD oznacza, że użytkownik z uprawnieniami którego działa httpd(8), nie może uruchamiać żadnych programów, nie może modyfikować żadnych plików, a także nie może przejmować tożsamości innych użytkowników. Tracąc te ograniczenia, tracisz bezpieczeństwo, nie ważne czy chrootowane czy nie.
Niektóre aplikacje bywają bardzo proste, więc chroot(2)-owanie ich ma sens. Inne bywają dość skomplikowane i albo nie są warte wysiłku by umieścić je w chroot(2), albo podczas kopiowania systemu w chroot, możesz stracić korzyści środowiska chroot(2). Przykładowo, program OpenWebMail wymaga dostępu do czytania i zapisu katalogów z pocztą, katalogów domowych użytkowników, a także musi mieć możliwość działania jako jakikolwiek użytkownik w systemie. Usiłowanie wepchnięcia go w chroot jest zupełnie bezcelowe, ponieważ w rezultacie i tak pozbawisz się wszystkich zalet chroot(2)-owania. Nawet w przypadku aplikacji tak prostej jak nasza, musi ona zapisywać na dysk (by zapamiętywać liczniki), więc niektóre korzyści z chroot(2)-a są tracone. Generalnie, tylko minimum plików koniecznych by aplikacja działała powinno być kopiowane w chroot.
Usiłowanie chroot(2)-owania jakiejkolwiek aplikacji działającej z uprawnieniami root-a jest bezcelowe, root generalnie może uciec z chroot(2)-a.
Nie zapomninaj także, że w sytuacji gdy chrootowanie jakiejś aplikacji okaże się bardzo trudne, możesz nie aktualizować systemu tak często jak powinieneś. Może to spowodować, że twój system będzie MNIEJ bezpieczny, niż bardziej zarządzalny system z wyłączoną funkcjonalnością chroota.
Domyślną powłoką użytkownika root w systemach OpenBSD jest ksh.
Tradycyjnym przykazaniem administratora Uniksa jest korzystanie jako root tylko ze statycznie skompilowanych powłok, ponieważ kiedy system przechodzi w tryb pracy pojedynczego użytkownika (ang. single user), partycje nie należące do tego użytkownika nie są montowane, zatem dynamicznie łączone powłoki nie będą w stanie skorzystać z bibliotek zlokalizowanych w partycji /usr. Nie jest to coś, o czym administrator systemu OpenBSD musi pamiętać, ponieważ gdy system przejdzie w tryb pojedynczego użytkownika to sam poprosi o wybranie powłoki, zaś domyślną powłoką jest sh. W systemie OpenBSD standardowo znajdują się trzy powłoki (csh, sh oraz ksh). Wszystkie z nich są zlinkowane statycznie, tak więc dostępne są również w trybie pojedynczego użytkownika.
Użytkownicy posługujący się swobodnie powłoką bash (często spotykaną w systemie Linux), prawdopodobnie odnajdą w ksh wiele podobieństw. Ksh(1) posiada większość funkcji spotykanych w powłoce bash, włączając w to dopisywanie nazw plików po naciśnięciu klawisza Tab, redagowanie i przeglądanie listy wydanych wcześniej poleceń za pomocą klawiszy strzałek oraz przeskakiwanie na początek/koniec redagowanego polecenia za pomocą klawiszy CTRL-A/CTRL-E. Jeżeli potrzebne są inne funkcje powłoki bash, bash można zainstalować korzystając z pakietów lub pakietów.
Znak zachęty powłoki ksh można z łatwością zmienić z domyślnego "$ " na coś, co dostarczy użytkownikowi więcej informacji przez ustawienie zmiennej PS1. Na przykład, wstawienie następującej linii:
export PS1='$PWD $ '
/home/nick $
Dostępna w OpenBSD powłoka ksh(1) zostało rozszerzone o kilka "specjalnych znaków" dla podstawowego znaku zachęty, PS1, podobnych do tych wykorzystywanych w bashu. Dla przykładu:
\e - Wstaw znak ASCI - escape.(na stronie manuala ksh(1) znajdziesz więcej szczegółów a także znacznie więcej "znaków specjalnych"! Zwróć uwagę że znak "$" ma specjalne znaczenie wewnątrz podwójnego cytowania, zatem używaj go ostrożnie)
\h - Nazwa hosta, bez nazwy domeny.
\H - Pełna nazwa hosta, łącznie z nazwa domeny.
\n - Wstaw znak nowej linii.
\t - Aktualny czas w formacie: HH:MM:SS (24-godzinnym).
\u - Aktualna nazwa użytkownika.
\w - Aktualny katalog roboczy. $HOME jest skracany do `~'.
\W - Nazwa aktualnego katalogu roboczego bez wiodącej ścieżki.
\$ - Wyświetli "#" dla root-a, "$" dla pozostałych użytkowników.
Niektórzy mogą użyć poniższego polecenia:
export PS1="\n\u@\H\n\w \\$ "
[Spis treści] [Sekcja 9 - Migracja do OpenBSD] [Sekcja 11 - X Window System]
![[back]](../../images/back.gif){kind=small}
www@openbsd.org