🚀 go-pugleaf

Seweryn Habdank-Wojewódzki wrote:

> To znaczy właśnie nie kapuję jakie to jest bezpieczeństwo i przez czym?

[...]

> Rozumiem. Ale nadal nie rozumiem zagrożenia, które teoretycznie coś może
> wnieść do C++ z zewnątrz. Pomijam kwestię, że Ty możesz wnieść jakieś
> śmieci w swoim kodzie. Chodzi mi o to co może zrobić ktoś z zewnątrz?

A czym byłoby "zewnętrze" dla Ciebie, gdybyś miał oprogramować np. taką 
usługę:
http://www.4java.ca/sharedTomcat.htm?PHPSESSID=acec7b605c17dd3400279ad54fec91d1

?

(Żeby było jasne, nie reklamuję tego serwisu i nie wiem jak to zrobili, 
sądzę jednak, że całkiem sprawnie dałoby się sporo takich "shared" 
klientów na jednym Tomcacie hostować)


>> Żaden ze znanych mi systemów na taką swobodę nie pozwala.
> 
> DOS? Systemy, a w zasadzie loadery programów na małe procki.

OK, może przesadziłem.

>> Tu mówimy jednak o dość precyzyjnych zabiegach, które na poziomie C++ są
>> możliwe. Na poziomie platformy Javy (oczywiście, nie tylko) nie.
> 
> Nie; czy trudno?

No zważywszy, że JDK to raptem 6,5 MLOCów, powiedzieć kategoryczne nie 
to oczywiście nonsens...  I choć lista dotychczas wykrytych bugów w 
zabezpieczeniach Javy jest zadziwiająco krótka (mam nadzieję, że już tam 
trafiłeś), to jednak każdy ze zgłoszonych alertów (na dziś 342 w 
"category:security" od roku 2002), to potencjalna szansa zrobienia "a ku 
ku", więc na "na pewno nie" nie licz u mnie.

> To jest różnica. Bo jeśli trudno, to złośliwiec też Ci
> sypnie aplikację.

Możliwość jest, nieporównywalnie mniejsza jednak, niż w przypadku 
ewidentnych dziur.

Bezpieczeństwa 100% nic nie jest w stanie Ci zaoferować.  Javowe jest 
jednak IMHO na tyle dobre, aby przestać się jego łamaniem w normalnych 
warunkach zajmować.


> Poza tym cały czas zapominasz o bardzo prostym fakcie, że języki wysokiego
> rzędu nie sa tak wszędobylskie jak C i C++.

Nie zapominam.

> Zauważ, że na komórki jest JVM ME, ale nie jest tak, że ona eliminuje
> system. Zanim odpalisz JVM, to starują ci normalne programy napisane w C i
> C++. Szczególnie silny tu jest Symbian OS, który ma całkiem dobry
> kompilator C++ - nie znam jego biblioteki standardowej, ale komnpilator
> jest ok jak na taki mały sprzęt. Poza tym JVM ME to nie za dużo potrafi.

No coś Ty?  To co trzeba robić w tych środowiskach, to zupełnie poza 
tematem, tam to nawet do zmiennoprzecinków do niedawana nie było, jak 
myślisz, dlaczego?  Myślisz, że w obliczu ograniczeń platformy, 
dodatkowa ochrona kodu, która przecież za darmo nie jest, to rzecz 
priorytetowa?


> A ostatnia sprawa to kwestia wykorzystania naturalnych zasobów danego
> systemu/sprzętu. JVM dość unifikuje systemy i sprzęt (z tym są kłopoty), bo
> JVM w ogóle ma problem ze sprzętem, ale to pominę skupię się na samym
> systemie.

Java właśnie po to powstała, aby unifikować te wszystkie sposoby.  Co 
nie jest może zawsze pożądane, niemniej jak się okazuje, w wielu 
przypadkach jest wygodne.

> Są rzeczy specyficzne dla windowsa i dla unixa, i jak chcesz je
> użyć, to szybko kończysz na JNI, czy się mylę?

Bardzo się mylisz.  Większość kodu pod JVMy, przynajmniej wedle moich 
danych, pisze się dziś w Javie.

Natyw to ostateczność -- dość rzadko stosowana.  I to nawet nie ze 
względu na brak bezpieczeństwa, ale z uwagi na to, że JNI to nieco 
toporny interfejs, choć niestety, jak dotąd, jedyny porządnie 
działający.  Generelanie do nietypowych potrzeb.

> 
> Np. użycie użądzeń unixowych, czy typowych raw unix socket, albo sprawa
> pracy z ramdyskami. ale nie izolowanymi od systemu. Bo w JVM możesz zrobić
> ramdysk i możesz tam nawet zapuścić kompilację kodu i w ogóle różne rzeczy.
> Jednak ZTCW do tego ram dysku nie ma dostępu żaden inny proces systemowy.
> Albo dalej kazdy system ma swoje komendy wywłaszczające zadania. Jak to
> użyć? Raz z kolegą na linuksie odpaliliśmy sterownik który pracował w cyklu
> 100kHz, czyli odczyt danych, wyznaczenie sterowania, przekazanie sterowania
> na zewnątrz zabierało 10[us]. Ale po każdym takim teście sterowania, które
> nie było wykonywane a muzo, tylko na żywym sprzęcie (drivery do lasera),
> zegar systemowy czasu rzeczywistego (dla RTlinuxa) opóźniał się o czas
> eksperymentu. Już nie mówię o innych usługach systemu, które wisiały. Itd.
> itp. są rzeczy których Java nie oferuje, bo nie powinna. A ja właśnie
> takich spraw dotykam i dlatego wolę mieć niebezpieczny jezyk C++ czy C,
> który kiedy potrzebuję usłuży mi nisko osadzonymi w systemie usługami.

I do tego, ja też bym Javy, o której mówimy nie użył.

Musiałaby to być implementacja JSR-1, np. JamaicaVM 
(http://www.aicas.com/jamaica.html) -- choć co do jej jakości, musiałbym 
się najpierw przekonać, a nie mam jak dotąd takich potrzeb, może więc Ty 
ją wypróbujesz?  (W ewentualnych wynikach jestem oczywiście zainteresowany)

A!  I tu już, jak w każdym zresztą zaufanym sofcie, ochroną bym się 
najmniej przejmował.


Nadal jednak podtrzymuję zdanie, że mieć ochronę, która w razie potrzeby 
jest niezawodna (nawet jeśli tylko w teorii), jest lepiej, niż mieć ją 
dziurawą (co wykazane zostało).


piotr