processz elrejtése ps-ből és top-ból

Linux-kezdő

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.

  • 17404 megtekintés

( Foltos | 2012. 03. 01., cs – 09:56 )

TOP és PS letiltása nem root felhasználóknak?

( thuglife | 2012. 03. 01., cs – 09:56 )

Igen van. Javitsd a szoftvert hogy valtoztassa meg a process nevet!

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...

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.

( uid_4672 | 2012. 03. 01., cs – 10:10 )

indíthatod a processzet úgy, hogy ./program --password=`showmypassword.sh`

( apostroph3 | 2012. 03. 01., cs – 10:13 )

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.

( Jason v | 2012. 03. 01., cs – 10:24 )

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

( apal v | 2012. 03. 01., cs – 10:28 )

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.

( vl v | 2012. 03. 01., cs – 10:39 )

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.

( -Mr- | 2012. 03. 01., cs – 12:21 )

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-

( Frantique v | 2012. 03. 01., cs – 12:23 )

Hozz létre egy wrapper szkriptet: 


#!/bin/bash
myprog --password='secret'
exit 0

Ezzel megoldottad a problémát.

--
Coding for fun. ;)

( egeresz | 2012. 03. 01., cs – 13:19 )

kérlek, írd le, mi az az alkalmazás, és milyen funkcióra használod.

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.

( Elbandi v | 2012. 03. 01., cs – 13:27 )

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!

( hrgy84 | 2012. 03. 01., cs – 14:48 )

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.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

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.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

( cheeky v | 2012. 03. 01., cs – 18:08 )

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.

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.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

( zamboriz v | 2012. 03. 02., p – 00:50 )

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: 


void init( int argc, char **argv, char **envp ){
  argv[2] = "(igazi titok)";
}

__attribute__((section(".init_array"))) typeof(init) *__init = init;

fordítása: 


gcc -shared -o setarg.so setarg.c

teszt program: 


#!/bin/bash

LD_PRELOAD= /bin/echo A B C
            /bin/echo A B C

/bin/echo "0:$0 1:$1 2:$2"
LD_PRELOAD= od -c /proc/${BASHPID}/cmdline

ps ax | grep elso

teszt eredmény: 


$ LD_PRELOAD=setarg.so ./test.sh elso masodik

A B C
A (igazi titok) C
0:./test.sh 1:(igazi titok) 2:masodik
0000000   /   b   i   n   /   b   a   s   h  \0   .   /   t   e   s   t
0000020   .   s   h  \0   e   l   s   o  \0   m   a   s   o   d   i   k
0000040  \0
0000041
 5047 pts/1    S+     0:00 /bin/bash ./test.sh elso masodik
 5053 pts/1    R+     0:00 grep elso

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.

Á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: 


echo args: "0:'$0'" "1:'$1'" "2:'$2'" "3:'$3'" "4:'$4'" "5:'$5'" "6:'$6'" "7:'$7'"  "8:'$8'"  "9:'$9'"
ps -f $$
echo "$(cat /proc/self/environ | xargs -0 -n 1 echo | grep TITOK)"

futtatás: 


echo "titok.txt: '$(cat titok.txt)'"

LD_PRELOAD=./loadarg.so TITOK=asdf1234 ./test.sh  [LoadFromFile]titok.txt [LoadFromStdIn] [Hide][LoadFromEnv]TITOK [Hide]titok

eredmény: 


$ ./_run.sh
titok.txt: 'fajlbol'

args: 0:'./test.sh' 1:'fajlbol' 2:'eztgepeltembe' 3:'asdf1234' 4:'titok'

... CMD
... /bin/bash ./test.sh [LoadFromFile]titok.txt [LoadFromStdIn] ************************ ***********

TITOK=********

A kód: 


#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
#include <string.h>

static char buf[256];

static void init( int argc, char **argv, char **envp __attribute__((unused)) ){
  for( int i=0; i<argc; i++ ){
    int hide = 0;
    if( !strncasecmp( argv[i], "[Hide]", 6 ) ){
      hide = 1;
      char *orig = strdup( argv[i]+6 );
      for( char *c = argv[i]; *c; *c++ = '*' );
      argv[i] = orig;
    }
    if( !strncasecmp( argv[i], "[LoadFromStdIn]", 15 ) ){
      int len = read( 0, buf, 255 );
      if( 0 > len ) len = 1;
      buf[len-1] = 0;
      argv[i] = strdup( buf );
    }
    else if( !strncasecmp( argv[i], "[LoadFromFile]", 14 ) ){
      int fd = open( argv[i]+14, O_RDONLY );
      int len = read( fd, buf, 255 );
      close( fd );
      if( 0 > len ) len = 0;
      argv[i] = strdup(buf);
    }
    else if( !strncasecmp( argv[i], "[LoadFromEnv]", 13 ) ){
      char *e = getenv( argv[i]+13 )?:"";
      argv[i] = strdup( e );
      if( hide ){ for( char *t=e; *t; *t++='*' ); }
    }
  }
}

__attribute__((section(".init_array"))) typeof(init) *__init = init;

fordítás: 


gcc -std=gnu99 -shared -fPIC -o loadarg.so  loadarg.c

( vector | 2012. 03. 02., p – 12:37 )

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

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

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."

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."

( frottirtigris | 2012. 03. 02., p – 21:19 )

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.

( wladek1 | 2012. 03. 02., p – 22:42 )

Offtopic, de aki ezt megirta, azt ciklusban kellene lek...ni a taigetoszrol.

( goodbyte v | 2012. 03. 03., szo – 14:15 )

subs.

------------------------------------------
"Nincs ez el**szva, csak másra lesz jó!"

( joco01 v | 2012. 03. 19., h – 16:03 )

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

( battila | 2012. 03. 24., szo – 20:41 )

Muszaj a ket proginak egy gepen futnia?