DIY: Akcent świąteczny w miejscu pracy

Zrób to sam: Choinka u Informatyków :)

Kliknij, aby powiększyć

ACL dla plików i katalogów w Ubuntu

Unixowy system uprawnień dla plików i katalogów został naprawdę dobrze przemyślany i świetnie się sprawdza. Każdy jednak prędzej czy później może trafić na sytuację, w której możliwość stosowania rozszerzonych uprawnień dałaby znacznie większą swobodę i wygodę.

Kogo temat może zainteresować?

Wydaje mi się, że użytkownicy zwykłych desktopów nie będą ACL’i potrzebować. Jeśli jednak jakiś developer umieszcza przykładowo serwer z repozytorium u siebie albo jest administratorem jakiegoś serwera – myślę, że warto się zapoznać z poniższą tematyką.

Krok po kroku

Access Control Lists (ang. ACL), czyli listy kontroli dostępu są w jądrze Ubuntu wkompilowana domyślnie już od jakiegoś czasu. Niewiele stoi zatem nam na przeszkodzie, aby aktywnie zacząć z nich korzystać. ACL należy traktować jako rozszerzenie Unixowego systemu uprawnień plików i katalogów, dlatego zestaw komend takich jak chown czy chmod nadal obowiązuje.

Czego zatem potrzebujemy? Musimy uświadomić nasz system, że będziemy wykorzystywać ACL’e dla konkretnych systemów plików. No i przede wszystkim – musimy mieć narzędzia do zarządzania ACL’ami oraz wiedzieć, jak się ich używa :)

Zatem po kolei.

Sprawdźmy, czy mamy narzędzia do obsługi ACL’i. Narzędzia nazywają się setfacl, getfacl oraz chacl.

desktop repos # getfacl
Program getfacl nie jest obecnie zainstalowany.  Można go zainstalować wpisując:
apt-get install acl
getfacl: command not found
desktop repos #

Więc go sobie instalujemy:

sudo aptitude install acl

Spróbujmy ustawić jakąś rozszerzoną listę dostępu. Przejdźmy do katalogu domowego, załóżmy katalog test oraz nadajmy uprawnienia rwx użytkownikowi nobody.

cd
mkdir test
setfacl -R -m u:nobody:rwX test
setfacl: test: Operation not supported

Komunikat Operation not supported oznacza nic innego jak brak obsługi ACL w systemie plików. Jeśli nasz katalog domowy znajduje się na odrębnym systemie plików home, możemy aktywować obsługę ACL komendą:

sudo mount -o remount,acl /home

Teraz ustawianie rozszerzonych uprawnień powinno już działać. Ponowne wydanie komendy setfacl nie powinno już zwrócić błędu.

Przy okazji, możemy zobaczyć jak wyglądają uprawnienia naszego katalogu:

nme@desktop ~ $ setfacl -R -m u:nobody:rwX test
nme@desktop ~ $ ls -lad test/
drwxrwxr-x+ 2 nme nme 4096 2009-12-30 14:29 test/
nme@desktop ~ $ getfacl test
# file: test
# owner: nme
# group: nme
user::rwx
user:nobody:rwx
group::r-x
mask::rwx
other::r-x

Warto zwrócić uwagę na uprawnienia zwracane komendą ls -l: drwxrwxr-x+ – na końcu listy uprawnień znajduje się znak + oznaczający rozszerzone informacje. Takie uprawnienia możliwe są do odczytu za pośrednictwem getfacl co też uczyniłem powyżej. Wynik komendy jest dość czytelny.

Wracając do wydanej komendy:

setfacl -R -m u:nobody:rwX test

Co po naszemu brzmi – rekursywnie zmodyfikuj uprawnienia dla użytkownika nobody dla katalogu test ustawiając uprawnienia rwx dla katalogów i rw dla plików.

Dziecinne proste. Rozbudujmy komendę:

setfacl -Rm u:nobody:rwX,d:u:nobody:rwX test

(pierwsza część jest tak naprawde zbędna, ponieważ uprawnienia dla użytkownika już ustawiliśmy, ale chciałem przedstawić sposób w jaki możemy łączyć uprawnienia w obrębie jednej komendy)

d:u:... można zapisać również jako default:u:... co oznacza, że dla nowo zakładanych plików/katalogów, takie atrybuty mają być domyślnie dodawane.

Ważna sprawa, na koniec

Aby używać list dostępu, aktywowaliśmy opcję acl poprzez przemontowanie systemu pliku. Niestety, po restarcie, system plików nie będzie już obsługiwał list dostępu.

Co zatem zrobić?

Jeśli chcemy, aby nasz system plików pamiętał o tym, że ma obsługiwać rozszerzone listy dostępu, w pliku /etc/fstab należy to zaznaczyć, acl jako opcję dla naszego systemu plików:

/dev/mapper/desktop-home /home           ext3    defaults,acl        0       2

Więcej informacji, wraz z przykładami znaleźć możecie na stronach manuala komend do obsługi acl które przedstawiłem w tym tekscie.

Ailurus: wygodny tuning Ubuntu

Niestrudzony Adrian Nowak, na blogu Ubucentrum zamieścił wpis Ailurus – ułatwi początki z Linuksem.

Czym jest Ailurus? To wygodny interfejs produkcji „Thrusted Digital Technology Lab.” z siedzibą w Chinach, do tuningu systemu i obsługi systemu :)

Faktycznie, narzędzie jest faktycznie bardzo ciekawe. Nie znajduje się jednak w standardowym repozytorium. Dlatego myślę, że warto wspomnieć, w jaki sposób najwygodniej je zainstalować.

Nie zalecałbym metody którą proponuje Adrian – czyli instalacji pojedynczej paczki z serwisu GetDeb.net.

Instalowanie pojedynczych paczek jest zaśmiecaniem systemu.

Instalacja

W Ubuntu 9.10 możemy w wygodny sposób dodawać repozytoria, które sprawią, że jeśli pojawi się nowa wersja pakietu, przy aktualizacji systemu, pakiet zostanie również uaktualniony.

# przechodzimy na roota
sudo -i

# dodajemy nowe repozytorium
add-apt-repository ppa:ailurus

# aktualizujemy wykaz aktualnych pakietów
aptitude update

# instalujemy pakiet
aptitude install ailurus

Aplikacja, po instalacji jest dostępna poprzez Programy / Narzędzia systemowe / Ailurus.

Co oferuje nam pakiet?

  • Tips and tricks – warto przeglądnąć – informacje jak za pomocą gconf-editora wykonać tuning naszego Gnome’a
  • Wygodny frontend do konfiguracji i sprawdzenia parametrów systemu (typ procesora, ilość pamięci, czy procesor jest 64-bitowy, rodzaj karty graficznej i sieciowej)
  • Skróty do instalacji różnych przydatnych aplikacji, których nazwy należałoby w innym wypadku pamiętać albo trzeba byłoby się bardziej narobić, żeby je zainstalować
  • Ustawienia systemowe – innymi słowy – edycja plików konfguracyjnych, modifykacja menu kontekstowego Nautilusa itp
  • i wiele innych…

Kiedy można sobie ułatwić życie, warto to robić :)

Infrastruktura PKI na podstawie SSH

openssh_logoInfrastruktura kluczy publicznych (ang. Public Key Infrastructure, w skrócie PKI) jest podstawą współczesnej kryptografii. Miałem już styczność z wieloma osobami z branży IT, które kompletnie nie czuły o co właściwie w tym chodzi.Myślę, że poniższy tekst napewno się komuś przyda oraz, że warto mu poświęcić 5 minut. Spróbuję się maksymalnie streścić ;)

Klucze symetryczne i niesymetryczne

Większość szyfrowanych kanałów transmisji wykorzystuje jednocześnie klucze niesymetryczne jak i symetryczne.

Zaletą kluczy symetrycznych (takich jak AES, Blowfish czy DES) jest szybkość szyfrowania/deszyfrowania przy stosunkowo niskim obciążeniu procesora.

Wadą kluczy symetrycznych jest etap nawiązania transmisji. Jeśli oba komputery nie posiadają tego samego klucza do szyfrowania/deszyfrowania wiadomości – klucz taki musiałby być wysłany z jednego z nich do drugiego drogą nieszyfrowaną. Taką wymianę klucza można byłoby łatwo podsłuchać. Następnie, korzystając z tak zdobytego klucza – można podsłuchać resztę transmisji (taki atak nosi nazwę Man In The Middle).

Dlatego właśnie pojawiły się klucze niesymetryczne (np. stosowany standardowo w protokole ssh – algorytm RSA). Klucz niesymetryczny składa się z dwóch części – publicznej i prywatnej. Posiadacz części publicznej klucza jest w stanie zaszyfrować wiadomość. Posiadacz klucza prywatnego – może taką wiadomość odszyfrować. Proste. Dodatkowo – na podstawie klucza publicznego jesteśmy w stanie zweryfikować odcisk klucza (fingerprint) – jeśli się zgadza, wiemy, że rozmawiamy z właściwym serwerem.

Klucze w praktyce

Serwery Linuxowe na których pracuje usługa ssh mają również wygenerowane swoje klucze. Autentykacja może być różnoraka, jednak do najpopularniejszych należą – para użytkownik-hasło oraz łączenie się z wykorzystaniem kluczy.

Wykorzystanie haseł jest proszeniem się o kłopoty. Warto przesiąść się na klucze. Jak to zrobić?

Wygenerujmy sobie klucz. W obecnych czasach warto zaznaczyć, że chcemy mieć klucz 4096-bitowy, będzie się generował dłużej, ale będzie bezpieczniejszy. Warto też ustawić hasło dla klucza.

nme@notebook ~ $ ssh-keygen -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/home/nme/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/nme/.ssh/id_rsa.
Your public key has been saved in /home/nme/.ssh/id_rsa.pub.
The key fingerprint is:
12:30:87:ca:06:81:d8:5a:32:41:81:4c:3a:74:33:a9 nme@notebook
The key's randomart image is:
+--[ RSA 4096]----+
|XO.++..          |
|X.+.++           |
|oB..  .          |
|.E+    .         |
| .    . S        |
|       .         |
|                 |
|                 |
|                 |
+-----------------+
nme@notebook ~ $

W katalogu .ssh pojawiły się dwa pliki id_rsa – będący naszym kluczem prywatnym oraz id_rsa.pub – czyli klucz publiczny.
Klucza publicznego nie trzeba specjalnie strzec. Ważne, aby nasz klucz prywatny nie dostał się w cudze ręce.

Po co ten obrazek w ASCII? Abyśmy nie musieli weryfikować znak po znaku naszych kluczy. Jeśli chcemy odczytać fingerprint klucza, wydajemy komendę:

ssh-keygen -l

Jeśli chcemy zobaczyć odcisk wraz z obrazkiem ASCII – wydajemy:

ssh-keygen -lv

Okej. Powiedzmy, że mamy klucze i serwer na który chcielibyśmy się łączyć za ich pomocą. Musimy umieścić zawartość naszego klucza publicznego w pliku .ssh/authorized_keys na serwerze docelowym. Możemy to zrobić komendą:

nme@notebook ~ $ ssh-copy-id serwer:
The authenticity of host 'serwer (x.x.x.x)' can't be established.
RSA key fingerprint is fe:2b:6b:71:6f:81:ef:07:74:89:72:e7:ef:ab:f8:62.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'serwer,x.x.x.x' (RSA) to the list of known hosts.
Password:
nme@notebook ~ $

teraz możemy już normalnie się zalogować:

nme@notebook ~ $ ssh serwer
nme@serwer ~ $

W pliku .ssh/authorized_keys możemy trzymać dowolną ilość kluczy.

Dobrą praktyką jest generowanie kluczy prywatnych na każdej stacji roboczej z której łączymy się na inne maszyny. W wypadku gdy np. ktoś ukradnie nam jedną z tych maszyn – wystarczy usunąć dane klucze z plików authorized_keys serwerów, do których mamy dostęp.

Skoro już opanowaliśmy klucze – warto wyłączyć autoryzację do naszych serwerów za pośrednictwem par użytkownik-hasło. Robimy to edytując plik /etc/ssh/sshd_config – weryfikujemy ustawienia:

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

Restart sshd we współczesnych Ubuntu czy RedHatach wykonujemy komendą:

sudo service ssh restart

Kiedy wyłączymy już logowanie na pary użytkownik-hasło i pozostawimy jedynie logowanie na klucze:

nme@notebook ~ $ ssh serwer
Permission denied (publickey).
nme@notebook ~ $

Gdzie poza SSH stosowane są jeszcze klucze?

Infrastruktura kluczy publicznych (PKI) stosowana jest również przykładowo w HTTPS czy w sieciach bezprzewodowych – WPA2 (AES). Klucze niesymetryczne stosowane są do nawiązania transmisji między klientem i serwerem – celem wymiany klucza symetrycznego, a następnie transmisja jest już oparta o klucz symetryczny.

Znajomość ogólnych zasad działania PKI jest bardzo praktyczna również w przypadku, jeśli przymierzamy się do wykorzystania OpenPGP czy certyfikatów SSL, które możemy traktować jak wyższe stopnie zaawansowania ;)