Ubuntu Server Edition: root password beállítás ajánlott

Még régebben kérdeztem a sudo kapcsán, hogy ha bootoláskor az /etc/init.d/checkfs.sh nem találja rendben valamelyik partíciót és fsck nem tudja magától javítani, akkor kapok-e egy root shellt ingyen (sec. hole).

A válasz igen volt, de most gondoltam kipróbálom az új Ubuntu 7.04-ben.

Alap szervert telepítettem, telepítés után a következő mókás időkapu fogad:

A boot befejeztével van egy bosszantó dolog az upstart miatt, ugyanis a login után még indulnak el daemonok (szolgáltatások windowsul)

egy Enter-el kapjuk vissza a promptunkat

Ahhoz, hogy kipróbáljuk kapunk-e jelszó nélkül root shellt, rontsunk el egy partíció bejegyzést

sudo works as designed, vagyis ha nincs root jelszó beállítva, egy ilyen alkalommal root hozzáférést kaphatunk. figyeljük meg a $PATH tartalmát!

a már említett /etc/init.d/checkfs.sh handle_failed_fsck() függvénye indít egy sulogin-t

de szerintem ez már egy bug, hogy a shell indítófájlja (ezt mondd ki Leila fájlja, sic!) nem tud programokat indítani mert a $PATH (lásd 5. kép) nincsen rendesen beállítva a checkfs.sh-ban

a következő kép azt mutatja, amikor már mindent elintéztünk megnézzük milyen futási szinten vagyunk. Ez ismeretlen, merthogy még a boot folyamat közepén vagyunk...

...és ha CTRL+D-vel kilépünk -ahogy az elején ígérte- folytatódik a bootolás (a már ismert login prompt utáni daemon indítással)

nézzük meg a shadow fájlban a rootnak mi van megadva? ! jelenti a felhasználó lock-olását, sima userként sudo nélkül nem is tudunk rá su-zni. Megjegyzem normális rendszeren (pl FreeBSD) amúgy se tudnánk, ha nem vagyunk bent a wheel groupban. Állítsunk password-öt a rootnak, így már a sulogin kérni fog password-öt.

Az előző képen a user nem adhat ki sulogint, de természetesen a sudo sulogin már megy neki és ha van passwordje a rootnak akkor nem kapunk illetéktelen hozzáférést a szerverünkhöz.

Következő képünk a checkfs.sh PATH beállítását mutatja, amit ha megváltoztatnak az Ubuntu fejlesztők, akkor nem fog hibaüzeneteket kiírni suloginkor a shell. Egyébként nem tudom, hogy az a logika áll-e mögötte, hogy ha nincs PATH-on az /usr/bin/passwd akkor nem tudja a "betörő" megváltoztatni egy passwd parancs kiadásával a root jelszót, hiszen elé lehet írni az elérési utat (most arról nem beszélünk, h mi a helyzet ha a /usr partíció sérült meg ;-)

Utolsó két képünk egy érdekes szolgáltatást mutat be, miszerint az /etc/bash.bashrc -be beledrótoztak egy újdonságot, ami minden parancskiadáskor lefut, nevezetesen ha olyan parancsot adunk ki amit a rendszer nem ismer, de tudná telepíteni, akkor megmondja hogyan tehetjük meg ezt.

Ám ennek ára van, minden parancskiadáskor amikor a speckó debian bash beépített felüldefiniálható függvénye (command_not_found_handle, lásd hozzászólásokban) 127-et ad vissza, le kell futtatnunk egy oldalnyi (27 sor) futáskor értelmezett (interperetált) python scriptet.

Ez sztem addig hasznos amíg felépítünk egy rendszert, utána érdemes kikommentezni.

Végszó: jó dolog a sudo, de szerveren állítsunk a root-nak password-öt.

ui.: és ne felejtsük el a /etc/pam.d/su -ban beállítani, hogy csak wheel csoport su-zhasson, ne minden boldog-boldogtalan! (ehhez ubuntun egy groupadd wheel is kelleni fog..)

( sz | 2007. 04. 21., szo – 17:24 )

"Ám ennek ára van, minden parancskiadáskor le kell futtatnunk egy oldalnyi (27 sor) futáskor értelmezett (interperetált) python scriptet."

IMHO nem minden parancskiadáskor, hanem csak akkor, ha az adott parancs nem található, de jóval több mint 27 sor python kódot, mert van ott némi import is...

Nem feltétlen. Legrosszabb esetbe az első import után már bytecode képződik az importált dolgokból, ergo azon már nem megy végig a interpreter mégegyszer. Gyakori azonban, hogy a telepítéskor compilálnak bytecode-t mert akkor utána többé nem kell. Persze magát a scriptet nem lehet compilálni, sajna.

Dede, de én nem is arra mondtam. Felettem utaltak arra, hogy a import modulokon is végig kell menni a interpreternek. Erre mondtam azt, hogy nem, mert legrosszabb esetben a script első fellövésekor leforognak az importált modulok, ergo valóban csak a scripten megy át a python interpreter.

valóban nem mindig, viszont nekem gentoo bash-ben pl nincs is ilyenem: 

command_not_found_handle
              The name of a shell function to be called if a command cannot be
              found.  The  return  value  of this function should be 0, if the
              command is available after execution of the function,  otherwise
              127  (EX_NOTFOUND).  Enabled only in interactive, non POSIX mode
              shells. This is a Debian extension.

sőt cygwin alatt sincs pedig a verziók: 

joe@gentoo ~ $ bash --version
GNU bash, version 3.1.17(1)-release (i686-pc-linux-gnu)
Copyright (C) 2005 Free Software Foundation, Inc.

$ bash --version
GNU bash, version 3.2.15(13)-release (i686-pc-cygwin)
Copyright (C) 2005 Free Software Foundation, Inc.

joe@ubuntu:~$ bash --version
GNU bash, version 3.2.13(1)-release (i486-pc-linux-gnu)
Copyright (C) 2005 Free Software Foundation, Inc.

( Replaced | 2007. 04. 21., szo – 23:36 )

ehh, gyomorforgato :/

ui.: az csak nekem vicces, hogy "you can install apt-get by apt-get install apt"? :)

--
The Internet has evolved from smart people in front of dumb terminals to dumb people in front of smart terminals.