Moje Dysputy O Package/policy Kitach

[notgnucy]

Temat nawiązuje do ostatnich perypetii ze skryptem package-no-found. Muszę przyznać, iż pomysł nie był zły, był tylko źle zrealizowany. Wiele razy okazuje się, że pewne oprogramowanie na pewno nie jest złośliwe i jest przydatne. Nie możemy jednak tak powiedzieć o wszystkich, nawet tych pochodzących z oficjalnego forum fedory.

 

Dobrym rozwiązaniem byłoby zezwolić na oznaczenie danego pakietu, jako gotowego do instalacji. Możemy np. zaznaczyć wszystkie klienty IM, obsługujące różne protokoły, jako gotowe do instalacji. Oczywiście, prócz nazwy pakietu można sprecyzować też repozytorium i wersję. Byłoby to świetne, gdyż oszczędzamy miejsce, nie zaśmiecamy menu, a jeżeli użytkownik sobie tego zażyczy, to może zainstalować potrzebnego klienta IM w chwilkę(lub system samemu to zainstaluje). Oczywiście uprawnienia do instalowania paczek gotowych do instalacji przyznawałoby się w PolicyKit, domenie PackageKit-u. Dobrym rozwiązaniem byłaby możliwość naniesienia gotowych zestawów tych ustawień. Przypuśćmy, iż system sam może nam zainstalować WINE i kodeki bez podawania hasła. W tym celu udajemy się np. na stronkę, by pobrać zestaw przyjaznych paczek, a następnie dodajemy je do zbioru gotowych do instalacji. System sam zainstaluje WINE przy próbie otworzenia pliku EXE, kodeki przy próbie otwarcia filmu, itd.

 

Ważny zastosowaniem jest np., by zaznaczyć całą kategorię gry, jednak pochodzące z danego repo, jako gotowe do instalacji. W ten sposób siostra mogłaby instalować sobie gry, jak jej się podoba(gorzej, IHMO z usuwaniem, gdyż nie znamy właściciela, co zainstalował ten pakiet).

 

To tylko sugestia. Wiem, że dużo pracy jest wymagane, by ją zrealizować(szczególnie pod kątem GUI), ale chyba warto. Zawsze możemy otworzyć repo własnych programów, by rozpowszechniać je w firmie. Sekretarka będzie korzystać z innych programów, księgowa z innych, więc pozostałe aplikacje nie będą zużywać potrzebnego miejsca i rozpraszać. Można nawet wprowadzić automatyczne kasowanie programów po pewnym czasie od wylogowania.

 

Wiem, iż od tego jest opcja instalacja zaufanych pakietów, jednak to nie spełnia roli, gdyż wiele systemów nie zainstaluje paczki, jeżeli nie zainstalujemy klucza. Mój pomysł by rozwiązał wszystkie te problemy.

Edytowane Grudzień 5, 2009 przez WalDo
łączenie postów

[@WalDo]

Propozycja imho bez sensu o ile dobrze zrozumiałem to co napisałeś.

Po co mam się udawać "na stronkę, by pobrać zestaw przyjaznych paczek" a potem dodawać do jakiegos zestawu przyjaznych paczek, skoro mogę pobrać te paczki z repozytorium.

Poza tym nie widzę znaczącej różnicy między Twoją propozycją a obecną implementacją - obie naruszają polityki i ułatwiają potencjalną penetrację systemu.

 

Co do instalacji bez klucza: "--nogpgcheck" jeśli mówimy o yum, bo rpm tylko wyrzuci ostrzeżenie.

Co do instalowania przez siostrę: nadaj jej uprawnienia "sudoersa" do określonych czynności.

 

P.S.Widziałeś pod postem przycisk [EDYTUJ]? To korzystaj z niego i nie pisz postów pod własnymi

[borzole]

Proponuje takie rozwiązanie.

Jeśli programu nie ma, to użytkownik może zainstalować program yum'em tylko na swoim koncie i ma na to ilość miejsca wyznaczone przez quote (?) konta. Czy to będzie w $HOME/usr czy w jakimś fikuśnym /usr/home/zenek (taki gupi przykład tylko).

Dlaczego tego rozwiązania nigdzie się nie spotyka? Skoro mogę instalować tak programy ze źródeł to czemu nie można użyć wbudowanego yuma?

[notgnucy]

Miałem na myśli coś całkiem innego. Udawanie się na stronę, to tylko późniejsze rozszerzenie.

 

Miałem na myśli możliwość oznaczenia paczek, jako zaufane bez dodawania klucza, a także bez instalacji.'

 

Potem system może automatycznie zainstalować dany pakiet, jeśli będzie to potrzebne. Można to nawet tak skonfigurować, by już niepotrzebny pakiet był usuwany, np. po wylogowaniu się użytkownika, który dokonał instalacji.

 

Siostrze mógłbym dać jedynie prawa do instalacji gier z repozytorium dla gier. Jak przy pomocy sudoers to osiągnąć?

---- łączenie postów ----

Proponuje takie rozwiązanie.

Jeśli programu nie ma, to użytkownik może zainstalować program yum'em tylko na swoim koncie i ma na to ilość miejsca wyznaczone przez quote (?) konta. Czy to będzie w $HOME/usr czy w jakimś fikuśnym /usr/home/zenek (taki gupi przykład tylko).

Dlaczego tego rozwiązania nigdzie się nie spotyka? Skoro mogę instalować tak programy ze źródeł to czemu nie można użyć wbudowanego yuma?

 

 

Tutaj już dochodzimy do kwestii bezpieczeństwa. Ogólnie, to uruchamianie programów portable, własnoręczna kompilacja, itd. powinny zostać zabronione. Przydałoby się użyć jakiegoś stosowego systemu plików lub dać możliwość zmiany atrybutów pliku jedynie w pamięci operacyjnej. Dodatkowo program ld powinien też być jakoś zabezpieczony. Wtedy mielibyśmy pewność, że użytkownik nie uruchomi niczego niezaufanego.

 

Scenariusz taki:

1. Użytkownik chce uruchomić ELF-a z pomocą Nautilusa.

2. Nautilus widzi, że to ELF, jednak bez prawa wykonywania, więc prosi demona o odpowiednich uprawnieniach o nadanie bitu wykonywalności.

3. Demon odmawia, więc Nautilus chce uzyskać prawo do nadania tego bitu, dzięki PolicyKit.

 

Ale to już inne tematy.

Edytowane Grudzień 5, 2009 przez WalDo
łączenie postów. Następnym razem zablokuję Ci możliwość pisania postów.

[borzole]

Siostrze mógłbym dać jedynie prawa do instalacji gier z repozytorium dla gier. Jak przy pomocy sudoers to osiągnąć?

nie da się.

SUDO nie pozwala na tak szczegółową konfigurację. To pozwala na ustalenie dostępu do urządzeń, programów a Ty chcesz skonfigurować szczególny przypadek dostępu do programu. Może PolicyKit coś takiego robi, sudo na pewno nie. Poza tym instalacja gry może wymagać zależności z zupełnie innej grupy i co wówczas? A jak jakaś gra ma w zależnościach 3/4 repozytorium to też ok?

Zaznaczanie gdzieś na jakiejś stronie co jest dozwolone a co nie... poza tym samym problemem z zależnościami to jest jeszcze problemem sama ilość tych paczek. Tego jest tysiące i myślisz, że komuś się będzie chciało ustalać reguły instalacji dla tysięcy paczek? Przemyśl ten swój pomysł jeszcze.

W ogóle te pomysły są bez sensu, po to wymyślono konto root by zwykły user nie mógł nic w systemie zmieniać, a jedynie go używać.

 

[EDIT]

Ogólnie, to uruchamianie programów portable, własnoręczna kompilacja, itd. powinny zostać zabronione.

Chyba bym się pochlastał jakbym po napisaniu każdego skryptu, skompilowaniu każdego "hello world" w c musiał wykonywać Twoje akrobacje rodem z zabezpieczeń serwerowych. To w końcu chcesz ułatwić sobie życie, czy utrudnić.

ps. wystarczy "noexec" w fstab do tego co mówisz

[notgnucy]

nie da się.

SUDO nie pozwala na tak szczegółową konfigurację. To pozwala na ustalenie dostępu do urządzeń, programów a Ty chcesz skonfigurować szczególny przypadek dostępu do programu. Może PolicyKit coś takiego robi, sudo na pewno nie. Poza tym instalacja gry może wymagać zależności z zupełnie innej grupy i co wówczas? A jak jakaś gra ma w zależnościach 3/4 repozytorium to też ok?

Zaznaczanie gdzieś na jakiejś stronie co jest dozwolone a co nie... poza tym samym problemem z zależnościami to jest jeszcze problemem sama ilość tych paczek. Tego jest tysiące i myślisz, że komuś się będzie chciało ustalać reguły instalacji dla tysięcy paczek? Przemyśl ten swój pomysł jeszcze.

W ogóle te pomysły są bez sensu, po to wymyślono konto root by zwykły user nie mógł nic w systemie zmieniać, a jedynie go używać.

 

[EDIT]

Chyba bym się pochlastał jakbym po napisaniu każdego skryptu, skompilowaniu każdego "hello world" w c musiał wykonywać Twoje akrobacje rodem z zabezpieczeń serwerowych. To w końcu chcesz ułatwić sobie życie, czy utrudnić.

ps. wystarczy "noexec" w fstab do tego co mówisz

Całkowicie się zgadza. Najogólniej NOEXEC powinno wystarczyć. Jest tylko jedne mankament... Jak użytkownik będzie uruchamiać sobie skróty? Ostatnio one też mają atrybut wykonywalności. I przy dużym samozaparciu nawet noexec, przy sprzyjających warunkach da się obejść(np. z pomocą ld).

[dj_oko]

To, co sugerujesz, o ile ktoś stwierdzi, że jest w ogóle warte zachodu, zaimplementowałbym jako rozszerzenie PolicyKita, który rozdaje bilety na instalację nie samych pakietów, tylko pakietów wedle ich typów, które(z racji nieobecności w RPM) byłyby oznaczane jakoś przez PackageKita.

 

Jednakże jest to konfiguracja tak bardzo szczegółowa, że bardzo rzadko znajdzie chętnych do skorzystania z niej. W przypadku skrajania systemu aż tak bardzo na miarę, po prostu na sztywno zakazuje się szeregu rzeczy i ma się spokój.

 

Utrzymywanie rozszczegółowionego frameworka jest trudne. Przykładem jest PolicyKit, którego aplet konfiguracyjny był tak męczący w implementaci i QA'owaniu, że go porzucono, dając opcję - "nowy, wspaniały durny wynalazek w trayu rodem z 2002 roku" lub też "ręczna edycja miliona XMLi". Ale to się wkrótce(w nowym releasie?) ma zmienić.