Forum Debian Users Gang

Pavlo950 · 2012-05-26 22:45:54

Witam!

Chciałbym uniemożliwić wykonanie następującego polecenia: "sudo su root", z tego względu, że w tym przypadku wymagane jest jedynie hasło użytkownika, z którego jest polecenie wykonywane. Jak to zrobić?

ArnVaker · 2012-05-26 23:12:33

A jak obecnie masz to sudo skonfigurowane? Bo jeśli masz tak jak w Ubuntu, to po co wyłączać możliwość zalogowania się w ten sposób na roota, skoro via sudo na haśle użytkownika i tak jest dostęp do wszystkich innych poleceń z uprawnieniami administratora?

===============

Z tego co widzę, w /etc/sudoers jest wpis (przynajmniej w testingu jest):

Kod:

# Allow members of group sudo to execute any command
%sudo    ALL=(ALL:ALL) ALL

Czyli użytkownicy będący w grupie sudo mają możliwość wykonania każdego polecenia z uprawnieniami administratora (tak jak w Ubuntu).

Żeby odebrać im tę możliwość wystarczy usunąć ich z grupy sudo:

Kod:

sudo passwd (ustawienie hasła roota)
sudo gpasswd -d nazwa_użytkownika sudo (usunięcie użytkownika z grupy sudo)

Wtedy żeby wykonać coś z uprawnieniami administratora trzeba będzie się zalogować na konto roota (root musi mieć ustawione hasło!).

===============

W drugą stronę (czyli z normalnego konta roota na uprawnienia via sudo) też łatwo przejść:

Kod:

gpasswd -a nazwa_użytkownika sudo (dodanie użytkownika do grupy sudo)
passwd -l root (zablokowanie hasła roota)

I już jest tak jak w Ubuntu.

Minio · 2012-05-27 00:08:42

PavloAkaLogan napisał(-a):
Chciałbym uniemożliwić wykonanie następującego polecenia: "sudo su root"

Kod:

sudo bash

Kod:

sudo vim # a potem ":! /bin/bash"

Twój pomysł jest zły, ponieważ w rzeczywistości daje on praktycznie zerową obronę. Sprawny użytkownik będzie potrafił uzyskać dostęp do powłoki nawet przy bardzo podstawowym zestawie narzędzi. Tak więc zamiast polityki „dozwolone jest wszystko oprócz tego, co zabronione” lepiej idź w stronę „zabronione jest wszystko oprócz tego, co dozwolone” — użytkownikom dasz dostęp jedynie do tych narzędzi administracyjnych, które są im absolutnie niezbędne (czytaj: żadnych) i o których wiesz, że nie umożliwiają ucieczki do powłoki.

dominbik · 2012-05-27 10:30:24

np.

Kod:

sudo nano /etc/sudoers

i znów by sobie sudo su przywrócił. u mnie też każdy może wykonać każdą komendę przez sudo, lecz komendy niezdefiniowane w sudoers - musi znać hasło roota; opcja

Kod:

Defaults    rootpw

Minio · 2012-05-27 10:35:13

dominbik napisał(-a):
np.
Kod:
sudo nano /etc/sudoers
i znów by sobie sudo su przywrócił.

W sumie to nie, ale dobrze kombinujesz:

Kod:

ls -lah /etc/sudoers
-r--r----- 1 root root 669 sty 31 00:47 /etc/sudoers

Jacekalex · 2012-05-27 14:45:51

Jakby ktoś chciał się pobawić SELINUX'em, i ustawić prawa do /etc/sudoers tylko dla contextu root, to da się zrobić.
Wejście na roota przez sudo nie zmienia contextu użytkownika, co powoduje, że poza zalogowaniem, bardzo niewiele może taki pacjent zrobić.
Trochę, jakby strzelać z armaty do wróbla, ale na serwerach, gdzie pojawiają się rozmaici dowcipnisie, właśnie tak się to załatwia. ;)

Sznurki:
http://pl.wikipedia.org/wiki/Security-Enhanced_Linux
http://wiki.debian.org/SELinux
http://www.gentoo.org/proj/pl/hardened/selinux/selinux-handbook.xml

Jakby ktoś chciał sie pobawić ACL Grsecurity, to też nie jest jakiś straszny problem. ;)

Pozdrawiam
;-)

Ostatnio edytowany przez Jacekalex (2012-05-27 15:08:48)

Minio · 2012-05-27 15:16:12

Jacekalex napisał(-a):
Jakby ktoś chciał się pobawić SELINUX'em, i ustawić prawa do /etc/sudoers tylko dla contextu root, to da się zrobić.
Wejście na roota przez sudo nie zmienia contextu użytkownika, co powoduje, że poza zalogowaniem, bardzo niewiele może taki pacjent zrobić.
Trochę, jakby strzelać z armaty do wróbla, ale na serwerach, gdzie pojawiają się rozmaici dowcipnisie, właśnie tak się to załatwia. ;)

Na serwerach, gdzie pojawiają się rozmaici dowcipnisie, daje im się dostęp do sudo i przy pomocy SELinuksa kombinuje, żeby tak naprawdę z tego dostępu nie mogli korzystać?

Jacekalex · 2012-05-27 15:42:46

Nie.

Mam na myśli to, że sudoers ma pewien ograniczony zakres możliwości konfiguracyjnych.
Natomiast systemami ACL dostępnymi w Grsec/Selinux/Apparmor możesz ustawić praktyczneie dowolny zakres uprawnień, jaki jest Ci potrzebny.

Co do samego sudo, to zazwyczaj albo daje się go komuś z dobrodziejstwem inwentarza, albo nie daje się w ogóle takiego dostępu.

Ja, jakbym miał kombinować, jak komuś dać w sudo dostęp do Synaptica, ale nia dawać dostępu do powłoki, to osoiście zastanowiłbym się, czy rzeźbić w jakimś ACL, czy w sudoers.

Zwłaszcza, że jak ktoś "fachowo" obetnie sudo, to to samo musi zrobić z su i z su-to-root, także zamiast czarować, prościej jest albo zabrać dostęp do takich zabawek przez grupy, albo zastosować ACL.

Kiedy miałem przed nosem SUSE - to tam do sudo potrzebne było hasło roota.
IMHO niegłupie rozwiązanie, ale w żaden sposób nie wyjaśniające problemu Autora wątku.

Pozdrawiam

Ostatnio edytowany przez Jacekalex (2012-05-27 15:44:28)

Pavlo950 · 2012-05-27 23:17:31

@ArnVaker
Dla siebie nie mam ustawionego hasła (bo de facto nikt do mojego konta dostępu nie ma), znaczy się opcja NOPASSWD:ALL. Wszyscy inni użytkownicy mogą wykonywać jako root ze swoim hasłem.

Tak odnośnie o tym co powiedział Jacekalex o SUSE'ie, to w jaki sposób wymusić hasło root'a zamiast hasła użytkownika, który próbuje coś wykombinować z sudo?
"su -c" i "su-to-root" od biedy mogły zastąpić mi sudo, jednakże sudo jest wygodniejsze dla mnie ze względu na możliwość odpalenia aplikację na X'ach i wklepywanie z autouzupełnieniem.

Jacekalex · 2012-05-28 01:03:05

PavloAkaLogan napisał(-a):
......

Tak odnośnie o tym co powiedział Jacekalex o SUSE'ie, to w jaki sposób wymusić hasło root'a zamiast hasła użytkownika, który próbuje coś wykombinować z sudo?
"su -c" i "su-to-root" od biedy mogły zastąpić mi sudo, jednakże sudo jest wygodniejsze dla mnie ze względu na możliwość odpalenia aplikację na X'ach i wklepywanie z autouzupełnieniem.

Właśnie z ciekawości sciągnąłem paczkę sudo z SUSE, i w konfigu sudoers znalazłem taką linię:

Kod:

Defaults targetpw   # ask for the password of the target user i.e. root

Inna sprawa, że działanie takiego konfigu nie różni się znacząco od zablokowania userowi dostępu do sudo przez wywalenie go z grupy sudo/wheel - w zależności od dystrybucji.

Jeśli zabezpieczysz sudo - to tak samo musisz zabezpieczyć i skonfigurować su i su-to-root (albo wywalić), żeby to miało jakikolwiek sens.

Pozdrawiam
;-)

Ostatnio edytowany przez Jacekalex (2012-05-28 01:04:43)

dominbik · 2012-05-28 12:37:51

że zacytuję sam siebie;

dominbik napisał(-a):
wykonać każdą komendę przez sudo, lecz komendy niezdefiniowane w sudoers - musi znać hasło roota; opcja
Kod:
Defaults    rootpw

+ niektóre komendy sobie dodać bez hasła. na desktopowe instalacje w pełni wystarczające i sądzę, że bezpieczne.

Ostatnio edytowany przez dominbik (2012-05-28 12:38:14)

Pavlo950 · 2012-05-28 19:36:39

Dziękuję, mniej więcej osiągnąłem taki efekt, jaki oczekiwałem.

Że tak, zapytam jeszcze o dwie rzeczy.

1. Gdzie modyfikuje się, aby hasła nie zapamiętywało?
2. Co robi opcja "env_reset"? Z tego, co pisze w manualu (okolice line 378) to resetuje jakieś "środowisko", ale nie wiem do końca o co chodzi. O co chodzi?

Ostatnio edytowany przez PavloAkaLogan (2012-05-28 19:38:02)

dominbik · 2012-05-28 19:53:43

1. bodajże

Kod:

Defaults timestamp_timeout=0

2. nie wiem

Pavlo950 · 2012-05-28 20:15:06

@dominbik
Dzięki.

Ostatnio edytowany przez PavloAkaLogan (2012-05-28 20:20:51)

Minio · 2012-05-28 21:20:53

PavloAkaLogan napisał(-a):
2. Co robi opcja "env_reset"? Z tego, co pisze w manualu (okolice line 378) to resetuje jakieś "środowisko", ale nie wiem do końca o co chodzi. O co chodzi?

O zmienne środowiskowe. Masz ich bardzo dużo, niektóre bardziej, a inne mniej przydatne. Możesz sobie zobaczyć poleceniem env.
Generalnie ustawianie zmiennych środowiskowych na wartości użytkownika docelowego jest tym, co chcesz zrobić, ale istnieją pewne wyjątki od tej reguły. Dlatego właśnie jest to opcja, a nie działanie wpisane na sztywno w kod źródłowy.

Forum Debian Users Gang

Ogłoszenie

#1 2012-05-26 22:45:54

Pavlo950 - człowiek pasjonat :D

"sudo" - uniemożliwienia wykonania polecenia.

#2 2012-05-26 23:12:33

ArnVaker - Kapelusznik

Re: "sudo" - uniemożliwienia wykonania polecenia.

Kod:

Kod:

Kod:

#3 2012-05-27 00:08:42

Minio - Użyszkodnik

Re: "sudo" - uniemożliwienia wykonania polecenia.

PavloAkaLogan napisał(-a):

Kod:

Kod:

#4 2012-05-27 10:30:24

dominbik - Członek DUG

Re: "sudo" - uniemożliwienia wykonania polecenia.

Kod:

Kod:

#5 2012-05-27 10:35:13

Minio - Użyszkodnik

Re: "sudo" - uniemożliwienia wykonania polecenia.

dominbik napisał(-a):

Kod:

Kod:

#6 2012-05-27 14:45:51

Jacekalex - Podobno człowiek...;)

Re: "sudo" - uniemożliwienia wykonania polecenia.

#7 2012-05-27 15:16:12

Minio - Użyszkodnik

Re: "sudo" - uniemożliwienia wykonania polecenia.

Jacekalex napisał(-a):

#8 2012-05-27 15:42:46

Jacekalex - Podobno człowiek...;)

Re: "sudo" - uniemożliwienia wykonania polecenia.

#9 2012-05-27 23:17:31

Pavlo950 - człowiek pasjonat :D

Re: "sudo" - uniemożliwienia wykonania polecenia.

#10 2012-05-28 01:03:05

Jacekalex - Podobno człowiek...;)

Re: "sudo" - uniemożliwienia wykonania polecenia.

PavloAkaLogan napisał(-a):

Kod:

#11 2012-05-28 12:37:51

dominbik - Członek DUG

Re: "sudo" - uniemożliwienia wykonania polecenia.

dominbik napisał(-a):

Kod:

#12 2012-05-28 19:36:39

Pavlo950 - człowiek pasjonat :D

Re: "sudo" - uniemożliwienia wykonania polecenia.

#13 2012-05-28 19:53:43

dominbik - Członek DUG

Re: "sudo" - uniemożliwienia wykonania polecenia.

Kod:

#14 2012-05-28 20:15:06

Pavlo950 - człowiek pasjonat :D

Re: "sudo" - uniemożliwienia wykonania polecenia.

#15 2012-05-28 21:20:53

Minio - Użyszkodnik

Re: "sudo" - uniemożliwienia wykonania polecenia.

PavloAkaLogan napisał(-a):

Stopka forum