[MEGOLDVA] Elszúrt sudoers file CentOS szerveren

Linux-kezdő

Sziasztok,

Játszottam egy CentOS szerverrel és elszúrtam a sudoers filet (hülye voltam és a visudo helyett a nano /etc/sudoers parancsot használtam).

Most ha valamit csinálni akarok, akkor ezt a hibát kapom:

[ncsupka@czpr-vps ~]$ sudo nano
sudo: >>> /etc/sudoers: syntax error near line 102 <<<
sudo: parse error in /etc/sudoers near line 102
sudo: no valid sudoers sources found, quitting
sudo: unable to initialize policy plugin

Van valami megoldás, amivel helyretudom hozni, vagy single-user módban kell elindítanom a szervert és úgy kijavítani?

Előre is köszönöm a segítségeteket!

FRISSÍTVE:

Bebootoltam single-user módban, utána javítottam az /etc/sudoers fájlt, root jelszó megváltoztatva. Öröm van és bodóttá' Köszi mindenkinek a segítséget! (Mostantól csak visudo-t használok...)

  • 6578 megtekintés

Ez nem biztonsági rés, teljesen direkt van így. Sőt nem csak a single, de mondjuk ha van fent egy bash, akkor azt is megteszi neked ezt a szívességet (init=/bin/bash a végére. Ha olyan kívánalmaknak kell megfelelni, hogy a lokálisan (vagy a gép ellopásával) se lehessen "feltörni", akkor ott van a LUKS meg a grub-ra is tehetsz el jelszót.

FathoM

Ha fizikailag hozzáférsz egy géphez, akkor a rajta futó os nem tudja megvédeni magát (hacsak az egész adathalmaz nincs titkosítva). Kiveheted, máshonnan bebootolhatod, vagy egyszerűen csak máshonnan futtathatsz egy initet (lásd init=/bin/bash pl)

Egyébként igazából hatos redhatban upstart van, így kezdődik az inittab: 


# inittab is only used by upstart for the default runlevel.
#
# ADDING OTHER CONFIGURATION HERE WILL HAVE NO EFFECT ON YOUR SYSTEM.

és tényleg annyi is van benne, hogy 

id:5:initdefault:

Hetesben meg systemd, ott 


# inittab is no longer used when using systemd.
#
# ADDING CONFIGURATION HERE WILL HAVE NO EFFECT ON YOUR SYSTEM.

és tényleg.

( pirate | 2015. 03. 09., h – 15:59 )

$ su -
# sudoers javit
örül :)

(gondolom tudod a root jelszót ha tudod szerkeszteni az /etc/sudoers-t)

---
"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."

Pont egy ceges VPS-nel lenne nagyon fontos tudni a root jelszot (akar lezart boritek valahol).
Ez nem tul nyero igy. A control panel-es probat erdemes lehet megcsinalni amit javasoltak.
Gondolom a backup-bol visszaallitas sem jatszik, mivel nincs backup.

---
"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."

( siposa v | 2015. 03. 09., h – 16:11 )

1) Leszeded a megfelelő sudo csomag RPM fájlját, pl. innen, ezen belül .../{CentOS verzió}/os/{architektúra}/Packages/

2) mc-vel megnyitod, és kimásolod belőle a sudoers-t

3) A tartalmát beletolod az etc-ben lévő elrontott fájlba (így nem változnak meg a jogosultsági beállításai):
# cat /home/csupka91/tmp/sudoers >/etc/sudoers

A sudoers nem arra szolgal, hogy kontrollalt root (vagy mas user) hozzaferest adjunk nem root usereknek?
Eleg gaz, ha valaki aki nem root csak ugy szerkesztheti a file-t es tobb jogot ad maganak mint amit kapott a root-tol :)

---
"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."

Nem gáz ez, hanem *nix, céges poliszivel: van egy root pwd, amelyre érvényesül (vagy nem), hogy there can be only one, és vannak a sudoval felmagasztaltak, akik ugyanúgy elcseszhetnek mindent, mint a Kiválasztott, csak a távolra írt logok átnyálazása után kukoricán térdepelve írják le százszor a tanulságot (kopipészt kizárva).

Hát ha sudo -e /etc/sudoers volt, akkor kilépni már kilépett, és van olyan beállítás, ami mellett nem triviális elenőrizni, hogy mennyire szúrta el. Szóval a lentebb emlegetett visudo egy fokkal biztonságosabb, annak meg ugye az a baja, hogy átlag rendszergazda kilépni se tud a vi-ból, amit a visudo használ :-)
(Mondjuk én már állítottam át úgy túzfal szabályt, hogy hiába nem léptem ki az adott sessionből, attól már nem nagyon volt lehetőségem módosítani. Szerencsére a szomszédban volt a szerverszoba.)

Az egy kissé paradox vagy tudathasadt, vagy nem is tudom milyen állapot, hogy a modernre guizott disztribeknek úgy lett a sudo a megkerülhetetlen parancsuk, hogy közben a vi, vagy jobb (?) esetben a nano lett az alapértelmezett editor, és a minta sudoers nincs kiegészítve azzal a kommenttel (pontosabban: én még nem láttam olyat) a nullkilométeresek számára, hogy milyen egyszerű lépésekkel érezhetnék magukat kevésbé szerencsétlennek is.

A visudo manual szerint csak spéci fordítási opciók hatására veszi figyelembe az EDITOR változót :-) Engem mondjuk nem hat meg, jellemzően sudo -e /fa/jl/nev formával kezelem ( és persze EDITOR=vi ), ha egyáltalán kell - bár a napokban futottam bele egy olyan rendszerbe, ahol ez nem működött, ezért kénytelen voltam kissé trükközni :-(

Ha ilyen félelmeid vannak, hadd javasoljak valamit!

Elteszel a gépen biztos helyre egy mentést egy/a működő sudoers fájlodból.
Írsz egy cron jobot a rootnak, ami figyeli, hogy a saját $HOME-od egy sajátosan elnevezett könyvtárában megjelenik-e egy sajátosan elnevezett fájl. Ha igen, visszamásolja a minimál sudoerst.

Persze csak akkor, ha nincs nálad rendszergazdibb, aki ezért meghúzná a füledet.

"Ha ilyen félelmeid vannak, hadd javasoljak valamit!

Elteszel a gépen biztos helyre egy mentést egy/a működő sudoers fájlodból.
Írsz egy cron jobot a rootnak, ami figyeli, hogy a saját $HOME-od egy sajátosan elnevezett könyvtárában megjelenik-e egy sajátosan elnevezett fájl. Ha igen, visszamásolja a minimál sudoerst.

Persze csak akkor, ha nincs nálad rendszergazdibb, aki ezért meghúzná a füledet."

No offense de ez már too much szerintem.
visudoval kell szerkeszteni, odafigyelni aztán jónapot.
Ajánlom 3x átnézni amúgy a sudoers-t mielőtt menti, és azután is lepróbálni, és nincs para (sokéves tapasztalat)...

---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

Azért a fenti helyzetben - szintaktikai hibát sikerült ejtenem a sudoersben" - kb lényegtelen, hogy milyen szövegszerkesztőt és milyen üzemmódban használ az ember. A javasolt visudo lényege - szerintem - az, hogy "provides basic sanity checks, and checks for parse errors" (idézet a visudo manuálból). Azaz remélhetőleg nem tudja a drágalátos felhaználó elbaszni a konfigot, mert mielőtt felülírná az élest egy hibással, a visudo visszaugat neki. (Az meg, hogy kinek melyik editorban könnyebb hibát ejteni, az nagy eséllyel a használati szokásokon múlik - van ugye aki Word-ben írt szövegekbe tesz egy :wq! -t.)

( md | 2015. 03. 10., k – 22:17 )

Végül is használhatod a nano-t, csak utána csekkold egy "visudo -c"-vel. (Már ha root vagy.)

( sany | 2015. 03. 10., k – 22:42 )

"...aztán csak visudo-t fogok használni."

Csak akkor lesz gond ha a "visudo" parancs nano-t indít. :)

Teljesen megfelelő a nano is csak a "-w" opciót ne feledd!

............
Tegnap nem csináltam semmit, ma folytatom, mert nem lettem kész vele! :)

Ha jobban megnézed, ő annak írta. Az első hozzászólás, amiben a visudo szerepelt, az pont tőle jött. Majd ezek után jöttél te és ragozod a "nano -w" -t, ami nem előzi meg a problémát, ellentétben a visudo-val. Ugyanis ha abból indulunk ki, hogy szintaktikai hibát vét, azt nano-ban is lehet, meg vi-ban is meg MS Word-ben is. Ha pedig nem vét hibát, azt ugyanúgy lehet mind a három fenti szerkesztővel. De a visudo ekkor is több ellenőrzést csinál, mint a nano.

( NevemTeve | 2015. 03. 12., cs – 10:42 )

Off: Tényleg látok itt némi sechole-gyanús részt: ha a usernek csak visudo-ra van joga, de másra nincs (mondjuk ez elég életszerűtlennek hangzik); és ő az EDITOR változót beállítja a /sbin/terminte_universe-ra, akkor a visudo megteszi neki azt a szívességet, hogy megállítja az univerzumot...

Idézve a manból:

"There is a hard-coded list of one or more editors that visudo will use set at compile-time that may be overridden via the editor sudoers Default variable. This list defaults to vi. Normally, visudo does not honor the VISUAL or EDITOR environment variables unless they contain an editor in the aforementioned editors list. However, if visudo is configured with the --with-env-editor option or the env_editor Default variable is set in sudoers, visudo will use any the editor defines by VISUAL or EDITOR. Note that this can be a security hole since it allows the user to execute any program they wish simply by setting VISUAL or EDITOR."

---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

Hogyne, de azért szeretném jobban érteni, hogy pontosan hogyan lépne fel a veszély...

1. valaki hozzáfér a root-user képernyőjéhez, és átállítja az EDITOR változót?
2. Van olyan mezei user, aki futtathat visudo-t, de egyébként korlátozottak a jogai, ő visszaélhet az EDITOR változóval?

ad1: ennél sokkal rosszabbakat is tehet, hamár...
ad2: ha futtathat visudo-t, akkor mi értelme arról beszélni, hogy korlátozottak a jogai?

Ja, és hogy mi lenne a megoldás: pl. ha a visudo a $EDITOR-t technikai userként futtatná?

Megint kiderült, hogy a pragmatizmusod érték, és hogy a mant nem csak olvasni kell, de kételkedni is benne.
Kipróbáltam a kéznél lévő disztribekkel és AIX-szel, és óvatoskodásnak nyomát se láttam: gyakorlatilag bármilyen állatságot forkol editorként a visudo, lehet az akár a true, a false, az rm is - legfeljebb nem tud mit kezdeni a végeredménnyel, illetve nem lát diffet a .tmp és az eredeti között, ezért nem ír felül.

A strings-zel csekkolva egyedül az ubuntu visudojában láttam editorok listáját, de az is csak default preferencia lesz, mert az is elhisz bármit EDITOR-nak, csak létezzen.