Konyvtarukba zart userek

Hi!

Nem probaltam ki, de mi van akkor, ha pl. az adott konyvtarakra egyszeruen nem adsz az adott konyvtarakra exec jogot?

By(t)e
TBS::Antiemes

Mielott nekialsz sajas tshell irni nezz utana a restricted shell funkcioknak. Pl a bash -r kapcsoloval.

masreszt ha bezarod valamilyen modon a konyvtaraba, akkor a binarsokat ne masolgasd, hanem csinalj hardlinkeket.

Hi!

Ha adott esetben a binarisok nem ugyanazon a filerendszeren vannak, mint a home, akkor nem lehet hardlinkelni. Viszonylag biztonsagosabb servereken altalaban nem szokott ugyanazon a filerendszeren lenni a ketto.

By(t)e
TBS::Antiemes

[quote:83b68abb22="antiemes"]Hi!

Ha adott esetben a binarisok nem ugyanazon a filerendszeren vannak, mint a home, akkor nem lehet hardlinkelni. Viszonylag biztonsagosabb servereken altalaban nem szokott ugyanazon a filerendszeren lenni a ketto.

By(t)e
TBS::Antiemes

Ez igaz, de akkor is erdemes egy /home/bin, es azt linkelni minden /home/usernev/bin -be, meghozza scriptel. Frissitesekkor jol jon.

[quote:e2c0c5f4c0="Anonymous"]

Use Linux 2.4+ (de valoszinuleg BSDk is tudnak hasonlot), es csinalsz egy konyvtarat azon a particion, ahol a binarisok vannak, amelyik tartalmazza a hardlinkeket a megfelelo binarisokra. Utana mount -t none --bind /safe-bin /home/$USER/bin

Meg a /safe-lib, meg a /safe-etc, meg a /safe-tattara. apt-get upgrade
uten meg csak nezunk. Ez az ut szerintem jarhatatlan. Inkabb
erdemesebb chmod-olni meg setfacl-ezni. Vagy grsecurity-val hide-olni.

Vagy tenni a gepre egy lk trojan-t es hagyni hogy az hide-oljon :)

Hi!

Meg a /safe-lib, meg a /safe-etc, meg a /safe-tattara. apt-get upgrade
uten meg csak nezunk. Ez az ut szerintem jarhatatlan.

Ossze kell irni egy scriptben, hogy miket masoljon hova, es minden apt-get upgrade utan azt is futtatni.

By(t)e
TBS::Antiemes

Shell-t irni tenyleg badarsag. Egyreszt, mert nem konnyu. Masreszt, mert evek kellenek hozza, hogy bash, tchs, vagy esetleg zsh szintu shell-t irjatok. Harmadreszt, a fent emlitett shellekkel kompatibilisnek kellene lennie, hogy a user ne sirjon hogy ez/az maskepp mukodik, es nem futnak a scriptjei. Szoval eleg gaz...

Level 1-es megoldas: A konyvatarjogosultsagok allitgatasa chmod o+r-wx
Persze, ha a user ismeri a /etc szerkezetet, akkor igy is megtalalja a konfigokat :) Erre jo a kovetkezo lepcso:
Level 2-es megoldas: grsec vagy RSBAC. Aztan csak nez ki a fejebol, hogy "jee, ezen a Linuxon nincsen /etc" :)

[quote:b0a0ff04f1="borso"][quote:b0a0ff04f1="Anonymous"]

Use Linux 2.4+ (de valoszinuleg BSDk is tudnak hasonlot), es csinalsz egy konyvtarat azon a particion, ahol a binarisok vannak, amelyik tartalmazza a hardlinkeket a megfelelo binarisokra. Utana mount -t none --bind /safe-bin /home/$USER/bin

Meg a /safe-lib, meg a /safe-etc, meg a /safe-tattara. apt-get upgrade
uten meg csak nezunk. Ez az ut szerintem jarhatatlan. Inkabb
erdemesebb chmod-olni meg setfacl-ezni. Vagy grsecurity-val hide-olni.

Vagy tenni a gepre egy lk trojan-t es hagyni hogy az hide-oljon :)

Szerinted ezt az egeszet nem lehet scriptelni, hogy updatelje a /safe-* -ot is? :)

Mondjuk szerintem UML-es megoldas jobbabb, vagy egy full chroot /safe/ ala, vagy hasonlo, az tenyleg egyszerubb.

[quote:eedf7591f0="onyx"]
Amire meg erdemes figyelni, hogy a full learning nem fog letrehozni az uj policy fileba admin role-t. Ezt erdemes a regi, eredeti policy filebol kimasolni, es bevagni az uj policy fileba, hogy legyen admin roleod. Ez utan, ha mar mindent belottel, es fut a grsec rendesen, igy tudsz superuser modba valtani:
gradm -a admin, es azt a jelszot kell ugye megadnod, amit az admin role-nak megadtal.
onyx

Megcsináltam, de most meg az a baja hogy 2 "subject /" van:
Duplicate subject found for "/" in role default, on line 257 of /etc/grsec/policy.
"/" references the same object as "/" specified on an earlier line.
The RBAC system will not load until this error is fixed.

Meg ezekre is "haragszik":

CAP_SYS_ADMIN is not removed in role default. This would allow an attacker to mount filesystems to bypass your policies

CAP_NET_ADMIN is not removed for role default. This would allow an attacker to modify your firewall configuration or redirect private information

CAP_NET_BIND_SERVICE is not removed for role default. This would allow an attacker (if he can kill a network daemon) to launch a trojaned daemon that could steal privileged information

/etct is mountolni kéne
abban van a profile, az csinálja meg a promptodat
abban van a passwd, onnan olvassa ki a whoami

ha nem akarod mountolni, akkor a passwdt, meg a profile+profile.d-t symlinkeld

[Level 2-es megoldas:[/b] grsec vagy RSBAC. Aztan csak nez ki a fejebol, hogy "jee, ezen a Linuxon nincsen /etc" :)

Ezt pontosan hogyan is kell???

[quote:d20562f2d1="Anonymous"]
/etc/sudoers -be beraktam
user ALL=NOPASSWD:/usr/sbin/chroot

Ezzel olyan szépen jelszó nélküli rootot adtál minden usernek, hogy azt öröm nézni. Javaslom man sudoers parancsot.

Ha azt akarod, hogy a user bechrootolódjon valahova, és utána root jogokat a cucc eldobja, akkor nézd meg pl a Debianos dchroot nevű csomagot. Az egy aranyos kis C program ami pont ezt csinálja.

[quote:d20562f2d1="Anonymous"]
3. miért uid 0 ami ugye root?

Mert sudo setuid root, és sehol nem mondtad meg neki, hogy chroot után azt dobja el.

Mármint arra gondoltam hogy grsec-kel hogyan is lehet ezt megcsinálni.

[quote:4b1d728c05="Anonymous"][quote:4b1d728c05="algernon"]
Ezzel olyan szépen jelszó nélküli rootot adtál minden usernek, hogy azt öröm nézni. Javaslom man sudoers parancsot.

Persze decsak a chroot-hoz...

Az bőven elég. Próbáld ki ezt, userként:

$ sudo /usr/sbin/chroot / /bin/bash

[quote:5a8e984c17="Anonymous"][quote:5a8e984c17="algernon"]
Az bőven elég. Próbáld ki ezt, userként:

$ sudo /usr/sbin/chroot / /bin/bash

Amugy akkoe már csak /home -on belül tud variálni chroot-al

Jah, lehet, feltéve hogy besshzott. De ha sudoers marad olyan, amilyen, és teszemazt CGIt tud futtatni, akkor secperc alatt rootot szerez magának, /home-on kívülre is.

De ha chrooton belül rootot szerez, akkor onnan is olyan simán jön ki, ahogy nemakar. (Kivéve, ha nem tud device filet csinálni, akkor trükkösebb.)

[quote:5a8e984c17="Anonymous"]
Akkor írd le szépen, részletesen hogy te hogy csinálnád

Nem fogom leírni részletesen, mert kegyetlen egyszerű a dolog, és az összes hozzá kellő dolgot itt megemlítették már, jómagam is hozzátettem 1-2 ötletet.

A magam részéről én debootstrap-al csinálnék egy chrootot, pam_mount és pam_chroot segítségével meg szépen bele lehet pakolni a juzereket.

Ha meg kevesebbet akarok szívni, akkor debootstrap egy chrootot, és belövok egy user mode linuxot.

Mindent elmondtak már itt a fórumon, ami kell neked. Csak a doksikat kéne átnézned, gondolkodni a dolgon egy keveset, és utána pillanatok alatt be is tudnád lőni, nem egy nagy ördőngősség (ha az lenne, ezeregy howto lenne róla).

volt itt egy olyan otlet, hogy grsec-el kene megoldani a problemat. Az illeto egy bizonyos "hide" dolgot emlitett. Valaki ki tudna fejteni bovebben, hogy miket is kene beallitani a grec-ben, hogy ilyen hide letrejojjon?

Elore is kosz!

Nemrég én is próbálgattam.
Bekell forgatni a grsec-be a sysctl supportot, telepíted a gradm-et, azzal tudod állítgatni.

[quote:0a03f6db43="jaci"]Nemrég én is próbálgattam.
Bekell forgatni a grsec-be a sysctl supportot, telepíted a gradm-et, azzal tudod állítgatni.

Ezt megcsinaltam.
De amikor el akarnam inditani a gradm-et (gradm -E) ezt keri allitsak be jelszot, de miutan beallitom, ujra azt keri allitsam be.

Ha jol gondolom az /etc/grsec/policy-t kell piszkalgatni.. Nem nagyon talaltam leirasokat hogy mit hogy kene. peldaul ezt a hide dolgot hogyan lehet megcsinalni? nem tudnal adni egy pelda configot?

Nekem sem volt tökéletes, és akkor elég finoman fogalmaztam:)
A pass-t nekem is többször kellett beállítani mire elfogadta. /nem tom miért/

A default configot variáltam, de az volt a gondom, hogy ha hiddenre tettem a /etc-t akor sok alkalmazás behalt... Próbáltam tanítani is így már jobb volt az eredmény, de pl a samba meg a postfix akkor sem ment rendesen. Úgy hogy feladtam:)

Van olyan, akinek ezt mar sikerult belonie rendesen?

Valóban a PAM a legszebb megoldás, de anélkül is egyszerűen meg lehet csinálni.
Pl: a user shellje (/etc/passwd) egy bash szkript legyen, valahogy így
[code:1:fcb5b8b454]
#!/bin/sh
USER=`basename ~`
sudo /usr/sbin/chroot ~ /bin/su - $USER
[/code:1:fcb5b8b454]
az /etc/sudoers fájlba meg kell egy ilyen:
[code:1:fcb5b8b454]
juzernév ALL:NOPASSWD: /usr/sbin/chroot, /bin/su
[/code:1:fcb5b8b454]
no meg érdemes a home könyvtárába bemásolni a szükséges binárisokat, konfig fájlokat, stb. és már megy is.

Tovabbi problema hogy a kozos eroforrasokat azert valahogy
elerhetove kell tenni chroot-on belul is: levelezes, man cache,
syslog, nscd (ha van), ...

Ezt próbálgasd:
# To use full system learning, enable the system like:
# gradm -F -L /etc/grsec/learning.logs
# and then generate the rules after disabling the system after the
# learning phase with:
# gradm -F -L /etc/grsec/learning.logs -O /etc/grsec/policy

Elindítod hogy loggoljon. Akkor minden olyan alkalmazást amit szeretnél használni elindítasz, és használod, majd ebből készíted a policy-t.
Csak a samba-t és a postfixet nem tanulta meg rendesen, lehet kézzel kellett volna neki kicsit besegíteni.

A grsecurity rbac funkcioja eleg maceras... viszont ha egyszer belotted, eleg jol mukodik. Mindenkepp a full learning modot hasznald, ahogy azt az elozoekben mar leirtak. A trukk az, hogy hagyni kell futni jopar napig (~1 hetig). Ne ijedj meg, 1-2 gigas logfileot fog generalni. Fontos, hogy a rendszert ilyenkor csak ugy hasznald, ahogy altalaban fogod. Ha kulonleges dolgokat akarsz vegezni, amit alapesetben nem akarod, hogy a root user is tudjon (egesz rbac lenyege az, hogy a root usert degradalja egy sima userre, akinek semmivel sincs tobb joga), akkor erdemes leallitani a tanulast, megcsinalni, amit akarsz, es visszakapcsolni utana. Azon se lepodj meg, hogy amikor a logokbol a gradm segitsegevel (gradm -F -L path/to/logfile -O path/to/new/policy/file) policyt gyartasz, az is jo sokaig el fog tartani. (Nalam multkor masfel napig futott.) Ezutan kesz egy policy fileod, mostmar csak az van hatra, hogy kezzel kiegyengesd. Ehhez kell a tapasztalat, de egy ido utan bele lehet jonni. En ugy szoktam, hogy gradm -E, aztan rogton kapcsold is ki:)) Logfilet csekkold (syslogot), es nezd, hogy mik irnak hibat. Keresd meg, hogy mi nem oke a policy fileban, es modositsd, aztan gradm -E ujra, stb. Hosszadalmas, de erdemes vele vacakolni sztem.

Ami meg felmerult, hogy miert ker tobb jelszot: alapesetben a gradm felrakasaval egy alap policy file fog telepitesre kerulni /etc/grsec ala. Ebben van egy admin role, ami arra valo, hogy rootkent erre tudsz authentikalni, es igy leszel mezei rootbol superuser. Tehat ennek valo az egyik jelszo (gradm -P admin). A masik jelszo pedig a grsec rbacjanak ki/be kapcsolasara valo (gradm -P).
Amire meg erdemes figyelni, hogy a full learning nem fog letrehozni az uj policy fileba admin role-t. Ezt erdemes a regi, eredeti policy filebol kimasolni, es bevagni az uj policy fileba, hogy legyen admin roleod. Ez utan, ha mar mindent belottel, es fut a grsec rendesen, igy tudsz superuser modba valtani:
gradm -a admin, es azt a jelszot kell ugye megadnod, amit az admin role-nak megadtal.

Nah ez jo hosszura sikeredett, es nem tudom mennyire ertheto, ha vmi nem stimmel, kerdezz. Amugy grsec nagy baja, hogy nem igazan dokumentalt, pedig ez az rbac az egyik legfontosabb resze (szerintem), megsem sokan hasznaljak, pont mert ennyire nincs dokumentalva.

Sok sikert!
onyx

[quote:aecca1a49c="willothewisp"]no meg érdemes a home könyvtárába bemásolni a szükséges binárisokat, konfig fájlokat, stb. és már megy is.

Na pont itt a probléma... ha 6000 usered van, és a home könyvtárak nem igy egy file-rendszeren vannak (hanem mondjuk 20 -on), akor másolgatni elég macera, a helyfoglalás miatt is.
Ennél már csak az macerább, ha a "másolt" konfigállományokat módosítani kell, vagy mondjuk ha egy biztonsági-lyuk miatt frissíteni kell a binárisokat...

Szerintem nem baj hogy ilyen hosszúra sikerült. Lehet újra megjön a kedvem hozzá:)
Azt hiszem ott is hibáztam hogy az admin role-t nem másoltam be neki, ezért párszor kizártam magam: :D Mindenesetre azért azt ajánlom hogy minednki csak olyan gépen próbálgassa ami elég közel van, ha esetleg még sem úgy sülne el a dolog mint ahogy várná...

Kosz az infokat, majd probalkozom...
Viszont azt meg nem teljesen ertem, hogy a sima usereknek hogyan lesznek beallitva a jogaik. Csinalok egy proba-usert, bekapcsolom a learning-et, belepek a userrel, amit engedni akarok neki a kesobbiekben azt megcsinalom vele, vagy hogy? Es ha kesz a userre vonatkozo policy akkor atirhatom hogy egy csoportra vonatkozzon?

[quote:eb7517ee4e="dszabo"]Kosz az infokat, majd probalkozom...
Viszont azt meg nem teljesen ertem, hogy a sima usereknek hogyan lesznek beallitva a jogaik. Csinalok egy proba-usert, bekapcsolom a learning-et, belepek a userrel, amit engedni akarok neki a kesobbiekben azt megcsinalom vele, vagy hogy? Es ha kesz a userre vonatkozo policy akkor atirhatom hogy egy csoportra vonatkozzon?

Amikor megy a full learning, akkor csinalsz minden olyat, amit amugy akarsz csinalni a geppel. Tehat pl ha van egy juzered, akkor azzal belepegetsz, es minden olyan programot futtatgatsz, amit kesobb majd hasznalni akarsz azzal a felhasznaloval. Amikor a grlearnnel megcsinaltatod vele a teljes policyt, ez a juzer benne lesz egy kulon user role-kent, benne minden programra vonatkozo subjecttel, amiket hasznaltal. (pl bash, mc, ping, etc.)

Persze akkor sincs semmi, ha mar kesz a policyd, es utana akarsz pl uj felhasznalot megadni. Van a full learningen kivul masikfajta learn is. A mar kesz policyban is lehet megadni tanulo modot, roleokra is (pl beleirod, hogy uj_juzer_neve ul), es kulon subjectekre is:

[code:1:eb7517ee4e]
role valamiuser
[...]

subject path/to/app ol {
/ h
-CAP_ALL
bind disabled
connect disabled
}
[/code:1:eb7517ee4e]

Ez utan a -F kapcsolo nelkul inditod az rbacot, (-F a full learningre valo), tehat gradm -E -L /path/to/logfile. Mindaddig igy kell inditani a rendszert, amig egy tanulasra allitott subject/role van a policy fileban. (az uj, tanult subjectek/roleok megadasa: gradm -L /path/to/logfile -O /etc/grsec/policy-learned, aztan ebbol a filebol kell atmigralni az uj subjecteket/roleokat)

Amugy erdemes megnezni a meglevo doksikat:
http://www.grsecurity.net/papers.php - itt van a regi 1.9.x sorozat dokumentacioja, egy resze meg mindig ervenyes.

http://www.gentoo.org/proj/en/hardened/grsecurity.xml
nameg a grsecurity forumja: http://forums.grsecurity.net

Remelem sikerult valamennyire erthetoen leirni.

engem érdekelne, főleg ez a grsec dolog..

a devpts nálam még a gid=5 és a mode=620 opciókkal mountolódik :wink: