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...)
Hozzászólások
Live CD be, config javit, örül.
-------------------------
Dropbox refer: https://db.tt/V3RtXWLl
neut @ présház
Ez a legegyszerűbb.
> Sol omnibus lucet.
single user a legegyszerűbb, ott se cd nem kell, se mountolgatni.
inittab?
> Sol omnibus lucet.
Mi van vele? Tippre root nélkül nem tud hozzáférni. A root visszaadásának meg tényleg az a legegyszerűbb módja, hogy reboot, grub sorvégére odaírni, hogy single, aztán mikor megjött a prompt beírni, hogy passwd.
Ezt nem tudtam. Azt hittem az inittab az szentírás. Egyébként
ez egy hatalmas biztonsági rés. Megy ez lilo-val is?
> Sol omnibus lucet.
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
Kössz, ezeket nem tudtam.
> Sol omnibus lucet.
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:
és tényleg annyi is van benne, hogy
Hetesben meg systemd, ott
és tényleg.
Nem véletlenül találták ki a boot-, BIOS-, diszk- és bootloader-jelszót, a titkosított fájlrendszereken túl.
$ 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..."
Sajnos ez egy céges VPS és senki sem tudja a root jelszót, sudo su-val voltam mindig root.
Szolgáltatónál Control Panel van hozzá? Csak azért kérdem mert az én "Tesco gazdaságos" VPS-em CPANEL-jén is van "Set Root Password" a root pass megváltoztatására illetve "Serial Console" amin keresztül szintén lehet kapni root sessiont.
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..."
pkexec
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
Gondolom ha lenne rootja csak úgy simán, akkor tudná javítani kézzel :)
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..."
Épp ezt mondom :)
Nyilván, mielőtt a kolléga syntax hibát vétett volna a sudoersben, azelőtt annak segítségével lett root, hogy tudja csesztetni. Azután meg már nem tud az lenni, és emiatt nyilván nem megy a cat odafentről.
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).
Ez jo volt :)
A ceges policy-t ertem, de pont ilyen esetekre nem art ismerni a tenyleges root jelszot is...vagy olyankor mikor meg nincs sudo (konzolon belepni ha nem tud bootolni a szerver, stb.).
---
"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."
Persze, illik letenni azt jelszót egy (vagy több) kontrolláltan elérhető helyre.
Persze pénzszűkében, az alagsorban, a WC mögött elhelyezett irodahelyiségben, naponta megköpködve az embernek nem feltétlenül az etikett az legfőbb gondolata.
tru dat
Pedig ez az eset :), senki se tudja mi a root jelszó, de mindenkinek van saját felhasználóneve és teljes root jogosultsága, egy syntax hibát vétettem amikor egy új felhasználót hoztam létre...
Ha elszúrni volt joga, némi eséllyel javítani is van.
Jham, de akkor még jó volt a sudo.
Az igaz.
Annyi baj legyen: most már lesz valaki a cégnél, aki tökéletesen fogja tudni és hittel hirdetni, hogy miért nem nyúlunk direktben ahhoz, aminek azt írja a dokja, hogy ne nyúlj hozzá direktben.
Egy reboot nem is olyan kacifántos tanulási hurok.
Inkabb azt kell megtanulni, hogy addig nem lepunk ki a shellbol vagy az adott geprol, amig ki nem probaltuk az uj konfigot egy uj session kereteben. Egy tuzfal vagy PAM konfig elrontasa joval fajdalmasabb tud lenni.
No igen, illetve ahogy Lenin mondta: screen, screen, screen (persze lehet, hogy tmuxot mondott, csak elferdítette a szovjet történetírás).
ez is tru
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.
(Végül is, nem olyan ez, mintha be lehetne állítani egy környezeti változóban, hogy EDITOR=/usr/bin/mcedit vagy ilyesmi.)
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 :-(
De olyan ez, de - ahogy Zahy írja - nem biztos, hogy összejön, és a nagyobb gond az, hogy (mondom, mondern gui) nem sikk már tudni, hogy mi a fene az az EDITOR, meg VISUAL, SUDO_EDITORról nem is szólva.
+1
Attól függ, hol a hol a szerver, és van e valami remote console :)
Van remote console, ebből valószínűleg reboot lesz, csak azt nem tudom szépen hogyan lehet újraindítani, ugyanis a reboot-hoz is kell a sudo... :D
Ha már reboot, akkor chroot is beleférhet és aztcsinálsz amit akarsz.
passwd parancsot is kiadhatod! :)
............
Tegnap nem csináltam semmit, ma folytatom, mert nem lettem kész vele! :)
De ez tök fölösleges. Elindítod single userben, aztán javítod a sudoerst, kiadod a passwdt, akármit, teljesen felesleges emiatt cdrommmal szerencsétlenkedni, mountolni meg chrootolni.
+1
Single userhez nem kell root pass? Nem ismerem a centost. Ha meg kell, _és_ ismeri a root jelszót (ez kiderült már?) akkor kár ilyennel bűvészkedni, konzol, root login, vi(sudo), öröm, bódottá.
Ha meg nem ismeri, akkor nincs más mint a live cd.
Single usert nem tudom, de az
init=/bin/bashmint kernel paraméter kellene hogy működjön.nem kéri.
Single user = dos mode
mit szerettél volna mondani?
hogy hiányolja magát a #newtoday-ből
Sajnos nincs meg a root jelszó. Most kéri főnököm a jogosultságot, hogy legyen jogosultságom soros porton bütyködni a VPS-t. Első dolgom az lesz, hogy megváltoztatom a root jelszót hogyha esetleg ilyen történne megint...
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"
+1
Ahogyan működni fog a VPS normálisan csinálok egy backupot a VPS-ről, aztán csak visudo-t fogok használni.
Lesson learned.
good boy :)
persze, ez a BAU
Az valami rootkit?
Az ötlet szerintem egyáltalán nem olyan elrugaszkodott a valóságtól, AT&T nagyon hasonló megoldást használ (persze shared storage-al, meg egyéb dolgokkal, szóval nem csak erre jó).
FathoM
Ha van konzol, akkor jó eséllyel lesz ott mellette egy power gomb is a VPS admin panelen. Nyugi, szabályosan fogja leállítani, hacsak valaki nem csinált direkt vmi hülyeséget.
Csak legközelebbre: visudo
"Csak legközelebbre: visudo"
Jó a nano is, csak kell a "-w" opsön és nincs semmi gond!
Teljesen mindegy mivel szerkeszted, ha ismered az editort. :)
............
Tegnap nem csináltam semmit, ma folytatom, mert nem lettem kész vele! :)
... feltéve, hogy nem cseszed el a szintaxist...
Ez még gentoo doksijában volt anno, hogy a nano használata "-w" nélkül fájdalmas lehet. :)
Nem biztos hogy ő hibázott!
Csak a nano szeszélyeit nem ismerte. :)
............
Tegnap nem csináltam semmit, ma folytatom, mert nem lettem kész vele! :)
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.)
:wq!
Megtörtént :(
:x :)
Egy lehetséges megoldás: http://hup.hu/cikkek/20150310/a_dram__rowhammer_problema_kihasznalasa_k…
Keress egy root exploitot!
Végül is használhatod a nano-t, csak utána csekkold egy "visudo -c"-vel. (Már ha root vagy.)
"...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! :)
http://hup.hu/node/139252#comment-1845429
A visudo-nak nem a vi a lényege, hanem az, hogy ellenőrzi a képződmény szintaxisát, s amíg az hibás, nem engedi felülírni a még jó sudoers file-t.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Kérlek, ne atomjanizd szét a topicot. Nézz már utána, mi az a visudo, mielőtt hülyeséget írsz.
>hupu
>utánanézés
>hülyeség előtt
>ever
Lehet hülyeség, mert nem néztem utána a visudo-nak.
De nem én rontottam el a sudoers fájlt, annak ird, aki nem tud fájlt szerkeszteni! :)
És nem nézi meg mire üt entert.
Ende
............
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.
Ne tetézd :-(
Danke.
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"
Ezt olvastam, de ebből nem derül ki, hogy pl. az én konkrét rendszeremen hogyan megy. Próbálkozásaim:
Ezek szerint a te terjesztésed sudoers-ében engedélyezve van a visudo-val a tetszőleges editor. Igen, azt lehet veszélyesre konfigurálni. de ha te nem nyúltál hozzá, az a terjesztés készítőjének felelőssége :-)
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á?
Szerintem az ad2 miatt ez az egész csak vihar a biliben.
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.