Fórumok
Hi!
RHEL6-on kellene a root által futtatott processzeket (vagy legalábbis egyet mindenképpen) elrejteni a többi user elől.
Indoklás: a processz úgy fut, hogy az egyik paramétere egy jelszó és az így mindenki számára látható. Igen, ez ilyen. Igen, ez dobozos termék.
Van rá megoldás, ami nem igényel kernel újraforgatást, top és ps újraírást, stb?
Thx.
Hozzászólások
TOP és PS letiltása nem root felhasználóknak?
Az alkalmazás adminok meg dögöljenek meg, nem? :)
sudoers?
nem müxik: ugyanúgy ki tudja olvasni a /proc/PID/cmdline-ból
Igen van. Javitsd a szoftvert hogy valtoztassa meg a process nevet!
"Csakugyan! Ha szabad megjegyeznem, ön zseniális uram."
felek, hogy nem o lesz az egyetlen, aki nem fogja majd tudni ertelmezni az "Igen, ez dobozos termék." stringet
>> "Igen, ez dobozos termék."
és?
gyengéknek lefordítom:
nincs meg neki a forrása, így nem tudja újrafordítani.
gyengéktől újra kérdem: és?
ne legyél agyban gyér, nem ezt vártam tőled.
Bukod supportot, ha megpiszkalod.
Es bizonyara a nagy raklap penzt azert fizettek be.
Sot meg egy pert is kaphatsz a nyakadba a reverse enginering miatt.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
:(
és? :)
^like
ez perl-ben egyszerũ
$0=undef
de C-ben hogy oldom meg?
~~~~~~~~
http://www.youtube.com/watch?v=VbUVqODL1nE
ez tuti megcsinálja:
int main(int argc, char **argv)
{
int i;
...
for (i = 1; i < argc; i++) memset(argv[i], 0, strlen(argv[i]));
...
}
Itt is megmarad egy kis biztonsági rés, ami az az időtartam amíg a kernel betölti a program kódját és a folyamat eljut a main-ban a törlésig.
Feltéve, hogy meghagyod a password betöltésének eredeti módját...
Valaki más már írta, hogy azt kell csinálni, hogy ahonnan jön eredetileg a jelszó (valami indító script lehet), no oda valami fals dolgot kell beírni, azaz ne a valós jelszóval induljon a program, ellenben az LD_PRELOAD-os függvény töltse be valahonnan (mondjuk egy 0700-as fájlból), és a main() meghívása előtt cserélje ki - csak az argv pointert. Így a main() már a jó jelszót fogja használni, de az nem jelenik meg sehol...
Itt van. Nekem is működik.
a) attól, hogy más néven van, miért ne láthatnám? Legfeljebb más néven kell keresni/nehezebb mehtalálni azt, amelyik kell
b) és a program elindulás (proceszként megjelenése) és a megváltoztatás közti időben mi a francért ne láthatnám a ps-ben? Sima versenyhelyzet, elég sok példát lehet a neten találni arra, hogy az ilyen versenyhelyzet esetén milyen trükközéssel lehet kicsit az esélyeket jobban az én irányomba billenteni
OT: FreeBSD alatt van egy mac_seeotheruids nevű MAC modul, ami pont ilyesmire van kitalálva (nem tudom persze mennyire jól implementált), gondolom itt is valamilyen MAC-mechanizmus rá a megoldás, bár az itt emlegetett "kapcsold ki a selinuxot" eléggé nehezítő tényező :-)
Szerk: bocs, azért jelezném, hogy elvi szinten a javítsd ki a programot résszel amúgy egyetértek
A gyártó is érdekes, hogy vannak még ilyen "enterprájz" megoldások arrafelé is.
Mondjuk személyes kedvencem még mindig egy wines exebe beleheggesztett domain administrator jelszó volt, amit persze strings-szel ki lehet nyerni, ha össze tudod sakkozni, hogy Administrator utáni sorban vajon mi lehet.... És ez minden user gépén ott figyelt... Eleve esélytelen volt a domain admin jelszavát megváltoztatni. A SELinux egyébként működő megoldás lenne, hacsak az a fránya disable ott nem lenne.
Egyébként lehet fut ám azzal, miért ne futna, "csak" el akarják kerülni a "felesleges" support hívásokat, ahelyett, hogy profilt csináltak volna rá... gondolom nem a 2 Ft kategóriás alkalmazás.
Javítsa ki, aki gyártotta! Gondolom, ha pénzért vett programról van szó, akkor lehet bugreportolni is... mert ez bug, jobban mondva sechole.
Ez eddig okes, gondolom ment is rola PR, de addig is, amig fixaljak, nem biztos, hogy jo, ha vedtelenul marad az a gep...
--
prctl környékén keresgélnék...
pl: https://gist.github.com/1350729
Nem tudod megtenni egyszeruen, lasd:
http://stackoverflow.com/questions/3830823/hiding-secret-from-command-l…
Igen, ezt láttam.
Fáj, hogy 2012-ben egy ilyen funkció nem default vagy legalábbis nem kapcsolható ki-be akár user szinten.
Inkább annak kéne fájni, hogy ilyen sz@r az alkalmazás...
Szerintem erős döntetlen. :)
Jogos... :)
indíthatod a processzet úgy, hogy ./program --password=`showmypassword.sh`
ez nem fog menni... :)
(A showmypassword.sh kimenete szépen látszódni fog az elindított program argumentumaként)
mert?
Mit mert? Oda írtam. -> Mert oda írja, amikor leftu a show script.
sorry. de én azelőtt kérdeztem
- (sikerult ertelmeztem a kommented)
igen, bocs, a zárójeles részt utólag írtam bele, mert rájöttem, hogy informatívabb is lehettem volna, és kb 1 másodperccel hamarabb frissülhetett a hozzászólásom, mint ahogy te válaszoltál.
mert lefuttatja a belső scriptet (á la backtick operátor), behelyettesíti az értékét a helyére, s úgy futtatja le a külső parancsot.
Sajnos a showmypassword.sh kiértékelődik a jelszóra (pl. alma) és onnantól a process listában máris látszik, hogy "alma". :/
szerintem ahhoz meg kell patchelni a kernelt. hacsak nem olyan disztrót használsz amiben eleve van grsecurity v. talán selinux. bár nem tudom hogy ez utóbbival is meg lehet-e oldani:) de valamerre erre indulnék el.
RHEL6-ban nincs grsec :(
A SELinux sem csinálja default-ból, de beletúrok, hátha mégis képes lenne rá, de most már csak a kíváncsiság hajt, mert az adott alkalmazás Admin Gudie-ja úgy kezdődik, hogy "Disable SELinux". IBM termékről van egyébként szó...
+1
LOL
--
A legértékesebb idő a pillanat amelyben élsz.
http://phoenix-art.hanzo.hu/
https://sites.google.com/site/jupiter2005ster/
Bugreport az IBM-nek, es opcionalisan a tovabbiakban tartozkodni a gyartotol?
Egyebkent mi ez a program?
--
R2D2 a filmtörténet legmocskosabb szájú karaktere.
Minden szavát kisípolták.
ha meg lehet adni a jelszót konzolról, akkor próbáld meg expectel megadni
melyik termek? biztos vagyok benne, hogy kell lennie masik megoldasnak, ha ez egy mostani, up-to-date, supportalt termek.
Subscrible
A mysql konzolos szarjai mintha ezt kiütnék valahogy némely oprendszeren.
(ezt most csak így ideköhögtem, mert nincs időm utánanézni most...bocs)
szemely szerint lattam olyan C appot, ami parancssori kapcsolon keresztul kap szenzitiv adatot, de az alkalmazas felulirja az adott memoriareszt, es ezutan mar a top-ban/proc/PID/cmdline alatt is a felulirt ertek latszik.
ezen anno nagyon meglepodtem, marmint hogy ilyet lehet, de biztonsagi szempontbol tovabbra is aggalyos, hiszen van egy kis idoablak, amikor mar elindult a processz de meg nem futott le a rutin, ami kiuti a parancssorbol a szenzitiv adatot.
altalaban a parancssori alkalmazasoknal a kovetkezo megoldasokat lattam alkalmazni:
- az inditott processz olvas egy default/argumentumkent megadott config fajlt, ami tartalmazhatja a jelszot
- argumentumkent atadhato a jelszot tartalmazo fajl neve/eleresi utja
- stdin-en, vagy egyeb file descriptor-on keresztul pipeolhato a szenzitiv adat.
Tyrael
ha a processz mondjuk egy inet socket-es szerver szolgaltatas, akkor aka'r be is lehetne pl virtualizalni? es akkor a megfelelo portot okosan forwardolod itt-ott, es jo lesz. de ha persze ma'st csinal, akkor az egy fokkal nehezebb.
LD_PRELOAD-dal beletolni egy kis kódot a programba, ami indulás után átírja az argv[*] értékét (ezt mutatja a ps/top)?
igen, valami modja kell legyen ennek. pl a `screen` tipikusan nagy SCREEN ne'ven szokott futni a ps-ben es nyilvan ilyen binaris nincs. es ha azt irom be hogy `screen -ty -dzs -ku`, akkoris csak egy `SCREEN` latszik ott. szoval valoszinuleg megvan ennek a modja. es ugyanez a /proc/${PID}/cmdline tartalma is, szoval aka'r.
ez mukodhet, de imo nem tokeletes megoldas, a tamado meg mindig megnyerheto a versenyt, hogy az inditas utan, de a feluliras elott olvassa ki az argumentum erteket.
viszont jelentosen megneheziti a kihasznalast, es nem kell hozza sem selinux, sem a programon modositani.
Tyrael
selinux?
--
NetBSD - Simplicity is prerequisite for reliability
Ki fogom próbálni, de sajnos az adott problémára nem megoldás. (Admin Guide első sora: "Disable SElinux")
Ötlet: egy darab külön, ennek a DOS-os világban szocializálódott fejlesztők által írt sza... szóval alkalmazásnak dedikált gép, egy darab root userrel.
A parancs amihez a jelszó paraméterként tartozik bináris állomány?
Sajnos gyanítom hogy igen, mert ha mondjuk bash script lenne, akkor a ". parancs" (vagy "source parancs") elrejti neked a parancsot és a paramétereket is és a /proc/$pid/cmdline sem fog árulkodni. Igaz a script által futtatott parancsokat, amíg futnak, a ps ugyanúgy kiírja.
Kérdés, hogy ha nem adsz meg jelszót a parancssorban, akkor bekéri-e a programod interaktívan? Ha igen és nincs lehetőséged interaktívan neked beírni a jelszót, mert mondjuk induláskor kell hogy automatikusan induljon a szolgáltatás, akkor javaslom az expect parancs használatát ami "beszélget" a programoddal és be tudja írni a jelszót, ami így nem kerül bele a cmdline-ba.
Üdv,
-Mr-
Hozz létre egy wrapper szkriptet:
Ezzel megoldottad a problémát.
--
Coding for fun. ;)
ezt te kiprobaltad?
myprog:
#!/bin/bash
sleep 300
es aztan a progi:
#!/bin/bash
myprog --password='secret'
exit 0
es mi van a ps faxu -ban?
ps faxu | fgrep myprog
a jelszo.
Hmm... Így jogos.
--
Coding for fun. ;)
argument inception level 1
kulon process namespace. (PID namespace)
lxc,cgroups -hez szukseges cuccok RHEL 6-ban AFAIK be vannak kacsolva.
Egyeb virtualizacio.
http://en.wikipedia.org/wiki/Cgroups#Namespace_isolation
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
Ezzel szerintem az a baj, hogy a PID namespace hierarchikus, azaz a teljes rendszert virtualizálnia kéne, kivéve azt azt 1 processzt.
jaja, ha azt akarja elrejteni, akkor igy van.
kérlek, írd le, mi az az alkalmazás, és milyen funkcióra használod.
nem vagyok benne biztos, hogy az volt a kerdes, hogy mivel tudja kivaltani az xy fizetos ibm alkalmazast.
Tyrael
Ne zavard össze… :)
-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)
Tobbszor talalkoztam mar a "dobozos, zart, fizetos, supportos" dolgoknal, hogy lehet A es lehet B felekeppen hasznalni, szinte minden felhasznalo A felekeppen hasznalja, de kello gondolkodassal lehet maskepp is.
Nem tartom lehetetlennek, hogy az adott alklmazasnal is el lehet kerulni a parancssori secret megadasat, csak eppen a segitseghez tudni kellene, hogy mi az alkalmazas, es melyik moduljaban miert kell megadni a jelszot.
Azert kerdeztem, hatha ismerem, es hatha tudok segiteni.
IBM WebSeal -hez kötődő akármi.
nezegesd a forrasat ennek: libsetproctitle, ld_preload elvileg megodhato lenne, de ismerni kene egy olyan fuggvenyhivast a programban ami akkor hivodik meg amikor mar feldolgozta a argumentumokat. Bar igy is van egy nagyon rovid idoablak amig olvashato az argv.
--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Hat, ha nagyon cink a dolog, es nem akarsz konyekig beleturni az appba, megoldhato ugy is, hogy a ps-t elrakod a sbin-be, a bin ala pedig bepakolsz egy wrappert hozza, ami kiszuri a kerdeses appot. Top-ra nincs otlet, azt sajnos jogosultsagilag le kell korlatozni.
Esetleg arrafele lehet meg erdemes keresgelni, hogy ha jol tudom, a SELinuxon belul az appok kulonfele role-kkal futnak, es azzal lehetne kavarni, hogy azt ne kapjak meg az app adminok, amivel ez fut. Gondolom, ha a Guide azzal kezdodik, hogy disable SELinux, akkor az alkalmazas nem hoz magaval policy set-et, igy azt neked kell majd osszekalapalni. Nem egy egyszeru menet.
Lehet tenyleg az lenne a legjobb, hogy ezt a cuccot bekonvertalni appliance-ca, aztan elzarni egy egyuseres virtualis gepbe.
--
Ez a cat /proc/NNNN/cmdline | tr "\000" " " ellen semmit sem ér - és mivel az összes pidhez tartozó könyvtárat tudja olvasni az átlagos user is...
SELinux eseten asszem ez egy picit maskepp van. Mivel masik role, definialhato olyan szabaly, hogy ne tudja piszkalni a processzt, ha nincs meg a megfelelo role. Ha igaz, akkor a /proc alatt letrejovo fajlok is ilyen role-val jonnek letre, igy arra meg csak annyit kell mondani, hogy nem olvashatja. Es akkor permdenied. De ezek mar halvany emlekek, utoljara nagyonnagyonsok eve lattam SELinux-ot.
--
A sima "eldugom a ps-t meg a top-ps meg az ilyesmit"-re reagáltam SELinuxhoz nekem is csak irtó régen volt pici szerencsém.
Bazz. Erre szoktunk környezeti változót tenni a parancsorba ugyebár.
Amibe a jelszót akár egy "read -S" -sel olvassuk be...
Maga felejt.
Biztos? Nem bontja ki a shell, mielott atadna?
-szobi.
A program paracssora csak azt tudja hogy ott a jelszót olvassa be. Az meg végképp nem érdekli hogy honnan kapja. Tehát amikor a program - folyamat- elindul akkor a kész parancssort kapja meg benne a jelszóval és ez parancssor fog látszani a /proc/xxxx/cmdline-ben és a ps-ben is.
Pontosan. Ahogy pl. a *.txt is kibontasra kerul. (A program mar egy listat kap az osszes txt fajlrol. Mondjuk ez pl. Windows-on maskepp mukodik.)
Lehet, hogy erdemes lenne kernelt patch-elni ehhez... Mi tart vissza?
Vajon a sajat patchelesu sajat kernellel ellatott gepre lesz support?
--
R2D2 a filmtörténet legmocskosabb szájú karaktere.
Minden szavát kisípolták.
milyen gyakorisaggal van szukseg olyan supportra aminel kikerik a kernel verziot is? Ha annyira fontos ez a hiba, akkor ez megoldas lehet. Masik lehetoseg a kulon gepre pakolas...
Kb. minden supportnal elkerik, ha jol sejtem. Legalabbis, ha en supportos lennek, olyan report scriptet adnek a usernek, hogy ez, a disztro szignoja, es leggyakoribb alapveto utility-k verzioszama benne legyen. Az alap, buta, ingyenes vmware report scriptbe bene van, szoval...
Meg egyebkent is, a support szerzodesek eleg vilagosak abban a kerdesben, hogy mit NEM lehet modositani egy rendszeren ahhoz, hogy a support ervenyes maradjon. Ha kiderul a turpissag, mindenkepp ugrott a support, ami nem ket filler szokott lenni, es raadasul megvan a lehetoseg, hogy valami irto szar hibanal derul ki, ami meg plusz bevetelkieses is a cegnek. Mit mondjak, egy fonok se szokott oromeben tancra perdulni egy ilyen utan.
--
Jo, igazad van. Support nelkul viszont siman megtennem. Vagy az is lehet, hogy inkabb virtualis gepbe pakolnam a dolgokat es elrejtenem a userek elol.
Nem is kell külön kérni a kernelvert: az IBM kapcsolattartói konkrétan megondják, hogy mely parancsok kimenetét kérik, és ez elég holisztikus dump szok lenni.
Hazudni persze lehet... egy ideig.
sub
Némi kísérletezés után úgy tűnik, hogy LD_PRELOAD-dal be lehet tölteni egy inicializáló kódot, ami átírja a program megfelelő paraméterét a tényleges jelszóra, míg a ps, top, stb, a parancssorban megadott helyőrzőt jeleníti meg.
a betöltendő kód:
fordítása:
teszt program:
teszt eredmény:
Ha működik így a dolog, akkor némi XOR-ozással elrejthető a szöveg a kódban, vagy beemelhető környezeti változóból, fájlból, amit indítás után le lehet törölni, stb.
kiraly, worksforme.
tmp % cat > hidearg.c
void init( int argc, char **argv, char **envp ){
argv[1] = "30";
}
__attribute__((section(".init_array"))) typeof(init) *__init = init;
tmp % gcc -fPIC -shared -o hidearg.so hidearg.c
tmp % LD_PRELOAD=./hidearg.so sleep 1
es a sleep 30 mp-ig var, nem 1 mp-ig, ahogy az eredeti parametere szolt.
En is kiprobaltam, jopofa cucc, es mukodik.
--
Nekem is megy.
szep megoldas, de ha en lennek supportos, akkor egy preloados ctor inzertalo megoldast a kod modositasanak tartanek.
Merthogy az.
Én meg shitware-nek tartanám az olyan programot, ami nem képes fájlból, vagy stdin-ről beolvasni a szenzitív információkat.
Én régebben Windowsra kerestem hasonló megoldást, de nem találtam. Örülök, hogy Linuxra létezik ilyen. Le is mentem, még hasznos lehet valamikor. Köszi, hogy megosztottad.
Átírtam használhatóbbra. A kód parancssori paramétert tölt ki (fájlból, sztenderd inputból, környezeti változóból) és kérésre el is tünteti.
teszt szkript:
futtatás:
eredmény:
A kód:
fordítás:
Remek. Én is piszkálgattam egy kicsit vasvillával a kódot, de csak annyit tettem hogy ellenőrzi melyik program "keze" alatt dolgozik.
Hm, érdekes megoldás, köszi. szerk: Rossz helyre válaszoltam, zamboriz-nek szólt.
Ez itt az egyetlen épkézláb megoldás ahogy nézem, bár nem olvastam végig nagyon figyelmesen mindet.
Gratulálok, szerintem nagyon ötletes.
a top es a ps forrasa elerheto, rejtsed el azok altal a folyamatot...
-------------------------------------------------------------------------------------------
Mit használok? Na, na, na? Hát blackPanther OS v11.1-et * www.blackpanther.hu
és reménykedj, hogy a felhasználó hülye a linuxhoz
1) a problemat ez nem oldja meg
2) bukja a tamogatast, mert modosit tamogatott fajlokat a rendszerben
Egyebkent tenyleg nincs baj az otlettel :-)
--
Bár a támogatást kétlem, hogy emiatt bukná, de lényegtelen is mert a probléma maga a zártkódú programmal van. Hogy lehet ilyet "eladni" ?! Ilyen jellegű biztonsági probléma, szerintem több mint szánalmas.
-------------------------------------------------------------------------------------------
Mit használok? Na, na, na? Hát blackPanther OS v11.1-et * www.blackpanther.hu
Kiballagtak a piacra, es elkezdtek obegatni. Hat, valahogy igy sikerult eladni. Egyebkent meg egyetertek, bar vannak meg remtortenetek a piacon, szoval ettol aggodni nem kell.
--
ha a kollega megmondana, hogy konkretan melyik termek az ES az tamogatott meg jelenleg is, fejlesztes alatt all, akkor (csupan karma pontokert cserebe) utanajarnek cegen belul, hogy wtf.
http://hup.hu/node/112266#comment-1428547
Ebbol mondjuk nem biztos, hogy sok kiderul, de talan... PM-ben probald kerdezni esetleg.
--
nekem annyira nem fontos a dolog, csak felajanlottam, ha mar epp Tivoli termekekhez is van kozom.
a) grsecurity
b) irsz egy kernel modult, amivel behookolsz a procfs-be es a sysctl-be, esetleg valamelyik syscall-ba es nem engeded kilistazni az adott processzet ( http://www.phrack.org/issues.html?issue=63&id=18 )
___
info
"nem engeded kilistazni az adott processzet"
ettől még a /proc bugyraiban lesz egy olyan hely, ahol plaintextben van feltüntetve a rejteni kívánt string
grsecurity: +1
A user csak a saját processzeit láthatja. Meg persze az RBAC sem árt.
"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."
http://hup.hu/node/112266?comments_per_page=9999#comment-1428377
Hát ha nincs valami speciális hardver benne, amihez feltétlenül gyári kernel kell bináris modullal, akkor semmi akadálya, hogy saját kernelt fordítson. És akkor ott lehet a grsec az RHEL6-ban is.
"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."
Mintha a support csak a gyári kernellel lenne csak elérhető.
Melyik resze nem vilagos annak ,hogy ha sajat kernelt forditasz baszhatod a supportot?
--
1 leszel vagy 0 élő vagy hulla!
Valószínűleg az egész. :-)
Az nem világos, hogy nem nyálaztam végig a thread összes hozzászólását, mert lusta voltam rá időt és energiát pazarolni.
A support egyébként kijön és nyom egy "uname -a"-t, mielőtt támogatást nyújt?
Az inkriminált szoftvert ugye nem lehet piszkálni.
Ha pedig nem szeretnének kockáztatni, és nincs egy grsec repo, akkor meg látják a user-ek a jelszót.
Tényleg csak segíteni próbálunk. Számbaveszik azt döntenek. Maximum egyből elvetik a grsec-et. Attól még mindig egy ötlet. Ennyi.
Szurkolok egyébként, hogy sikerüljön jó megoldást találni.
Üdv:
Dw.
"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."
Ugy kezdodik a topic ,hogy RHEL6. A support nem megy sehova kert egy diagnosztikat es abbol latni fogja ,hogy nem gyari kernel. Megkoszoni ,hogy hivtad elkoszon.
--
1 leszel vagy 0 élő vagy hulla!
too bad...
A topic úgy kezdődik, hogy "Hi". Bocs a szar poénért.
"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."
en bevallom egy shell scripttel probalkoznek:
variable = "jelszo"
export $variable
/usr/*bin/prog --paswd $variable
Amennyire én néztem, így nem jelenik meg a jelszó.
Amire oda kell figyelni, de ahogy nézem ez alapértelmezett, hogy a /proc/
/environ ne legyen olvasható a user által.
De javítsatok ki, ha nincs igazam.
Olvass vissza... a $variable helyere behelyettesiti a shell a cuccot...
munkaado szempontbol hasznos lehet ez a topic. :/
Tyrael
Koszonom az epito kritikat.
Masreszt meg utobb derult ki, hogy a rendszer amire raneztem, ott grsecurity patch is fenn van.
(user vagyok rajta, nem root.)
Update erkezik, ha talalok megoldast.
Offtopic, de aki ezt megirta, azt ciklusban kellene lek...ni a taigetoszrol.
subs.
------------------------------------------
"Nincs ez el**szva, csak másra lesz jó!"
+1
+1
+1
tetszik az LD_PRELOAD-os megoldás.
mysql esetén pl ez úgy van megildva, hogy egy fájlba rakod le a belépési infókat. A fájl csak a megadott felhasználó olvashatja. és csak a fájl helyét adod át a cmd-ben.
KAMI | 神
--
Támogatás | OxygenOffice | Fordításaim és SeaMonkey
ez aztan most kisegiti, hogy mysql eseten hogy van megoldva...
foleg, hogy egy rakas masik programban is igy van megoldva (vagy igy is megoldhato)
Annyira legalább, mint a te hozzászólásod.
Elnézést.
epp, mint a tied.
Csak arra szerettem volna rávilágítani, hogy hátha lehet máshogy is - nem csak a terminálba írt jelszóval.
KAMI | 神
--
Támogatás | OxygenOffice | Fordításaim és SeaMonkey
mert nem olvastad el, hogy mar leirta, hogy csak parancssorban lehet megadni, mashogy nem.
My mistake, sorry
KAMI | 神
--
Támogatás | OxygenOffice | Fordításaim és SeaMonkey
delete.
http://kernelnewbies.org/Linux_3.3
Add hidepid= and gid= mount options. hidepid=0 means classic mode - everybody may access all /proc/<pid>/ directories (default). hidepid=1 means users may not access any /proc/<pid>/ directories but their own. hidepid=2 means hidepid=1 plus all /proc/<pid>/ will be fully invisible to other users. gid= defines a group authorized to learn processes information otherwise prohibited by hidepid=
--
joco voltam szevasz
\o/
(Yes)
Azigen.
Ezek szerint a kernelfejlesztők közül valaki olvassa a HUP-ot. Van még valakinek valami kívánsága? :-)
Persze ez még nem old meg minden problémát, mert új kernel kell hozzá.
De vanilla kernel, ami még mindig jobb sok egyéb megoldásnál.
--
joco voltam szevasz
nah jah, csak kérdés, hogy...
1. mennyi idő lesz mire a nagy disztribúciókban is benne lesz
2. mennyi program fog megdögleni tőle
legyen egy sysctl/kernelparaméter, amivel a hidepid értékét globálisan lehessen beállítani, ne kelljen teleszemetelni az fstab-ot.
Majd bsd-ből átveszik a 4.0 ban. :)
security.bsd.see_other_uids=0
Ühüm, a security.bsd.see_other_uids nekem is eszembe jutott, igaz én FreeBSD-zek.
Egyebkent se rossz, ha a procfs benn figyel az fstabban. Sokminden el tud torni, ha a /proc ures.
--
linux alatt igen...
___
info
Es ha valaki kitatlalja, hogy netlinken keresztul is el lehesen erni ezeket az informaciokat, akkor hogy leszen ?
NPROC veglegesen el lett kaszalva, vagy csak a bekuldott valtozat volt kezdetleges ?
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
Muszaj a ket proginak egy gepen futnia?