ha ismert a hiba es nem lesz megoldas belathato idon belul akkor modositani kellene a dns-t hogy ne kelljen n+1 helyen atallitani utanna pedig visszaallitani a gepeket...
Lassan hetek óta nem jó, minden gépemet átállítottam a fő tárolókra. Mint minden, gondolom ennek az üzemeltetése is pénzbe kerül valakinek, de ha nem beszélnek róla akkor senki nem fogja megtudni mi a probléma és miben lehetne a segítségükre.
altalaban nemetet szoktam en is produkcios gepeken, de sokaig csak hallomasra tamaszkodva, nemreg viszont egy linode-os VPS kapcsan jottem ra, hogy mennyire szamottevo a kulonbseg mirror es mirror kozott.
Nem erdekel, szegyen-e vagy sem, valszeg eszrevettek.
Azt szeretnem, de remelem tompos mar megvalaszolta, hogy valaki alljon ide, mondja el mi a baj,
Ha nincs idejuk, esetleg csinalunk belole egy hirt ha kellene nekik ember, vagy forumtopicot, nem hiszem hogy barki ellenezne, hogy kirakjunk valamit, hogy "figyu, az FSN-nek most nem teglara, hanem sysadmin helpre lenne szuksege" - a portal meg teli van sysadminokkal.
Íme: vasárnap lerohadt a gép, reset sajnos nem segített rajta. Távolról sajnos ennyi lehetőség van.
Szerencsére van munkám, így ma csak kb. fél egyre tudtam bemenni a géphez (munkaidőben, mehettem volna este is). Két órányi szopás után 15 óra körül indult el.
Sok olyan sysadmin van a portálon, akiben annyira megbízol, hogy géptermi hozzáférést intézz neki (fizikai hozzáféréssel) egy olyan géphez, amelyről nem lenne szerencsés, ha valami kompromittált bináris kerülne ki, és hajlandó vasárnap, éjszaka, vagy munkaidő közepén a helyszínre utazni, és órákat eltölteni a javítással?
Mindezt ingyen persze.
# dig @dnsserver ftp.hu.debian.org
; <<>> DiG 9.7.2-P3 <<>> @dnsserver ftp.hu.debian.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16399
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 2, ADDITIONAL: 0
;; QUESTION SECTION:
;ftp.hu.debian.org. IN A
;; ANSWER SECTION:
ftp.hu.debian.org. 3600 IN CNAME ftp.fsn.hu.
ftp.fsn.hu. 14400 IN CNAME ftp.freepark.org.
ftp.freepark.org. 0 IN A 195.228.252.133
;; AUTHORITY SECTION:
freepark.org. 14397 IN NS ns.ntech.hu.
freepark.org. 14397 IN NS ns.fsn.hu.
;; Query time: 676 msec
;; SERVER: dnsserver#53(dnsserver)
;; WHEN: Mon Mar 21 16:22:00 2011
;; MSG SIZE rcvd: 142
miert jo a 0 erteku TTL az "ftp.freepark.org" cimre? igy a dns szerverem nem tudja berakni cache-be a cimet es minden lekeres 100x annyi ideig tart mint kellene...
Elég sok DNS szerver ha ilyen alacsony értékkel találkozik, akkor azt ignorálja, és beállít egy default értéket (1d, 1w, éppen ami), így a 0 károsabb lehet mint egy kicsit magasabb, de mindig elfogadott érték...
Lehet, hogy a kollega tulzott; tobben is azt jeleztek, a problema nem egyedi, es nem mostani; erre reagaltam. Nyilvan nem elvaras a 0.99 meg a 24 oran belul, de a "hetek" egy picit erosnek tunt.
Sz'tem 5-ot siman talalsz egyebkent ilyen emberbol itt.
Nyilvan egyebkent orulunk, hogy egyaltalan van aki csinalja, es nagyon szepen koszoni minden ubuntu/debian/ilyen-olyan modon fsn felhasznalo.
Mondjuk - minden tisztelet mellett - ha nem egy ember csinalna akkor nyugodtabb lennek - elmesz nyaralni / szoposabb munkahet van / beteg a gyerek oszt nincs debian repo egy hetig...
"megbízol, hogy géptermi hozzáférést intézz neki (fizikai hozzáféréssel) egy olyan géphez, amelyről nem lenne szerencsés, ha valami kompromittált bináris kerülne ki"
Ezzel nem teljes mertekben ertek egyet.
A felhasznalonak nem benned kell megbiznia, ezert van kulcsos hitelesites a csomagokhoz es egyeb kiadott dolgokhoz, nem?
Persze nyilvan nem szerencses az sem, ha egy mirror kompromittalodik, de azert nem ugyanaz, mintha a mirror forrasa kerul cikibe.
ok, arra azert vigyazz, hogy nehogy csupa olyan emberbe vetett bizalomra epuljon a rendszereid biztonsaga, akik bar jo barataid, de ido/szakertelem hianyaban nem tudnak felnoni a feladathoz(ala TC) :)
ezt nem tudom, csak tippeltem: tekintve hogy szakmailag nagyon keves embert ismersz el, es ez a csoport nagyban korrelal a sajat haveri korodhoz, ezert felteteleztem, hogy igen.
persze lehet hogy most ot csak azert emelted piedesztalra, hogy a tobbi hup-os olvaso szakertelmet pocskondiazhatsz ("öt bra-kaliberű ember a hupon, akiket még érdekel is ez a bohóckodás?")
de szerintem atment a mondanivalom. :)
ez a tipped majdnem ugyanannyira on-the-spot volt, mint az, hogy a kliens php-k biztonsága errefelé jelentékenyen befolyásolja a teljes rendszer biztonságát
mi az hogy kliens php-k?
meg hogy errefele?
sejtem hogy most meg szerettel volna alazni, de kicsit lehetnel bobeszedubb. :P
altalanossagban elmondhato, hogy a teljes rendszer biztonsaga == a rendszert alkoto reszegysegek leggyengebb elemenek a biztonsagaval. http://www.schneier.com/blog/archives/2005/12/weakest_link_se.html
miután megtudtam hogy a "kliensbe vetett bizalomra épül" világszerte a freebsd jail VPS-ek biztonsága, és ez schneier-ileg mélyen elítélendő, nem ölnék a felesleges kifejtési próbálkozásokba energiát ;)
ahogy erzed :)
ps: probaltam rakeresni az idezetre, de ugy tunik hogy nem sikerult pontosan masolnod.
tippem szerint erre gondolsz: http://hup.hu/node/89202#comment-1057149
ezzel kapcsolatban a mai napig fenttartom, hogy felelotlenseg a szuksegesnel magasabb prioritasokkal futtatni egy szolgaltatast, csak azert mert elmeletileg a masik szolgaltatas meg tudja vedeni.
kiveve amikor nem, pl. http://www.securityfocus.com/bid/40399 illetve a kernel bugok ellen nem tud/akar a jail vedeni.
Jails are a lightweight form of virtualization/containment premised on a shared kernel across protection domains--this means that a kernel vulnerability may allow access between protection domains. If your environment requires you to tolerate a kernel vulnerability, then you will need a non-kernel based virtualization system. Note that a very similar kind of reasoning applies to using hypervisors (such as Xen, VirtualBox, VMWare, etc) and vulnerabilities they might have: if you need to be able to tolerate a hypervisor vulnerability and maintain protection between two machines, then you can't use a hypervisor to keep them separate.
Tekintve, hogy (csakúgy mint a "case-sensitive" HFS+-t), úgy már az általad idézett CVE-2010-2022-t se olvastad el, továbbra sem lep meg hogy fogalom nélkül idézgeted a kezed ügyébe akadó google találatokat :) ("In the default FreeBSD jail configuration, it is not possible to break out of jails with this vulnerability")
Természetesen mindössze ennyi az elvárható, elvégre linuxot használsz.
a tortenelmi attekintesre nem reagalnek, ha nem gond.
a lenyeget nem akarod megerteni(amugy szerintem erted, csak nem akarod beismerni hogy a jailes dicsekvesed kapcsan butasagot irtal): a jail, ahogy minden nem trivialis szoftver tartalmaz hibakat, eppen ezert vakon hinni benne, hogy "dehat az megved mindentol" meg azt hajtogatni hogy "root-kent futtatom, mert freebsd-n ezt is megtehetem" eleg nagy butasag, plane amikor mar lattunk ra peldat, hogy talaltak sebezhetoseget a jailben, es a kernelben is. http://en.wikipedia.org/wiki/Principle_of_least_privilege
ha nem kell neki root, akkor ne rootkent fusson.
szerintem nem kevertem ossze, leven hogy a jailt indito init script szerintem csak a CVE-ben szerepelt, en sehol nem beszeltem rola, persze javits ki ha tevedek.
nem beszéltél róla (ahhoz ugye előbb el kellett volna olvasni), hanem elolvasás nélkül linkelted, egy olyan fogalomhoz amihez az égvilágon semmi de semmi köze
de ha "szerinted" ez nem összekeverés, akkor igazad van ;)
terelsz. :)
elolvastam a linket mielott kuldtem, te viszont meg mindig nem tudtad elolvasni es vagy ertelmezni az en irasomat:
ezzel kapcsolatban a mai napig fenttartom, hogy felelotlenseg a szuksegesnel magasabb prioritasokkal futtatni egy szolgaltatast, csak azert mert elmeletileg a masik szolgaltatas meg tudja vedeni.
kiveve amikor nem, pl. http://www.securityfocus.com/bid/40399 illetve a kernel bugok ellen nem tud/akar a jail vedeni.
letezo jail bug amit linkeltem? igen
amennyiben kihasznalhato akkor ki lehet maszni a jailbol? igen
javitotta a freebsd csapat? igen
ha lett volna ennel konyebben kihasznalhato jail sechol az elmult 1-2 evbol, akkor azt linkeltem volna, de leven hogy nem volt, igy ezt linkeltem.
amit csinalsz, az mar csak tereles, raadasul magadhoz kepest eleg gyenge.
The jail(8) utility does not change the current working directory while
imprisoning. The current working directory can be accessed by its
descendants.
By default, the FreeBSD /etc/rc.d/jail script, which can be enabled
using the jail_* rc.conf(5) variables, is not affected by this issue.
This is due to the default jail flags ("-l -U root") used to start a
jail as these flags will result in jail(8) performing a chdir(2) call.
If the rc.conf(5) variables jail_flags or jail__flags has been
set, and do not include '-l -U root', the jails are affected by the
vulnerability.
a jail nem valtott konyvtarat, ami nem volt gaz a default init scripttel, mert az ugy inditotta a jailt, hogy megtortent a konyvtarvaltas.
ha nem valt konyvtarat a jail, akkor az aktualis konyvtaron keresztul ki tud traverzalni a jailbol a tamado.
idezek a mitre.org-rol, hatha ugy konyebben megerted:
jail.c in jail in FreeBSD 8.0 and 8.1-PRERELEASE, when the "-l -U root" options are omitted, does not properly restrict access to the current working directory, which might allow local users to read, modify, or create arbitrary files via standard filesystem operations.
maga a hiba sulyos, de a kihasznalas eselye nem tul nagy, mivel valoszinuleg kevesen hasznalnak/tak custom init scriptet.
ettol fuggetlenul biztonsagi res, es szepen fixelte is a vendor.
Akkor már csak azt kell végre megértened, hogy e hiba szempontjából teljesen mindegy, hogy a jailen belül hány root-ként futó processz van, ami ellen oly' lelkesen próbálsz ezzel kardoskodni :) Meg mondjuk azt is, hogy nem "custom init script" használatáról van szó, hacsak az rc.conf időközben nem lett azzá kinevezve valahogy /o\
Megnyugtatásul közlöm, hogy linuxostól ez a tudás nem elvárható.
Akkor már csak azt kell végre megértened, hogy e hiba szempontjából teljesen mindegy, hogy a jailen belül hány root-ként futó processz van, ami ellen oly' lelkesen próbálsz ezzel kardoskodni
e hiba szempontjabol valoban mindegy, de azt hittem, hogy ezen mar tulleptunk, leirtam hogy csak azt volt hivatott bemutatni, hogy a jail sem hibatlan, es minel tobb jogosultsaga van (feleslegesen) a jailben a usernek, annal valoszinubb, hogy tudja exploitolni a sebezhetoseget amivel kimaszik a jailbol(ez ugyanigy van nem jail kornyezetben is).
Meg mondjuk azt is, hogy nem "custom init script" használatáról van szó, hacsak az rc.conf időközben nem lett azzá kinevezve valahogy /o\
ne mond mar, hogy az /etc/rc.d/jail az nem init script?
valoban a jail_* rc.conf -bol olvassa a configjat, de ettol meg init scriptrol beszelunk.
ha a "gyari" init scriptet, illetve configot hasznalod, es nem krealtal jail_flags or jail__flags valtozot, vagy csinaltal, de tartalmazza a '-l -U root' argumentumokat, akkor nem vagy sebezheto.
de ha osszetaknyoltal magadnak egy init scriptet, ami nem adja at ezeket a parametereket a jail-nek, vagy eppen "rosszul" adtad meg a jail flageket a gyari init scripthez tartozo configban, akkor rabasztal.
tényleg, egész eddig csak azért verted magad hogy "megmutasd": semmi se hibátlan? és ezzel kinek mondtál újat, captain obvious?
neked:
- Volt, hogy egy root joggal futó php-met nyomták fel, még a shutdown-t is próbálták linuxos aggyal paraméterezni, természetesen sikertelenül, dehát freebsd jail-ben ez egyébként is így járás ;)
linuxon mindez elég szomorúan végződött volna. Lehet ezért nem használom?..
- miert kellett root-tal futnia btw?
- Hogy érezzem hogy freebsd-n ezt is megtehetem ;))
nem futtatunk root-tal szolgaltatast, ha nincs ra szuksege.
Tehát életedben nem láttál ilyet (konkrétan ezt meg pláne), délelőtt még azt hitted hogy egy jail paramétereihez shell scriptet kell módosítani, de azért levonod a konzekvenciát hogy szerinted értesz hozzá (!), ahogy a case-sensitivity-hez, meg egyéb dolgokhoz is. Ahha. A királyi többes használata meg látom már régóta jól megy, alkalmazd is bőszen, komolyan sokkal jobban hangzanak tőle a magas igazságtartalmú okfejtéseid o/
délelőtt még azt hitted hogy egy jail paramétereihez shell scriptet kell módosítani,
legfeljebb te voltal ertetlen :)
ahogy a case-sensitivity-hez, meg egyéb dolgokhoz is.
mar megint a tortenelem. :)
ez itt kb. annyira relevans, mint hogy a felugyelted alatt a novara hanyszor allt meg, vagy nyomtak fel.
Ahha. A királyi többes használata meg látom már régóta jól megy, alkalmazd is bőszen, komolyan sokkal jobban hangzanak tőle a magas igazságtartalmú okfejtéseid o/
neked is megvan a sajat stilusod, nekem is, en is ~ toleralom a jo izles hatarain belul a tiedet, szerintem neked is menni fog, de ha nem, akkor ignoralj nyugodtan.
de relevans, ha kapcsolodik a targyhoz.
az hogy egyszer ordas faszsagot mondtam nem garantalja, hogy mindig tevedni fogok.
hiszen te is tevedtel mar, es megsem dolt ossze a vilag.
ezert, ha be akarod bizonyitani, hogy konkretan itt es most tevedek, akkor abbol kell dolgoznod, amit itt es most leirtam.
nem amit multkor egy masik topicban, vagy amit te belelatni veltel az egyik hozzaszolasomba.
félreérted, nem azt garantálja hogy tévedni fogsz, hanem azt, hogy más témában is nyugodt szívvel fogsz 0 tájékozottsággal annyi marhaságot annyit pofázni (a te olvasatodban: teorizálás), hogy az egész komment sáv két pixel lesz.
félreérted, nem azt garantálja hogy tévedni fogsz, hanem azt, hogy más témában is nyugodt szívvel fogsz 0 tájékozottsággal annyi marhaságot annyit pofázni (a te olvasatodban: teorizálás), hogy az egész komment sáv két pixel lesz.
mindig ketton all a vasar.
mivel te inditottad kettonk kozul ezt a beszelgetest, ezert ezzel a hozzaszolasommal pont ugyanannyi postot izzadtunk ki mindketten.
az hogy 0 tajekozottsaggal annyi marhasagot pofaztam ebben a szalban, az meg bizonyitasra var a reszedrol. :)
Köszi az infót. Trolloknak ignore=ON - én sem adnék "csak úgy" fizikai hozzáféréssel bíró full jogosultságot olyan rendszerhez, amiért első, második és sokadik körben is nekem kell tartani a hátamat...
Szurkolok a megoldáshoz, mert a cím a telepítő készletekben és sok telepített rendszerben is ez van beállítva és erre nincs felkészítve a csomagkezelő.
Hozzászólások
Az ftp.fsn.hu-n van ha jól tudom, elég gyakran haldoklik mostanában... A FSN.hu oldalon pedig semmi információt nem találni róla.
Ez így elég gáz, hogy sehol senki.
--
Vajon a BIX-be is van ilyen?
Hol sehol senki? Mit ertesz ez alatt?
tompos
http://www.fsn.hu/articles/projektjeink/index.html
http://www.fsn.hu/articles/mivel_foglalkozunk/index.html
http://www.fsn.hu/articles/az_fsn_alapitvany/index.html
http://www.fsn.hu/articles/elerhetosegein/index.html
Ahhoz képest, hogy nem most kezdték, nem kapkodják el az oldal feltöltését tartalommal.
Úgy értem, hogy nincs aki felügyelje a gépeket.
--
Vajon a BIX-be is van ilyen?
Van, aki felugyelje a gepeket. Halodnak a HDD-k. Ido, amig cserelni tudja.
tompos
mintha a debian is csatlakozott volna...
(ftp.hu.debian.org)
Az is az FSN.hu szerverén van, nem meglepő.
használd az ftp.bme.hu -t ;)
ha ismert a hiba es nem lesz megoldas belathato idon belul akkor modositani kellene a dns-t hogy ne kelljen n+1 helyen atallitani utanna pedig visszaallitani a gepeket...
udv Zoli
Lassan hetek óta nem jó, minden gépemet átállítottam a fő tárolókra. Mint minden, gondolom ennek az üzemeltetése is pénzbe kerül valakinek, de ha nem beszélnek róla akkor senki nem fogja megtudni mi a probléma és miben lehetne a segítségükre.
hasznaljatok masik mirrort, az fsn-es halott/haldoklik. :(
Tyrael
Időtlen idők óta a német tárolókat használom (korábban Ubuntum volt, még akkoriban áttértem, most Debian van, már eleve). Sosem volt panasz rájuk.
+1
Vagy a nemetet, vagy az osuosl taroloit hasznalom. It just works.
--
altalaban nemetet szoktam en is produkcios gepeken, de sokaig csak hallomasra tamaszkodva, nemreg viszont egy linode-os VPS kapcsan jottem ra, hogy mennyire szamottevo a kulonbseg mirror es mirror kozott.
Tyrael
+1, én is, csak valami miatt az egyik gépen a magyar maradt beállítva, de most korrigáltam...
Ahelyett, hogy itt sirtok, valaki irna valamelyik FSN-es csokanak?
Nagyon nem vagyok otthon a hazai free software korokben, Hunger vagy timar vagy bra vagy valaki ilyes figura nem dolgozik arrafele?
Trey esetleg ismerheti oket?
Nézd meg a főoldal alját az http://www.fsn.hu/ -n, hogy ki küldte be az egyetlen cikket :)
http://kovisoft.hu
Írtam bra-nak, hátha nem tud róla. Bár szerintem tud.
--
trey @ gépház
Ha eddig nem vettek eszre, akkor az nagyon nagy szegyen. Tudtommal a Nagios free termek.
--
Nem erdekel, szegyen-e vagy sem, valszeg eszrevettek.
Azt szeretnem, de remelem tompos mar megvalaszolta, hogy valaki alljon ide, mondja el mi a baj,
Ha nincs idejuk, esetleg csinalunk belole egy hirt ha kellene nekik ember, vagy forumtopicot, nem hiszem hogy barki ellenezne, hogy kirakjunk valamit, hogy "figyu, az FSN-nek most nem teglara, hanem sysadmin helpre lenne szuksege" - a portal meg teli van sysadminokkal.
Íme: vasárnap lerohadt a gép, reset sajnos nem segített rajta. Távolról sajnos ennyi lehetőség van.
Szerencsére van munkám, így ma csak kb. fél egyre tudtam bemenni a géphez (munkaidőben, mehettem volna este is). Két órányi szopás után 15 óra körül indult el.
Sok olyan sysadmin van a portálon, akiben annyira megbízol, hogy géptermi hozzáférést intézz neki (fizikai hozzáféréssel) egy olyan géphez, amelyről nem lenne szerencsés, ha valami kompromittált bináris kerülne ki, és hajlandó vasárnap, éjszaka, vagy munkaidő közepén a helyszínre utazni, és órákat eltölteni a javítással?
Mindezt ingyen persze.
Én kérek elnézést. :)
Köszönjük!
ps: ha jól tudom HP gépen fut a cucc, azon pedig van ILO, így kb minden elérhető távolról is. Én minden gépemen használom.
Nem, sajnos nem HP gépen fut, de a hardverhibát az ILO sem javítja.
A mostanában sűrű kimaradások oka lehet a mar régi hw? (vinyok pl)
Amennyiben igen lesz újra tégla projekt?
miert jo a 0 erteku TTL az "ftp.freepark.org" cimre? igy a dns szerverem nem tudja berakni cache-be a cimet es minden lekeres 100x annyi ideig tart mint kellene...
udv Zoli
Mondanám, hogy oka volt, de akkor azt is meg kellene magyaráznom. :)
Kivettem, köszönöm.
azert probalkozhatnal valamivel
udv Zoli
Nem értem, milyen kapcsolat van a kettő között?
-
Elég sok DNS szerver ha ilyen alacsony értékkel találkozik, akkor azt ignorálja, és beállít egy default értéket (1d, 1w, éppen ami), így a 0 károsabb lehet mint egy kicsit magasabb, de mindig elfogadott érték...
Szia,
Lehet, hogy a kollega tulzott; tobben is azt jeleztek, a problema nem egyedi, es nem mostani; erre reagaltam. Nyilvan nem elvaras a 0.99 meg a 24 oran belul, de a "hetek" egy picit erosnek tunt.
Sz'tem 5-ot siman talalsz egyebkent ilyen emberbol itt.
Nyilvan egyebkent orulunk, hogy egyaltalan van aki csinalja, es nagyon szepen koszoni minden ubuntu/debian/ilyen-olyan modon fsn felhasznalo.
Mondjuk - minden tisztelet mellett - ha nem egy ember csinalna akkor nyugodtabb lennek - elmesz nyaralni / szoposabb munkahet van / beteg a gyerek oszt nincs debian repo egy hetig...
öt bra-kaliberű ember a hupon, akiket még érdekel is ez a bohóckodás? nevezd meg őket
nekem elég lenne egyet is :)
--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.
Magyar virtus b.zdmeg, ahelyett, hogy jelentkeznetek :)
bambano, ha nem lenne messze nanas Budapesttol ;)
Nem vagyok otthon rendszergazda-kaliberekben, de az osszes profi magyar unix rendszergazdat megtalaljatok a HUP-on, nem? Ennyire vacak a kinalat?
Az osszes? Hubazzeg, mitol lenne?
tompos
ezért volt ott az "akit érdekel ez a bohóckodás" kitétel
Egyébként szerencsére össze lehet vetni kettejük munkásságát: bambano - bra ;)
hupmeme, ázz, ezt eddig észre se vettem :)
--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.
get a life!
először is köszönjük a részletes tájékoztatást
végülis... akár ;-) nyilván személyes "randik" után... de miért ne?
Üdv:
egy tégla tulajdonos ;-)
Ugy fel-1 eve en is felajanlottam a segitseget, azt valaszolta, hogy nem kell.
tompos
"megbízol, hogy géptermi hozzáférést intézz neki (fizikai hozzáféréssel) egy olyan géphez, amelyről nem lenne szerencsés, ha valami kompromittált bináris kerülne ki"
Ezzel nem teljes mertekben ertek egyet.
A felhasznalonak nem benned kell megbiznia, ezert van kulcsos hitelesites a csomagokhoz es egyeb kiadott dolgokhoz, nem?
Persze nyilvan nem szerencses az sem, ha egy mirror kompromittalodik, de azert nem ugyanaz, mintha a mirror forrasa kerul cikibe.
tompos
megpróbálom egy példával érzékeltetni: letöltöd turul16 gentó szerveréről a FreeBSD-8.2-RELEASE-amd64-memstick.img file-t
MD5 (FreeBSD-8.2-RELEASE-amd64-memstick.img) = a080100906400182eaea808873d1d952
mas kerdes, hogy vajon hanyan hasznaljak (pedig serult letoltesbol eredo telepites kozbeni WTF? ellen is ved)
Tyrael
és a példa folytatása: én nem, mert bra-ban megbízok
http://floridajim.com/images/cupingod.jpg
Tyrael
igen, "others" = turul16
ezzel azt akarod mondani hogy bra az isten? :)
Tyrael
akár egész nap is játszatnánk csőrrel etetést, de minek?
ok, arra azert vigyazz, hogy nehogy csupa olyan emberbe vetett bizalomra epuljon a rendszereid biztonsaga, akik bar jo barataid, de ido/szakertelem hianyaban nem tudnak felnoni a feladathoz(ala TC) :)
Tyrael
"ezzel azt akarod mondani", hogy bra jóbarátom?
ezt nem tudom, csak tippeltem: tekintve hogy szakmailag nagyon keves embert ismersz el, es ez a csoport nagyban korrelal a sajat haveri korodhoz, ezert felteteleztem, hogy igen.
persze lehet hogy most ot csak azert emelted piedesztalra, hogy a tobbi hup-os olvaso szakertelmet pocskondiazhatsz ("öt bra-kaliberű ember a hupon, akiket még érdekel is ez a bohóckodás?")
de szerintem atment a mondanivalom. :)
Tyrael
ez a tipped majdnem ugyanannyira on-the-spot volt, mint az, hogy a kliens php-k biztonsága errefelé jelentékenyen befolyásolja a teljes rendszer biztonságát
mi az hogy kliens php-k?
meg hogy errefele?
sejtem hogy most meg szerettel volna alazni, de kicsit lehetnel bobeszedubb. :P
altalanossagban elmondhato, hogy a teljes rendszer biztonsaga == a rendszert alkoto reszegysegek leggyengebb elemenek a biztonsagaval.
http://www.schneier.com/blog/archives/2005/12/weakest_link_se.html
Tyrael
miután megtudtam hogy a "kliensbe vetett bizalomra épül" világszerte a freebsd jail VPS-ek biztonsága, és ez schneier-ileg mélyen elítélendő, nem ölnék a felesleges kifejtési próbálkozásokba energiát ;)
ahogy erzed :)
ps: probaltam rakeresni az idezetre, de ugy tunik hogy nem sikerult pontosan masolnod.
tippem szerint erre gondolsz:
http://hup.hu/node/89202#comment-1057149
ezzel kapcsolatban a mai napig fenttartom, hogy felelotlenseg a szuksegesnel magasabb prioritasokkal futtatni egy szolgaltatast, csak azert mert elmeletileg a masik szolgaltatas meg tudja vedeni.
kiveve amikor nem, pl. http://www.securityfocus.com/bid/40399 illetve a kernel bugok ellen nem tud/akar a jail vedeni.
Tyrael
jó de te linuxot használsz
?
mit szerettel volna ezzel mondani?
Tyrael
hát csak ezzel deklarálom milyen fajsúlyos a mondanivalód security témában, ha már az otherOS megvolt
tehat attertunk a szemelyeskedesre, ha mar az ervekbol kifogytunk?
"a multban mar tevedtel, ezert minden allitasod hamis" az nem erv. :)
ha mar csak ez megy, akkor hagyjuk itt abba, szerintem.
Tyrael
már rég áttértünk, biztos nem olvastad
o, dehat az csak barati jotanacs volt :)
Tyrael
:]
group hug?
:)
amugy latom mar fel is kerult a hupmeme-be a hozzaszolasom ahol rwatson-t idezem.
http://forums.freebsd.org/showpost.php?p=7824&postcount=13
ezt hivjak ongolnak?
Tyrael
Tekintve, hogy (csakúgy mint a "case-sensitive" HFS+-t), úgy már az általad idézett CVE-2010-2022-t se olvastad el, továbbra sem lep meg hogy fogalom nélkül idézgeted a kezed ügyébe akadó google találatokat :) ("In the default FreeBSD jail configuration, it is not possible to break out of jails with this vulnerability")
Természetesen mindössze ennyi az elvárható, elvégre linuxot használsz.
a tortenelmi attekintesre nem reagalnek, ha nem gond.
a lenyeget nem akarod megerteni(amugy szerintem erted, csak nem akarod beismerni hogy a jailes dicsekvesed kapcsan butasagot irtal): a jail, ahogy minden nem trivialis szoftver tartalmaz hibakat, eppen ezert vakon hinni benne, hogy "dehat az megved mindentol" meg azt hajtogatni hogy "root-kent futtatom, mert freebsd-n ezt is megtehetem" eleg nagy butasag, plane amikor mar lattunk ra peldat, hogy talaltak sebezhetoseget a jailben, es a kernelben is.
http://en.wikipedia.org/wiki/Principle_of_least_privilege
ha nem kell neki root, akkor ne rootkent fusson.
Tyrael
egyelőre még a "jailben futó php" és a "jailt indító init script" szcenáriókat is összekeverted, szóval léccine
egyébként is: linuxot használsz
szerintem nem kevertem ossze, leven hogy a jailt indito init script szerintem csak a CVE-ben szerepelt, en sehol nem beszeltem rola, persze javits ki ha tevedek.
Tyrael
nem beszéltél róla (ahhoz ugye előbb el kellett volna olvasni), hanem elolvasás nélkül linkelted, egy olyan fogalomhoz amihez az égvilágon semmi de semmi köze
de ha "szerinted" ez nem összekeverés, akkor igazad van ;)
terelsz. :)
elolvastam a linket mielott kuldtem, te viszont meg mindig nem tudtad elolvasni es vagy ertelmezni az en irasomat:
letezo jail bug amit linkeltem? igen
amennyiben kihasznalhato akkor ki lehet maszni a jailbol? igen
javitotta a freebsd csapat? igen
ha lett volna ennel konyebben kihasznalhato jail sechol az elmult 1-2 evbol, akkor azt linkeltem volna, de leven hogy nem volt, igy ezt linkeltem.
amit csinalsz, az mar csak tereles, raadasul magadhoz kepest eleg gyenge.
Tyrael
már vagy harmadszor idézed, és még mindig nem olvastad el /o\
The jail(8) utility does not change the current working directory while
imprisoning. The current working directory can be accessed by its
descendants.
Ez mitől jail-breaking sechole? ;)
mondjuk linuxot használsz, szóval érthető hogy nem érted az egybefüggő leírt szöveget :(
meg mindig nem olvastad el a CVE-t. /o\
http://security.freebsd.org/advisories/FreeBSD-SA-10:04.jail.asc
a jail nem valtott konyvtarat, ami nem volt gaz a default init scripttel, mert az ugy inditotta a jailt, hogy megtortent a konyvtarvaltas.
ha nem valt konyvtarat a jail, akkor az aktualis konyvtaron keresztul ki tud traverzalni a jailbol a tamado.
idezek a mitre.org-rol, hatha ugy konyebben megerted:
maga a hiba sulyos, de a kihasznalas eselye nem tul nagy, mivel valoszinuleg kevesen hasznalnak/tak custom init scriptet.
ettol fuggetlenul biztonsagi res, es szepen fixelte is a vendor.
Tyrael
Akkor már csak azt kell végre megértened, hogy e hiba szempontjából teljesen mindegy, hogy a jailen belül hány root-ként futó processz van, ami ellen oly' lelkesen próbálsz ezzel kardoskodni :) Meg mondjuk azt is, hogy nem "custom init script" használatáról van szó, hacsak az rc.conf időközben nem lett azzá kinevezve valahogy /o\
Megnyugtatásul közlöm, hogy linuxostól ez a tudás nem elvárható.
akkor lassan, utoljara, hogy te is megertsd. :)
e hiba szempontjabol valoban mindegy, de azt hittem, hogy ezen mar tulleptunk, leirtam hogy csak azt volt hivatott bemutatni, hogy a jail sem hibatlan, es minel tobb jogosultsaga van (feleslegesen) a jailben a usernek, annal valoszinubb, hogy tudja exploitolni a sebezhetoseget amivel kimaszik a jailbol(ez ugyanigy van nem jail kornyezetben is).
ne mond mar, hogy az /etc/rc.d/jail az nem init script?
valoban a jail_* rc.conf -bol olvassa a configjat, de ettol meg init scriptrol beszelunk.
ha a "gyari" init scriptet, illetve configot hasznalod, es nem krealtal jail_flags or jail__flags valtozot, vagy csinaltal, de tartalmazza a '-l -U root' argumentumokat, akkor nem vagy sebezheto.
de ha osszetaknyoltal magadnak egy init scriptet, ami nem adja at ezeket a parametereket a jail-nek, vagy eppen "rosszul" adtad meg a jail flageket a gyari init scripthez tartozo configban, akkor rabasztal.
Tyrael
tényleg, egész eddig csak azért verted magad hogy "megmutasd": semmi se hibátlan? és ezzel kinek mondtál újat, captain obvious?
"osszetaknyoltal magadnak egy init scriptet" /o\
mondjuk az látszik soha életedben nem csináltál jailt
mar megint csak a tereles, meg a maszatolas.
neked:
nem futtatunk root-tal szolgaltatast, ha nincs ra szuksege.
en hasznalnam a gyarit, de nehanyan csinaljak
http://www.google.hu/#sclient=psy&hl=hu&q=freebsd+jail+init+OR+startup+…
valoban nem csinaltam, de a hozzaszolasaink alapjan nem latszik rajtad a gyakorlatbol fakado tudaskulonbseg :/
Tyrael
Tehát életedben nem láttál ilyet (konkrétan ezt meg pláne), délelőtt még azt hitted hogy egy jail paramétereihez shell scriptet kell módosítani, de azért levonod a konzekvenciát hogy szerinted értesz hozzá (!), ahogy a case-sensitivity-hez, meg egyéb dolgokhoz is. Ahha. A királyi többes használata meg látom már régóta jól megy, alkalmazd is bőszen, komolyan sokkal jobban hangzanak tőle a magas igazságtartalmú okfejtéseid o/
de buta vagy. :)
http://hup.hu/node/59810#comment-624034
legfeljebb te voltal ertetlen :)
mar megint a tortenelem. :)
ez itt kb. annyira relevans, mint hogy a felugyelted alatt a novara hanyszor allt meg, vagy nyomtak fel.
neked is megvan a sajat stilusod, nekem is, en is ~ toleralom a jo izles hatarain belul a tiedet, szerintem neked is menni fog, de ha nem, akkor ignoralj nyugodtan.
Tyrael
jó akkor ami neked kínos, az "nem releváns"
akkor igazad van :)
de relevans, ha kapcsolodik a targyhoz.
az hogy egyszer ordas faszsagot mondtam nem garantalja, hogy mindig tevedni fogok.
hiszen te is tevedtel mar, es megsem dolt ossze a vilag.
ezert, ha be akarod bizonyitani, hogy konkretan itt es most tevedek, akkor abbol kell dolgoznod, amit itt es most leirtam.
nem amit multkor egy masik topicban, vagy amit te belelatni veltel az egyik hozzaszolasomba.
Tyrael
félreérted, nem azt garantálja hogy tévedni fogsz, hanem azt, hogy más témában is nyugodt szívvel fogsz 0 tájékozottsággal annyi marhaságot annyit pofázni (a te olvasatodban: teorizálás), hogy az egész komment sáv két pixel lesz.
QED
mindig ketton all a vasar.
mivel te inditottad kettonk kozul ezt a beszelgetest, ezert ezzel a hozzaszolasommal pont ugyanannyi postot izzadtunk ki mindketten.
az hogy 0 tajekozottsaggal annyi marhasagot pofaztam ebben a szalban, az meg bizonyitasra var a reszedrol. :)
Tyrael
"te inditottad kettonk kozul ezt a beszelgetest"
... még ezt is elbasztad ...
a beszelgetesunk itt indult.
vadasz, vadasz te szopni jarsz ide. :)
Tyrael
így már tényleg értem hogy szerinted miért van neked mindig igazad o/
offtopic: ez egy karlenditos smiley?
Tyrael
-
Köszi az infót. Trolloknak ignore=ON - én sem adnék "csak úgy" fizikai hozzáféréssel bíró full jogosultságot olyan rendszerhez, amiért első, második és sokadik körben is nekem kell tartani a hátamat...
Sajnos már rég gond van vele :(
Szurkolok a megoldáshoz, mert a cím a telepítő készletekben és sok telepített rendszerben is ez van beállítva és erre nincs felkészítve a csomagkezelő.
OFF: Upgradelték seed és openrelay szerverré.
szerintem elfogytak a téglák...
ubuntu.sth.sze.hu ekvivalens?
Nem, az a győri Széchenyi István Egyetemen van: http://ubuntu.hu/node/12791
Működik újra jól láttam?
http://hup.hu/node/100803#comment-1246996
Tyrael
[fintorgó on]
"Egy ideje nem elérhető..."
emlékét kegyelettel megőrizzük....
[fintorgó off]
--
Aspire_3690 & bP_10.1.1
"amióta esténként kikapcsolom a mobilomat, utolérhetetlen vagyok az ágyban." - ismeretlen szerző