Új disztró ?

Érdemes lenne -e egy gentoo alapú binaris magyar desktop disztrót létrehozni ? Ezzel legyőzve a gentoo egyetlen hátrányát a napokig tartó forgatást.

minden disztrón egyszerű a dolog, ha megvannak hozzá az eszközeid. mivel a gentoo alapvetően forrásalapú, ezért ott a rendszer részei ezek az eszközök, ezért tudod újrafordítani az egészet egy paranccsal. és igen, ubuntun sokkal bonyolultabb, mert össze kell vadászni 3 db scriptet a netről. nyertél. most már jöhet az a magyar gentoo...

Hova teszi kész debeket ? (Csinál azt is ? 

/var/cache/apt-build/repository

dev-eket külön szedve ?)
Igen.

Hogy teszek patchet egy csomaghoz ? 

apt-build --patch <file> install <package>

Hogy adok más opciót a configurének ? 

apt-build source <package>
vi /var/cache/apt-build/build/<package>-<version>/debian/rules
apt-build --nosource install <package>

Le tudja szedni a forgatáshoz szügséges eszközöket /csomagokat ?
Igen, bináris csomagból felteszi őket.

Tud kulön dbg filokat csinálni minden binárishoz ?
Nem, csak ahhoz tud, amelyiknél a package maintainer előlátta, de van egy wordaround: 

apt-build source <package>
vi /var/cache/apt-build/build/<package>-<version>/debian/rules
# töröld ki azokat a sorokat, melyekben dh_strip van
apt-build --nosource install <package>

apt-builddel mindig lehet dobálózni, ha Debianról van szó, na de keress olyant, aki használja is.

apt-build --patch install
patch ez utan ott marad, vagy mineden forgataskor be kell irnom, ki hogy szedem, inverz patchel ?
Elméletileg megpróbálja megtartani a forráskód helyi változtatásait verziófrissülés esetén is.

De gentoo arcok ebuildjeiben jobban bízok, mint holmi ubuntu/debian tákolmányban :)
Igen, mert Gentoonál az a cél, hogy az ebuildek kényelmesen használhatóak legyenek ports-like rendszer alatt, Debian alatt meg az, hogy jó kis bináris csomag készüljön belőle, és ez némelyik csomagnál buildelésénél problémákat okozhat.

Népszerűségöl függ.
level 0 megoldás: így járás

Ha elgen közremüködnek akkor, a use flageket ket csoportra bontjuk.
1. ami befojásolja egyes fileok tartalmát.
2. ami csak a leforgatott/telpített komponensek mennyiségét befolyásolják.

Level 1 megoldás, gyárilag minden 2 kategoriás use flaget használjuk, az install idején meg kiszürjök, ami nem kell. (zone)
level 2 +
a,több csomagot gyártunk gyakari kombinációk számára
level 3 +
super csomagokat gyártunk amik binary diffeket tartalmaznak az eltérésekkel, a fontosabb flag kombók felé.

Meghatározható, hogy milyen taktika szerint illessze a flegeket binárishoz (user választhat), hogy aki nem gyakori flageket használ az se járjon rosszul.

Ahol az még mindig kevés marad a saját forgatás, ill. kérés a flag kombinácó támogatására.

A esetek 90% elég az level 1. megoldás szvsz.

( colos | 2007. 11. 12., h – 10:48 )

miket akarsz belerakni? teljes desktop vagy szerver pl ldap es kerberos tamogatassal, ledokumentalva magyar nyelven? :) pax kernellel szallitva?

udv Zoli

"miket akarsz belerakni?"
Ami egy DVD re rafer kicsomagolva sqashfs -en.
"teljes desktop vagy szerver pl ldap es kerberos tamogatassal, ledokumentalva magyar nyelven? :)"
Egyenlőre desktop, a cél. Ha van rá érdeklődés ilyesmi is bekerülhet. (Erre más koncepcióm vannak, nagyon örülnék majd, ha dokumentálásbe is besegitene valaki )
"pax kernellel szallitva?"
Add némi büntetést a sebbeséghez, hagyapucányit a biztonsághoz, desktopra nem hiszem, hogy kell.
A "más koncepciómban" szerepel , a 2. DVD -n. (Ami buzzwordokkel lesz tele, es gyorsan telepitheto pre. configolt megoldasokkal lenne tele)
Ha biztonság fontos cél eleve más gcc paraméterrekkel forgat az ember.

"Mi az amit minimum, be kell x elni, hogy megfogja?"
Marmint mit? Konkretan ezt az exploitot egy non-executable stack is megfogja, viszont return-olni a stacken kivul meg sok helyre lehet. Ha mindent meg akarsz fogni, akkor meg mindent be kell kapcsolni. ;)

"Mi az amit engedélyeznem kell, hogy fusson.
(fork,dup2, execve -nek imertem fel a rendszer hivasait)"
Ezt viszont tenyleg nem ertem. Mi fusson, hova, es hogy jonnek ide a milyen rendszerhivasok?

"A mezei Linux defaultban mikor ad -wx lapot ?"
Pl. ha kered mprotect()-el (es ha egy szal syscall-al lehet ilyet kerni, az mar sokban egyszerusiti az exploitot).

Szerk: egyebkent megesik idonkent normal mukodes soran is: 


root@t60:/proc# find ./ -name maps -exec cat \{} \; | grep wx | wc -l
6464

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

"non-executable stack"
Alapból futatható a stack ?

"Mi fusson, hova,"
A kurva mail szerver, amiben a hiba van.

"fork,dup2, execve" ezeket hivja a támadó kód, semmi mprotect/mmap, mivel az mprotect/mmap nem várt kiadásához is kell egy futatható írható lap, hogy kapja ezt meg a program? Vagy, hogy éri el, hogy egy legális mprotect/mmap illegális attr kérjen lapot ?

(es ha egy szal syscall-al lehet ilyet kerni, az mar sokban egyszerusiti az exploitot).
Ismerem az mprotec/mmap -ot a támadó kódban nem látok. A gyári programnak kell ilyen lapot kérnie.

szerk:
extremail zárt kód, már itt fen akad nálam a biztonsági hálón :)
ps2: staticusan linkelt
Belül regparamot használ, syscallnál vermeli le.
mmap,mprotecteket libc ,ld -beli függvények hivják másutt nem látok.
ps3: 


#include <string.h>
#include <sys/mman.h>
#include <errno.h>
void exploit()
{
;;
}

//faszom keresi meg most headerben
#define PAGE_MASK (~((long)4096-1))
int main()
{
	char haha[1024];
	memcpy(haha,exploit,1024); //remeljuk itt nem szal el.
#ifdef EXPLOIT_WORK	
	if (mprotect((void*)((long)haha&PAGE_MASK), 8192, PROT_READ|PROT_WRITE|PROT_EXEC))
	{
		perror("mprot");
	}
#endif	
	((void *(*)(void))haha)();
	return 0;
}

/tmp $make testmprot
cc testmprot.c -o testmprot
/tmp $ ./testmprot
Segmentation fault
/tmp $ rm testmprot
/tmp $ make CFLAGS=-DEXPLOIT_WORK testmprot
cc -DEXPLOIT_WORK testmprot.c -o testmprot
/tmp $ testmprot
/tmp $

Az en stackem nem futathato alapbol.
ps4: 


int fugveny()
{
 ;;
}
int main()

{
        *(char*) fugveny=0;
        getchar();
        fugveny();
        return 0;
}

Code szekciom nem irhato. (elszal getchar elott)

ps5:
4005e0: ba 07 00 00 00 mov $0x7,%edx
4005e5: be 00 20 00 00 mov $0x2000,%esi
4005ea: 48 81 e7 00 f0 ff ff and $0xfffffffffffff000,%rdi
4005f1: e8 ba fe ff ff callq 4004b0

A code secioba kerul be az mprotect prot parametere.

(amd64 -em van, mezei gentoo kernel, glibc 2.7)

Ha jól értem. PAX az után jó mitán a támadónak van egy irható futatható lapja, ez után nehzebben tudjon tevékenykedni (újabb lapokat szerezni pl., ). Itt feltételezzük, hogy a támadó nem ismeri a konfigurációt és nem is igyekszik azt megkerülni, az alkalmazás jó eséllyel elszál hibával, és lehet tanakodni, hogy támadás történt -e, vagy csak nem várt erőforrás igény.

A legfontasabb (gyakori desktop rendszeren)célpontoknál viszont ki kell kapcsolni ezt és a hasonló védelmet.

Kernel térrel meg úgy vagyok, ha már ott kodot tud fatutni az illető akkor az veszett fejsze nyele, ha rájön, hogy XY tipusó védelemmel van elrejtve Z infó úgy is kibányássza.

vanilla ágnak nem célja az ilyesmi, az ágakról, és összefonódottságokról majd később..

Kernel paraméterrel letíltható -e a teljes PAX olyan formában, hogy ne lassítson ?

"Ha jól értem. PAX az után jó mitán a támadónak van egy irható futatható lapja, ez után nehzebben tudjon tevékenykedni (újabb lapokat szerezni pl., ). Itt feltételezzük, hogy a támadó nem ismeri a konfigurációt és nem is igyekszik azt megkerülni, az alkalmazás jó eséllyel elszál hibával, és lehet tanakodni, hogy támadás történt -e, vagy csak nem várt erőforrás igény."

rtfm

"A legfontasabb (gyakori desktop rendszeren)célpontoknál viszont ki kell kapcsolni ezt és a hasonló védelmet."

En egesz jol elvagyok vele (es ha valaminel ki is kell kapcsolni, az csak 1).

"Kernel térrel meg úgy vagyok, ha már ott kodot tud fatutni az illető akkor az veszett fejsze nyele, ha rájön, hogy XY tipusó védelemmel van elrejtve Z infó úgy is kibányássza."

Nyilvan, a PaX celja epp ennek (a kodfuttatasnak, es nem csak a kernelben) megakadalyozasa.

Viszont akkor mar en is szeretnek par meresi eredmenyt, hogy szerinted mikor es mennyire lassit.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Igen, ezt en is lattam, de ebbol nekem pont az jon le, hogy egesz minimalis a performance hit (SEGMEXEC-nel kulonosen).

"Leszarom, hogy plusz munka kikapcsolni, de ha ki kell kapcsolni xy alkalmazsanal (pl. X) akkor kb. ugyan ott vagyok ahol a part szakad."
Miert is? Igy abban az 1-2 programban kell valami lyukat talalni az egyebkent meglevo ~100 helyett. Az eselyeidet mindenkepp noveli.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

( sartek | 2007. 11. 12., h – 10:49 )

a sabayon az nem ez? (bar nem tom h mennyire magyar)

Bináris! Működik! Nem mindenhol magyar és nincsenek benne a magyar vonatkozású csomagok pl ooo esetleg xqed. A karakterek igen furcsák ékezetekkel, ennek ellenére igen jól összerakott gentoo. Ezen a vonalon lehetne indulni. A forrásból fordítás fontos esetleg nekünk, de nem minden felhasználó tart rá igényt. Egy közösség összerakott produkcióját javítgatva/támogatva szivesen raknám minden hozzám forduló gépére. Néhány csomagot szivesen megcsinálok én is, csak ne kérje számon rajtam senki a frissítéseket időre, mert abból van most kevés.

dzsolt

( kikke | 2007. 11. 12., h – 11:00 )

A gentoo-ban azt nem értem, miért jó processzoridőt pazarolni binárisok fordítására, amikor ahelyett fehérjéket is kutathatna a jónép.

( n0gabor | 2007. 11. 12., h – 11:29 )

Sztem hulyeseg ezert uj disztrok kezdeni, egy csomo olyan meloval jar amit mar masok mar elvegeztek. Sztem csinaljaktok egy "GENTOO HUNGARY" repot vagy valami ilyesmit, ahol a "nagy" csomagokat forditjatok binarisba elore megadott USE flagekkel, illetve a magyar nyelv tamogatasat elosegito csomagokat tennetek. Igy maradna gentoo (a rengeteg elonyevel), de megis segitene sokaknak.

( KOXX | 2007. 11. 12., h – 12:30 )

Jó ötletnek tartom! Szerintem úgy kéne összehozni, hogy a Sabayon bosszúságai ne forduljanak meg benne, gondolok a nagy méretre és a Gentoo-hoz nem méltó lassúságra mellyet az Ubuntu simán lealáz. Az Ubuntu lehetne egy példakép, annak az irányelvei szerint összerakni, de mégis valami mást kihozni. Szerintem nagy előny a kis méret, a gyorsaság és egyszerűség, de a desktop felhasználó szükségleteinek kielégítése.

Nem elsődleges cél.
DVD -ben gondolkozok.

Szerintem e népek 90% felrak mindent, hogy megnézzük mi is az. 10Gb particoót rá tud szánni.

Knopper meg azt tudtja, hogy 1 DVD-re 10Gb szoftveret tesz fel ami vinyóra mehet, és utánna csomagkezelőböl legyilkolható.

Fejlesztési ütemterveben az első pre alfa dev snapshot verzióban nem valószinü, hogy default installon kivül lesz más. De a koncepció tartalmazza a gyors szelektív installációt függőség kezeléssel... etc.

Akinek nincs net kapcsolata, és nem tudja hálozatba kötni a gépet egy DVD olvasós/ vagy DVD tartalmát taratalmazó géppel, vagy vinyóra tenni az nem tudja telepíteni. Bár, ha az komoly vissza tartó erő hajlandó vagyok változtatni ezen.

Nem gond, ha DVD, de szerintem a telepített rendszer ne legyen nagyobb egy telepített Ubuntu-nál. 1 CD anyag bőven elég arra, hogy olyan rendszert kapj ami kielégíti a szükségleteket. 1 DVD már 5-ször ennyi tartalom, így hát az lenne a logikus, ha több ablakkezelő, esetleg választható csomagkészlet közül lehet választani telepítés közben, de a végeredmény ne lehessen egy Sabayon féle óriás halmaz, mely lassú mint a dög.

( portage | 2007. 11. 12., h – 21:33 )

A gentoohoz sok bináris van x86-ra és amd64-re, a nagyobb csomagokhoz mindig van friss.

Egyébként 1.5 nap alatt fordult le múltkor az egész rendszer p3-on (xorg, kde, firefox stb), szóval nem annyi idő, mint ahogy sokan felvázolják.

Akinek ez a megfelelő, az előbb-útóbb úgyis ráérez, hogy ezt érdemes használnia. A gli eredménye is csak annyi volt, hogy sok noob spamelt a fórumokra és ircre, így is már túl könnyű a telepítés, és sok olyan használja, akinek nem kéne, jelentősen rontva a színvonalat, és nekem úgy tűnik, hogy az analfabéták aránya is nőtt a felhasználótáborban mikor jött ez a gli baromság. Még 1-2 könnyítés (pl. infok elterjesztése fogyatékosoknak is érthető módon), és már az lesz kérdés hogy pl. mi az irc.

-------------------
2.6.22-gentoo-r8