VIM 7 + Ruby -- bezpečnost zadupána do země novými funkcemi? (diskuse)

[JiK]

vim je ten uberkool editor, co ho lidi obcas spousti i vzdalene, na serverech, aby editovali nejake konfiguraky? A casto s pravy roota aby meli pravo ty konfiguraky menit? No, asi zustanu u Mac OS X.

[Michal Vyskočil]

Vim na OS X snad tuto vlastnost nemá? Nebo jsou tam konfiguráky zásadně psány v Ruby?

[happy barney]

Elvis žije

[zde]

A jak si hento, Kefalín, taký útok představujete? Pomodlíte se ke Klausovi a na začátku konfiguráku se objeví require "my-evil-script.rb", vim se přepne do ruby-mode, a v site-packages se objeví váš zákeřný exploit, aby jej vim mohl spustit?

[Martin Povolný]

1. krok: pusťte si irb, napište $: a podívejte se, jaké máte implicitně nastavené cesty.

2. krok (pokud vám to ještě nedocvaklo) zkuste to samé ve VIMu (v 'a.rb' přidejte řádek system("echo #{$:.inspect} >> /tmp/zde_je_pako") .

3. krok (pokud vám to ani teď nedocvaklo) - zamyslete se nad tím, jestli je třeba možné, že by někdo pustil VIM z adresáře /tmp/.

4. krok a) pokud vám to už docvaklo, nasypte si popel na hlavu a příště před psaním ironického příspěvku přemýšlejte, b) pokud se cvaknutí stále nedostavilo, změňte povolání

[kaaja]

Jestli jsem to pochopil, tak to nebyl ironicky prispevek na blog, ale spis ironicky prispevek na ten prispevek, ktery pise o tom, ze to muze byt nebezpecne pri editaci konfguraku. Mysim, ze autor pochopil, jak to funguje, ale chtel tim rict, ze kdyz uzivatel nebude blbej tak se pri editaci konfiguraku na serveru nemuze nic stat.

[Kyosuke]

Kromě toho, nepřijde mi, že by tenhle bezva sajt byl nezabezpečenej. I ten loading kvůli zjištění názvů metod by měl jít celkem rozumně zasandboxovat. Jen by se o to měl přičinit autor...

[zde]

1) pokud má Ruby jako prioritní search path pro moduly ".", je to jistý bezpečnostní nedostatek, ovšem pro Ruby, ne pro Vim.

2) Pusťte si Bash. Pod rootem napište echo >/etc/povolny_je_pako, a stiskněte ENTER (ta velká klávesa napravo se zalomenou šipkou). Ha! bash je děravý.

3) To samozřejmě možné je, ale netuším co tím chcete dokázat.

4) Myslím že vaše rady nebudu brát příliš vážně.

[Josef Kufner]

Účel bashe je ten, že se používá ke spouštění příkazů/skriptů. Účel vimu a je editace souborů. Vidíš ten rozdíl?

[Martin Povolný]

1) pokud má Ruby jako prioritní search path pro moduly ".", je to jistý bezpečnostní nedostatek, ovšem pro Ruby, ne pro Vim.

Jako prioritní ne, ale v serch path '.' má a to stačí. A problém VIMu to je, protože mluvíme o variantě, kdy je VIM linkován s Ruby a VIM nevhodným způsobem Ruby používá (nenastavuje $SAFE).

2) Pusťte si Bash. Pod rootem napište echo >/etc/povolny_je_pako, a stiskněte ENTER (ta velká klávesa napravo se zalomenou šipkou). Ha! bash je děravý.

No to je dost mizerný vtip a ještě horší přirovnání.

3) To samozřejmě možné je, ale netuším co tím chcete dokázat.

Třeba to, že exploit zranitelnosti, kterou jsem popsal je poměrně proveditelný.

[Martin]

Hmmm, tak to je drsný.

[Jan Kundrát (jkt)]

Otazka spis je, jak to resit. Python ma treba nejaky sandbox, ktery dokaze kod celkem silne omezit (za predpokladu, ze je bastilla bez chyb, teda). Umi Ruby neco podobneho?

Jo a btw, uz jsi poslal bugreport?

[Mikos]

Řešit code completion za pomoci vykonání kódu mi přijde jako vrchol idiocie ať by se jednalo o jakýkoliv jazyk. To je prostě stupidita nejvyššího kalibru, nemůžu si pomoct...

[Heron]

Asi tak. Při čtení blogu jsem byl lehce v šoku, jestli je něco takového vůbec možné.

[Jan Kundrát (jkt)]

Zajimalo by me, jak si chces jinak poradit s nekterymi vlastnostmi, ktere treba Python ma...

[Kyosuke]

Jsou IPython a irb idiotský software, když nabízejí code completion již vykonaného kódu?

[Martin Povolný]

irb je naprosto jiná situace. Jak jste sám napsal, k nabízení variant doplnění tam dochází pomocí introspekce v kontextu již vykonaného kódu.

Zatímco VIM ten kód k nalezení variant vykoná.

[Kyosuke]

No, "jiná"...a v tom je ten největší průšvih. Ona je to siuace přesně tatáž. Jinak než z již vykonaného kódu se v jazycích jako Python, Ruby a Lisp doplňovat prostě nedá. Používám hlavně Slime, takže mi to vlastně ani nevadí a už mi přijde úplně přirozené, že completion bere v úvahu kód, který jsem již napsal, načetl a vyzkoušel. (Stejně si ho člověk krátce po napsání chce taky vyzkoušet, že jo... ) Třeba ty accessory v Ruby a v Lispu prostě jinak zjistit nejdou, leda, že by se udělala ad-hoc omezená statická analýza omezená pouze na standardní jazyk. Což by ve větším kódu asi dlouho nevydrželo.

[Kyosuke]

Mimochodem, připomínám, že Tcl je na tom ještě mnohem hůř. Tam bez evaluace nemůže fungovat ani syntaktický verifikátor, natožpak nějaký doplňovač... (Forth vynechám, ten je na tom teoreticky nejhůř, ale asi se neočekává, že by někdo do několikakilobajtového softwaru montoval Visual Studio )

[Tom.š Ze.le.in]

A co code walker, ten by nefungoval? :)

Jinak mi přijde, že problém není ani tak ve vlastním kódu, ale když si chci prohlédnout cizí kód než ho spustím... Jak to dělá slime (jsem vimista, takže nemám zkušenost) - načítá kód až když se mu řekne, nebo iniciativně sám od sebe?

[Kyosuke]

Mno, kdyby byl turingovsky úplný...

Slime to řeší úplně jednoduše s přímočaře. C-c C-k provede compile-file a load. Tím pádem se dostane kód do běžícího lispu a je přístupný pro swank (serverová část Slime). Completion je řešená na straně serveru, tedy v tom bežícím procesu. Slime klient v Emacsu tedy nepředstírá, že umí doplňovat symboly z aktuálního souboru - to umět samozřejmě nemůže. Tahá si je ze spuštěného image.

Zákonitě se nenajde nikdo, komu by to vadilo, přestože jde o tentýž proces, jako v případě Vimu a Ruby. Jediný rozdíl je v tom, že tady je ta kompilace explicitní.

Mimochodem, fuzzy code completion ve Slime je z pohledu lispera úplný mazlíček. Třeba negado expanduje na most-negative-double-float, wiof na with-open-file...prostě expanduje podle procenta fuzzy matche dost vychytaným způsobem... To by možná ocenili i javisti a C#aři, kdyby jim oumeme + TAB samo vyhodilo OutOfMemoryException (OutOfMemoryError) a nemuseli se se vším tak psát, zvlášť, když z toho dělají proměnnou a musejí to psát dvakrát.

[Hynek (Pichi) Vychodil]

Asi tak, jen do toho seznamu ještě přidej Perl. A to nemluvě o tom, že v Perlu lze jít ještě dál a nevytvářet accessor při include (method import) jiného modulu, ale třeba až uvnitř AUTOLOADERU, takže code completion pak není možné vůbec. Mimochodem zrovna před 14 dny jsem si cvičně naprogramoval takovou knihovnu, která právě tohle dělá. Pokud se pokusím použít metodu, která ještě není natažená, tak se v autoloaderu zjistí jestli náhodou některý z atributů objektu právě takovou metodu neposkytuje, výjimka se generuje až při nenalezení. Code completion se s takovým zdrojákem pak nedá provádět ani když se provede evaluace.

[Kyosuke]

No jo, s autoloaderem jsem měl problémy už ve Smalltalku. Docela by mě zajímalo, co na tomhle poli šikovných fíčur vznikne v průběhu příštích dvaceti let a jak se s tím editory vypořídají.

[happy barney]

20? Stačí pozrieť na úlety perl 6, napr. definícia operátorov.
Ak tomu dobre rozumiem, bude možný i takýto zápis (samozrejme, po správnej príprave)

if ($a == ($b ± autobus)) {
  ...
}

hmm, a to sa jeden čuduje, prečo im ten vývoj trvá tak dlho

[Mikos]

To byl vtip? On je trochu rozdíl mezi textovým editorem a interaktivním interpretrem. VIM se pokud vím interaktivním interpretrem nenazývá

[Kyosuke]

Ne tak docela. Spousta editorů ten interpret obsahuje nebo nějaký umožňuje používat. Nehledě na to, že já zásadně nepoužívám textové editory. Používám výhradně interaktivní interpret Emacs Lispu, který se (jen) jako textový editor defaultně tváří.

[Mikos]

Jo, Emacs to je dobrý operační systém, jen v něm chybí pořádný textový editor

[Mikos]

Jinak já nepoužívam ani VIM ani Emacs Na běžné věci používam Kate a když programuju v Pythonu tak Eric3 (který autocompletion v Pythonu dělá a to aniž by vykonával kód ). Sice v něm to doplňování kódu asi nebude tak "dokonalé" jako v editorech který ten kód vykonávají, ale mně to stačí a nemusim se bát, že mi textový editor napáchá škody v systému

No a jako interaktivní interpretr nejčastěji používám výborný IPython, ten nemá konkurenci

[Mikos]

Doplnění: Jsem holt "klikoš" A v konzoli třeba na editaci konfiguráků mi bohatě stačí nano

[Kyosuke]

Mno, IPython je skvělý, to jo. Jenže pak jsem vyzkoušel Slime a už to bylo...

Možná by to stálo za nějaký Slime-reklamní blogpost. Nebo rovnou video.

[Tom.š Ze.le.in]

Ale to už přece existuje... :)

[Kyosuke]

Tohle video?

http://common-lisp.net/movies/slime.mov

No jo, ale já stejně přemýšlím, že v téhle zemi se tvoří příliš málo screencastů... Taková skvélá forma sdělování informací a ono kde nic, tu nic.

[Tom.š Ze.le.in]

Podle linku to je ono (neotvíral jsem).

Co se týče tohohle způsobu prezentace, tak to nemám moc rád, protože je to na mne moc pomalé a špatně se přeskakuje co člověka nezajímá (narozdíl od textu).

Co se týče myšlenky propagace slimu, tak souběžně s tím by se musel asi propagovat i (Common) Lisp - protože těm, co ho nepoužívají je slime na nic moc. A mám pocit, že v tomhle ohledu tahle země není zrovna na špici.

Každopádně alespoň reklamní blogpost by se hodil, tady jsme dost off-topic :)

[Mikos]

((Děkuji) (((ale o Lisp (nemám)) ((zrovna moc) zájem))))

(((vím, ((jsem ignorant) a tohle) je) poněkud laciný) (humor))

[Kyosuke]

Ale nechybí... Neupírám Vimu jednu přednost: Mnoho textových editorů obsahuje závažný bug, který náhodně poškozuje editovaný text a vkládá do něj náhodný šum, například :wq!, ZZ nebo qq. Ani Emacs se tomu nevyhnul. Vim je zato z nějakého důvodu imunní.

Mimochodem, převeďte si "vi vi vi" z římských číslic na arabské a pochopíte postoj Církve Emacsu k tomuto tématu...

[Kyosuke]

Řekl bych, že zrovna Ruby tohle řeší podstatně líp, než Python:

http://www.rubycentral.com/book/taint.html

Jenže tu jsou principielní problémy - metody, které by byly vytvořené/definované až po provedení akce, která bude znemožněna, samozřejmě nikdy nevzniknou, ať už bude model ochrany jakýkoliv. Sice ke škodě nedojde, ale completion prostě nebude. Statickým parsingem zase všechny metody člověk nezjistí, nebo aspoň ne obecně. Můžu mít ošetřený attr_reader, attr_writer a attr_accessor, ale podobné "metaprogramovací metody" si člověk může nadefinovat sám a pak je editor bez pomoci v pytli.

Vítejte do světa dynamických jazyků...

[Kyosuke]

Jenom ještě podotknu, že není snad takový problém do kódu, který je součástí většího softwaru (psaného po jednotlivých modulech s definicemi, v kontrastu s one-off skriptem v jednom souboru a převážně bez metod a s okamžitým prováděním příkazů), nepsat příkazy, které způsobí side-effecty při načítání. Takže ne omylem, ale spíš hloupostí, Jó, kdo přičichne k lispu, uvědomí si, že i pouhá kompilace může mít side-effecty, protože při ní dochází třeba ke spouštění makrofunkcí (ty side-effecty ovšem mohou být záměr).

[Martin Povolný]

Pozorný čtenář si všim, že tento odkaz se součástí mého původního blogpostu.

Méně pozorný ne

[Kyosuke]

Už jsem usínal a adresa mi unikla...

[Josef Kufner]

Poslal jste jim uz nekdo bugreport s nejvyssi prioritou?

[Martin Povolný]

Vzhledem k tomu, že nemají bugzillu ani nic podobného, tak jsem jim poslal akorát mail do mailing listu.

[Josef Kufner]

Lepší než nic.

[abr]

Tak proto tak nektere distra otaleji s balickama 7ky (btw nekdy paticka nelze )

[Lukáš Rýdlo]

OT: Nojo, nemate programovat v takovym pochybnym jazyce, ktery je uplne naRuby