Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Strony: 1
Technicznie rzecz ujmując, to nigdy nie używałem udisks2, bo wcześniej miałem problemy dotyczące:
1) niechcianego automontowania zasobów USB,
2) braku możliwości określenia praw dostępu do montowanych zasobów (wszystkich, nie tylko tych automatycznie montowanych).
Do tej pory korzystałem z narzędzia udevil, które było w stanie skutecznie ograniczyć dostęp do zasobów określonym użytkownikom, a że też ludzie źle pisali na temat udisks2, to w zasadzie nie chciało mi się nim bawić. Jednak przy (prawdopodobnej) migracji na KDE, udisks2 jest podpięty nawet gdy się instaluje najmniejszy możliwy zestaw pakietów i nie da rady się pozbyć udisks2 jeśli chce się mieć KDE. Postanowiłem zatem się trochę przyjrzeć temu udisks2 i zobaczyć ile jest prawdy w tym co ludzie gadają, czyli, że tego narzędzia nie powinno się instalować. xD
Poza samym udisks2, w repo Debiana są jeszcze dodatkowe pluginy (pakiety libblockdev-*), które można sobie dograć według potrzeb, np. są moduły od device-mapper'a, lvm2, szyfrowania, loop, itp. Niemniej jednak, sam udisks2 nie realizuje automatycznego montowania zasobów — one muszą być montowane za pomocą jakiegoś zewnętrznego mechanizmu i zwykle menadżery plików go oferują. Tak czy inaczej, istnieje także dedykowane narzędzie do tego celu, tj. udiskie (taki frontend dla udisks2).
Po zainstalowaniu tych powyższych pakietów, system będzie nam montował praktycznie wszystkie zasoby USB automatycznie, co może trochę wnerwiać człowieka, zwłaszcza jak się ma do czynienia z pendrive, który ma wiele partycji. By sobie ogarnąć ten cały udisks2/udiskie trzeba sobie napisać regułę dla udev'a, a właściwie to parę reguł.
Pierwsza z reguł przerobi wszelkie zasoby USB na systemowe. Można oczywiście sobie dowolnie dopasować urządzenia, ja jednak chcę by standardowy użytkownik nie miał prawa bawić się zasobami USB bez wyraźnej zgody. Dlatego stworzyłem sobie plik /etc/udev/rules.d/81-udisks2-block.rules i w nim ta pierwsza reguła wygląda tak:
SUBSYSTEMS=="usb", \ ENV{UDISKS_IGNORE}="1", \ ENV{UDISKS_AUTO}="0", \ ENV{UDISKS_SYSTEM}="1"
Powyższe wpisy mają na celu ustawić szereg zmiennych w środowisku udev'a. W oparciu o te zmienne operuje udisks2/udiskie . Zmienne: UDISKS_IGNORE ma na celu ukrycie podłączanych zasobów w różnych aplikacjach, np. menadżerach plików ale to czy tak będzie w istocie zależy już od samych aplikacji. Zmienna UDISKS_AUTO wyłącza automatyczne montowanie zasobów, a UDISKS_SYSTEM przerabia zasoby na systemowe.
Po ustawieniu tej ostatniej zmiennej nie będzie już można zamontować żadnych zasobów USB jako zwykły user, tj. będzie wymagany root — tego typu rozwiązanie (wraz z zablokowaniem automontowania zasobów) znacznie poprawia bezpieczeństwo systemu . Jeśli ktoś by spróbował zamontować zasób USB po ustawieniu tych powyższych opcji, to zostanie mu zwrócony poniższy komunikat:
Error creating textual authentication agent: Error opening current controlling terminal for the process (`/dev/tty'): No such device or address (polkit-error-quark, 0)
Error mounting /dev/sdc1: GDBus.Error:org.freedesktop.UDisks2.Error.NotAuthorizedCanObtain: Not authorized to perform operation
Oczywiście tego tupu rozwiązanie, o ile bardzo bezpieczne, to nie jest zbyt poręczne. Można dodać drugą regułę, która będzie miała na celu włączyć możliwość montowania zasobów jako zwykły użytkownik, w tym też automontowania określonych urządzeń. W tym celu trzeba dodać poniższą regułę:
ENV{DEVTYPE}=="partition", ATTRS{serial}=="001CC0EC34A2BB318709004B", \ ENV{UDISKS_IGNORE}="0", \ ENV{UDISKS_AUTO}="1", \ ENV{UDISKS_SYSTEM}="0"
Dopasowuje one urządzenia w oparciu o to czy mamy do czynienia z partycją (dyski zwykle nie mają systemu plików) oraz konkretnym numerem seryjnym urządzenia. Można pójść o krok dalej i dopasować nawet ID_FS_UUID, czyli zmienną przechowującą UUID systemu plików na danej partycji.
W taki sposób udisks2 jest w stanie udostępnić zwykłemu użytkownikowi tylko pewne określone urządzenia, na których może on operować. No i gdy ktoś nam podłączy swojego pendrive do kompa, to oczywiście nie da rady wejść z tym urządzeniem w interakcję i zgrać/wgrać danych z/na kompa, co jest bardzo użyteczne. Także jak widać, nie taki udisks2 straszny, wystarczy ogarnąć udev'a, a dalej to już samo pójdzie. xD
Ostatnio edytowany przez morfik (2018-04-03 17:50:06)
Offline
Tam nie będę miał feedback'a, a poza tym i tak nikt tam nie zagląda, a jak już czegoś się szuka, to i tak przez google z site:dug.net.pl i nick autora posta. xD
Offline
morfik napisał(-a):
Tam nie będę miał feedback'a, a poza tym i tak nikt tam nie zagląda, a jak już czegoś się szuka, to i tak przez google z site:dug.net.pl i nick autora posta. xD
szuka, szuka
Offline
Wygląda na to, że ograniczone prawa dostępu do zasobów można też nałożyć bezpośrednio w udisks2 w połączeniu z polkit, tylko chyba nowsza wersja polkit jest wymagana i na tej co jest nie da rady tego robić. Tu jest przykład:
polkit.addRule(function(action, subject) {
if (action.id.indexOf("org.freedesktop.udisks2.") == 0 &&
action.lookup("drive.vendor") == "SEAGATE" &&
action.lookup("drive.model") == "ST3300657SS" &&
subject.isInGroup("engineers")) {
return polkit.Result.YES;
}
}
});
-- https://www.freedesktop.org/software/polkit/docs/latest/polkit.8.html
A tu są wartości jakie można sobie dobrać i w zasadzie jest wszystko czego ja bym chciał: xD
http://storaged.org/doc/udisks2-api/latest/udisks-polkit-actions.html
Offline
Ok udało się to ogarnąć bez zbytniego bawienia się w reguły UDEV'a. W zasadzie to jest jakiś problem/konflikt na linii polkit<->devy debiana i od paru lat ten nowszy polkit 0.106+ nie może się wbić do unstable. Ta nowsza wersja jest od lat póki co w experimental ale ona działa. Zainstalowałem ją w końcu i by ogarnąć montowanie przy wykorzystaniu UDISKS2, to wystarczy stworzyć sobie dwie reguły (w pliku /etc/polkit-1/rules.d/20-udisks2.rules):
// Allow morfik user to mount some devices // without having to authenticate // polkit.addRule(function(action, subject) { if (action.id.indexOf("org.freedesktop.udisks2.") == 0 && action.lookup("drive.serial") == "0019E06B9C8ABE41C7A2C3EC" && subject.user == "morfik") { return polkit.Result.YES; } }); polkit.addRule(function(action) { if (action.id.indexOf("org.freedesktop.udisks2.") == 0) { return polkit.Result.NO; } });
Kolejność reguł ma znaczenie i jeśli zamienić by je miejscami, to morfik nie da rady zamontować zasobu. A jak jest taka kolejność jak wyżej, to jeśli są przetwarzane akcje org.freedesktop.udisks2.* (a jest ich trochę i można sobie sprecyzować dokładnie które mają być brane pod uwagę), oraz urządzenie ma określony numer seryjny i dodatkowo to użytkownik morfik próbuje operować na tym urządzeniu, to system mu pozwoli na tę akcję. Druga reguła ma z kolei na celu zablokowanie wszelkich innych akcji z udziałem UDISKS2. Można naturalnie sobie dać AUTH_ADMIN zanuast NO i wtedy zapyta o hasełko ale mi to do niczego nie potrzebne. xD
Jeśli użytkownik nie ma prawa do zasobu, to automatyczne montowanie zasobu jest blokowane. Jeśli natomiast się zezwoli użytkownikowi na dostęp do jakiegoś urządzenia, to po podłączeniu pendrive, takie urządzenie zostanie z automatu podmontowane przez politykę UDISKS2. Jeśli komuś to przeszkadza, to można dodać regułę UDEV'a z pierwszego postu i ustawić zmienne dla UDISKS, by nie montował automatycznie tego pendrive, czy też wszystkich innych urządzeń:
SUBSYSTEMS=="usb", \ ENV{UDISKS_AUTO}="0", \ ENV{UDISKS_IGNORE}="1"
I tu już jak widać nie trzeba ustawiać ENV{UDISKS_SYSTEM}="1" .
A i bym zapomniał — ten polkit wymaga jakiegoś agenta, który będzie pośredniczył między user'em a demonem polkit'a. Z reguły każde środowisko graficzne ma swojego własnego agenta, np. KDE ma polkit-kde-agent-1 ale na Openbox nie ma żadnego i trzeba sobie jakiś doinstalować.
No to chyba tyle w temacie, czyli udisks2 i polkit wypadają z mojej listy mechanizmów do obczajenia. xD
Ostatnio edytowany przez morfik (2018-04-09 01:27:13)
Offline
Przy okazji czytania sobie dokumentacji AppArmor (i pisania profili dla polkitd i udisksd), dopatrzyłem się tam kilku opcji od montowania zasobów. Technicznie rzecz biorąc, to policykit stoi na straży uprawnień, które dostają użytkownicy podczas próby zamontowania pendrive czy jakiejś partycji systemowej i to od określonych reguł (np. takich) zależy czy dostęp do zasobów zostanie im przyznany.
W przypadku, gdy polkit wyrazi zgodę aby użytkownik dostał możliwość zamontowania zasobu, to daemon udisksd wykonuje określone akcje montowania i odmontowania. Można by zatem dozbroić nieco udisksd na poziomie samego kernela, ograniczając mu możliwości montowania dysków w systemie. W dalszym ciągu policykit będzie grał główną rolę w przyznawaniu uprawnień ale będzie to robił tylko i wyłącznie obszarze, który zostanie narzucony demonowi udisksd. Czyli krótko mówiąc, jeśli policykit będzie miał złą politykę dostępu do zasobów, która powstałaby w wyniku błędów w konfiguracji reguł, to udisks dostanie po łbie od kernela i zamontowanie zasobu i tak się nie powiedzie. xD
Poniżej przykład reguł AppArmor'a ograniczających demona udisksd (które trzeba dodać do profilu AA):
mount fstype={ext*,vfat,iso9660} /dev/sd?? -> /media/*/*/, umount /media/*/*/,
W taki sposób można narzucić by udisks2 operował jedynie na zasobach, które mają system plików z rodziny EXT, FAT, czy ISO9660, plik urządzenia /dev/sda1 czy /dev/sdb4 i montował takie zasoby tylko i wyłącznie pod /media/$user/jakis_katalog/ (z reguły udisks tworzy katalog /media/$user/ i montuje zasób w katalogu o nazwie etykiety dysku).
Można także dorobić określone opcje, które mogą być użyte przy montowaniu, np. ta powyższa linijka zezwala na wykorzystanie wszystkich opcji ale można ograniczyć je dodając coś na wzór.
options=(ro,atime) options in (ro,atime)
Różnica między tymi dwoma jest taka, że ten pierwszy pasuje tylko do zasobów, które mają ustawione obie te opcje, a drugi do zasobów, które mają każdą kombinację z tych wymienionych w nawiasie.
Offline
Strony: 1