[A sorozat korábbi részei itt, itt és itt meg itt]
Az előző részhez hasonlóan, most is egy kis érdekességgel készültem. Viszonylag sok 1 napos villám Oracle auditot csinálunk mostanság itthon is és külföldön is. Az a mondás, hogy ilyenkor csak a legfontosabb dolgokat nézzük meg és mondunk hozzá okosságokat. Most találomra kiragadnám ezek közül az egyiket, mert ennek kapcsán előjön egy érdekesség, ami talán nem annyira közismert. (Ne feledjük kezdő DBA sapkában vagyunk - nyílván a szakma nagy öregjeinek ez is trivialitás lesz :-).)
Amiről szó lesz az pedig nem más, mint a fájlrendszer szintű jogosultságok. Magyarán az Oracle fontosabb fájljaihoz, illetve könyvtáraihoz kinek milyen szintű hozzáférést engedélyezzünk. Nyílván itt sem kell feltalálni a kereket, rengeteg leírás, ajánlás van, hogy x könyvtárra ilyen jogokat érdemes állítani az y fájlra pedig amolyat. Nem is ez az érdekes. Illetve azért de, ebben is van egy kis csavar, például nem mindig konzisztens a dolog, vannak eltérések az egyes ajánlások között, hogy akkor az oracle bináris (ami kétségkívül a legfontosabb fájlok egyike) 4755 vagy 4750, esetleg 4700 vagy 0700 jogosultságokat kapjon (ja igen, linuxos környezetről beszélünk, csak hogy egyszerűbb legyen :-). Rögtön egy kezdő linux admin beugratós kérdés: mi a franc az a 4-es a jogosultságok előtt (4755 vs. 755)? Ezt most itt nem lőném le, akinek a SUID és a SGID nem hangzik ismerősen, annak a tovább olvasás előtt fél oldalban a lényeg:
http://web.cecs.pdx.edu/~rootd/catdoc/guide/TheGuide_59.html
Persze nem véletlen hogy pont az oracle binárist rángattam elő példának, de nem lövöm le a poént előre, egyelőre nézzük meg milyen jogosultságokkal rendelkezik alapértelmezésben: -rwsr-s--x (oracle oinstall). Ez emberi nyelven 6751 ha jól számolom, pont nem találtam el egyik fenti példával sem :-).
Mi az amit ebből az ember józan paraszti/szekuriti ésszel lefaragna? Mi is ez? Az oracle binárisa, azt jó eséllyel az oracle felhasználó akarja indítgatni, tekergetni, az utolsó x-et mindenképp levenné az ember, sőt talán még az oinstall jogokat is nyugodt szívvel elvennénk, és akkor már a 4700 környékén vagyunk ugyebár. Viszont ha már elvettünk minden jogot mindenkitől, akkor a SUID-nak sincs értelme, azaz 0700 lenne a megoldás. Vagy mégsem?
Tulajdonképpen az esetek 98%-ban teljesen vállalható lenne a 0700, viszont van ennek a beállításnak egy érdekes mellékhatása. Tegyük fel, hogy be vagyok lépve a host OS-re, és onnan akarok kapcsolódni az alattam futó adatbázishoz:
$ sqlplus test/test
ERROR:
ORA-12546: TNS:permission denied
Enter user-name:
Viszont:
$ sqlplus test/test@db102test
SQL>
Vajon mi a különbség a két bejelentkezési kísérlet között?
Alapvetően teljesen más történik attól a kis @-os résztől. Az első esetben nem használunk @-ot (TNS connect stringet) és listenert sem. Ebben az esetben a kapcsolat közvetlenül az adatbázishoz vándorol és nem a „hivatalos” felhasználó - listener - adatbázis szentháromságot járja végig. A lokál OS-ről ugyanis ennyit lehet csalni, nem feltétlenül kell a listeneren keresztül bejelentkezni, sőt alapértelmezésben nem is akarja használni. Mit jelent ez? Az Oracle az ún. two-task architektúrát használja, azaz egy felhasználóhoz tartozik egy user process és egy server process, ezek ketten beszélgetnek egymással. Alapértelmezésben a felhasználók a listeneren keresztül beszélgetnek az adatbázissal, ekkor a listener indít nekik egy szerver processt, viszont ha kihagyjuk a listenert a dologból, akkor jobb híján a felhasználó akarna izzítani egy szerver folyamatot, amihez viszont kellene neki futtatási jog az oracle binárisra. Sőt, ez még nem is elég, SUID kellene neki, mert ha csak simán lenne egy x jog (701 mondjuk), az nem elég, mert akkor az oracle az ő nevében fog futni, az ő jogosultságaival, amivel nyílván nem fér hozzá semmihez.
Ellenben a második esetben attól a @-os résztől viszont megváltozik a dolog. Úgy kapcsolódik a felhasználó az adatbázishoz, mintha távolról jönne, így a listenerrel kezd el beszélgetni, amivel elegánsan megoldódik a fenti probléma.
Ez a különség nagyon szépen látszik a process listában is egyébként Ilyesmit kell látnunk, ha listeneren keresztül jön valaki: oracle 6428 1 0 13:20 ? 00:00:00 oracleDBA102TEST (LOCAL=NO)
Ilyet pedig ha közvetlenül kapcsolódik localhostról: oracle 6340 6339 0 13:06 ? 00:00:00 oracleDBA102 TEST(DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
Kis érdekesség a PROTOCOL=beq onnan jön, hogy az ilyen kapcsolatokat „bequeath connection”-nek nevezi az Oracle.
Az már egy másik érdekes kérdés persze, hogy local OS authentikációt használjunk vagy sem (nyílván az oracle felhasználó kivétel). Tudtok mondani olyan valós szituációt, amikor kell a local OS authentikáció (oracle useren kívül persze)?
