السلام عليكم
السيكيوريتى model فى الجافا يتبع موديل اسمه sandbox model ومعناه انه كل java appliation هنتخيله مسجون فى sand-box بحيث اى local class يقدر يعمل اى حاجة ... يعنى free زى العصافير اللى بتدور حوالين أبو زعبل ..... عارفينها ؟
واى remote class ميقدرش يعمل غير حاجات بسيطة جدا وميقدرش يعمل حاجات كتير زى انه مثلا ملوش حق ال read/write ولا انه يعمل اى connection سوى لل server اللى جه منه بس علشان لو جاى من مكان مش موثوق يبقى ميقدرش يتصل غير باصحابه بس ..... ممكن علشان يطلب منهم النجدة
... وطبعا ميقدرش يعمل اى process جديدة ..... جديدة مش حديدة ... ركز معايا يا بنى الله يخليك
وطبعا مبقدرش يعمل loading لاى native library
طبعا الكلام اللى فات ده by default إلا إذا سيادتك حنيت عليه
طبعا لما انت بتشغل عتريس فوكس ...... هو اللى بيتولى مسؤلية تشغيل ال application فى san box
وانت ملكش دعوة خالص بالليلة
طبعا انت ممكن تبقى خنيق وتتدخل ..... كل حاجة as you like
java sandbox architecture : * class loader
* class file verifier
* safety features built into jaa language itself
* security manager and java API
نبتدى نتعامل مع واحد واحد كدة ونبين الدنيا ماشية ازاى
(
1 class loaderطبعا بتمنع ال malicious code من انه يتحمل .....واحد يقوللى ازاى ... اقولله انه ممكن زى ما بيحصل فى الملفات التنفيذية فى ويندوز ... ييجى فيروس ابن حلال يحط ال instructions بتاعته فى وسط الملف وانت زى الشاطر تضغط على الملف فيبدأ البرنامج يشتغل ولكن الاكواد بتاع الفيروس بتتحمل هى كمان فى ال memory وتبدأ تشتغل ....... لكن فى الجافا فى عملية checking جامدة جدا قبل ال loading نا بيحصل
كمان ال class loaders تضمن انه ال classes اللى متلودة باستخدام different class loaders تبقى فى different name spaces ومتشوفش بعضها الا اذا كنت سيادتك عامل mechanism تحقق ده وطبعا اتا بتكلم عن ال loading مش ال instantiation فى الوقت الراهن .... لان ال loading بيحصل الاول طبعا
يعنى سيادنك مثلا ممكن تعمل كذا instance من نفس ال class اللى معمول له load مرة واحدة ..... لكن هل تقدر تلود كلاس واحد أكتر من مرة ؟ !!!!!
اه ولا لأ ؟
ايوة يا عم الأمور ..... امال احنا بنقول فى ايه من الصبح .... ممكن لانه ممكن الوده باستخدمه 3 different class loaders وبكدة يبقى كل واحد فيهم فى different name space
(2) class file verifierالباشا ده بقة ......... تلميذ
لأ لأ بجد ...... الياشا ده بيبدأ شغله بعد ما تم عمل loading خلاص وقبل ما يتم عمل execution للكود وبيعمل شوية interesting checks زى :
A ) Internal checks يتأكد انه اللى اتلود ده class اساسا مش حاجة تانية ويشيك على ال magic number وهو بالنسبة للجافا 0xCAFEBABE وللى ما يعرفش ال magic number هو number سداسى عشر واى ملف binary بيبدأ بيه علشان يميزه وكل نوع ملفات لها رقم تمييزى معين وهو ده اللى بيتقرأ بواسطة الأمر file فى linux واللى بيتعرف على انواع الملفات عن طريق قراءة شوية ال bytes اللى فى الاول دول ومقارنتهم ب database عنده فى
/etc/magic وممكن سيادتك تفتحها علشان تشوف بعض انوا ع الملفات كنوع من الفضول ............ وإن كنت أنصحك متعملش كدة .... مسمعتش عن الفول اللى قتل الفار
وكعادة اى ملف dummy فى الدنيا الفورمات بتاعه بيبقى كالتالى شوية بايتس تقولك حجم ال field قد ايه متبوعة بال data بتاع ال field ده وطبعا ال class file مش استثناء .... واللذيذ بقى انه ال verifier بقة بيشيك throughly على حجم ال fields ويتأكد انها مش متبوعة ب trailing zeros ولا bytes ولو مش عارف معنى trailing دور عليها فى كوكل ..... وبكدة يقدر يتأكد انه مفيش اكواد خبيسة .. هههههههههههههههه حطت نفسها جوة ال class file
ال check اللى جاى مش هتصدقوه ..... لانه بيعمل check على كل method ويتأكد انه مفيش كود جوة ال method بي jump على مكان تانى برة ال method
كمان بيتأكد انه ال method descriptor "its return type and number and type
of parameters" موجود جوة ال class ك string وبيتبع context معين
يعنى فى مكان محدد وشكله بالظبظ زى ما هوز متوقعه
كمان بيتأكد انه كل الكلاسات عدا object لها parent وانه الكلاس مش لقيييييييييط .... ههههههههههههههههههههههههههههههههههه
كمان بيتأكد انه اى jump instructions بتتم على valid byte code داخل ال method الواحدة
طيب قلتلكم قبل كدة انه ال byte code ده instructions عبارة عن byte واحد لكن ال byte الواحد ده لل instructions نفسها لكن طبعا قد يكون معاها operands ودى حجمها ممكن يكبر شوية عن ال byte
واكيد عارفين انه ال memory model بتاع الجافا بيقسم الmemory ل stack و heap وانه ال stack خاصة بال local variables ال intermediate calculations والجزء من ال stack اللى فيه intermediate calculations بيسمى operand stack
بالمناسبة قبل ما انسى ال jvm تعتبر stack based يعنى مفيش registers فى ال specifications بتاعتها فبتستخدم ال stack للامور بتاع ال registers
المهم انه ال operands الخاصة بال byte code ممكن تبقى اى حاجة فى ال operand stack او local vaariable مثلا
المهم بقى انه من ضمن ال checks اللى بتحصل هو التأكد من انه ال local variables مش بتتأكسس من غير ما يكون لها قيمة واخداها
وبيتم التأكدمن ال fields انها واخدة واخدة قيم initial مناسبة لل data type بتاعتها وان ال methods دايما واخدة arguments مناسبة فى العدد والنوع يعنى مش بيتنادى عليها بحاجة مخالفة للى فى ال signature بتاعها
غير كدة كمان ال byte code verifier بيتأكد من انه ال byte code هو valid byte code وانه بياخد operand سواء valid local variable in execution stack او valid data in the operand stack
B ) Verification of symbolic references المرحلة دى يا كتاكيت بتحصل بعد ما الكود actually executed والجافا لما بتلاقى symbolic reference لكلاس بتحاول تلوده أثناء ال runtime ولو ال implementation بتاع ال jvm بتعمل بعض ال optimizations وتلود بعض الكلاسات قبل ما تطلب actually كنوع من التسريع وبفرض انها ملقيتش الكلاسات دى مش هت throw ClassNotFOundException إلا لما الكلاسات دى او احدها يتم فعليا استخدامه فى ال application
تيجو نشرح ال dynamic linking شوية ؟
اللى هى عملية الsymbolic reference resolving ? !!!
symbolic reference -> string يعنى اساسا الكلاس اللى بينادى على كلاس تانى بيبقى فيه اسمه ك string وعن طريق قرائة الاسم يتم محاولة عمل لود للكلاس
طبعا محاولة اللوجد دى تتم لو هو مش already loaded
field symbolic reference -> className, fieldName, fieldDescriptor
method symbolic reference -> className, methodName or methodDescriptor
اثناء ال runtime لما يتعمل resolve لل symbolic reference بيتم عمل load للكلاس وعمل verifying عليه ثم يتم تبديل ال symbolic ref ب direct ref such as pointer or offset to the class field, or method
C ) Binary compatilityعارفين لما تيجى تعمل كومبايل لكلاس سوسو اللى بيستخدم كلاس تانى توتو ؟ طبعا توتو هو كمان بيحصله كومبايل فوق البيعة صح ؟
ايوة صح .... عمنا كوكو ... اقصد الكومبايلر اصل النهارده العيد وانا لسة معيد ......
بيشك بيلاقى سوسو بينادى على method جوة توتو فيروح لتوتو ويلاقى ال method جواه فيعمله كومبايل بالمرة .... طيب لو انت غيرت وشيلت ال method دى من توتو وعملتله كوميايل لوحده وجيت ت run سوسو .... هيديك exception صح ؟ !!! ده لانه اى كلاس بيتلود بيتعمله compatibility check يعنى يشوفه الدوال جواه متوافقة مع ال method calls وال return type وال signature وكدة !!!!! وده مفيد لو سيادتك عندك ال application متقسم لباكيجات منفصلة وكل تيم شغال فى package بحيث ممكن يعملولها كومبايل independently بكدة لما تيجى تجمع البازل بتاعتك وتحط الاجزاء مع بعضها لو حاجة نافصة .... مثلا واحد عبيط نسى يحط method مثلا ..... البرنامج هيديك exception أثناء ال runtime علطول وقبل ما يبدأ فى تشغيل البرنامج نفسه
3 safety features built into jaa language itselfاللغة نفسها مقدمة مجموعة من الحمايات المتعددة اللى كانت بتفتقر لها لغات تانية زى السى بلس بلس مثلا
زى انه مفيش pointers وال garbage collection و ال array bound checking وعمل check على ال references علشان لو null وتم استخدامها تديك null pointer exception كمان لو ال memory اتملت ال jvm تديك exception فى السريع بدون ما ده يتسبب فى مشاكل و bugs
من الحاجات اللذيذة برده انه ال jvm طبعا بتقسم ال memory اللى بتاخدها من السيستم ل اجزاء زى ال stack , heap, method area , ..... والطريقة اللى بتعمل ده بيها مش محددة وغير كدة اساسا مفيش behavior ثابت لانها تحط اى ال objects اللى بتعملها load فى اماكمن محددة .... يعنى العناوين او ال addresses بتاعتهم بتحدد فى ال runtime وبكدة ييجى عمو كركر او ال cracker ميلقيش behavior ثابت لاماكن ال objects فى ال memory ......... يا عم ده انا هقولكم على حاجة سر .... ده عم كركر حتى ميقددرش يعرف ال layout بتاع ال memory بتاع ال java حتى لو قرأ ال specifications لانه دى حاجة متروكة لل vendor .... يعنى باختصار هو مش عارف ال stack فين بالظبط وال heap فين بالظبط ولا ال thread الجديد اللى هو فى الاصل stack جديدة اتحط فين بالظبط والميزة دى بنسميها عملية منع ال unstructured memory access ودى حاجة كمان مدعمة على مستوى ال byte code يعنى حتى لو كتبت byte code باستخدام your bare hands مش هتقدر تعمل unstructured memory access
عموما كركر اللى كنا بنتكلم عنه هو كركر الضعيف .....
ولو فيه حد جامد ممكن يلاقى وسيلة .... مع تايد مفيش مستحيييييييل .... ههههههههههههههههههههههههههههههههههههههه
الكلام اللى فات كويس so far ? أتعشم ذلك ..... تعالو نقول عكسه بقة ونبيين انه كل الكلام اللى فات عن الحماية ممكن يبقى كلام فاضى ....
الكلام اللى فات جميل ....بس بينطبق على الجافا code مش على ال native libraries اللى بيتم الاستعانة بيها فى البرامج .... يبقى لو سيادتك استعنت ب native library يبقى انت المسؤل لانه الكود بتاعها ممكن ي corrupt ال memory لو فيها أكواد خبيثة لانها بت run out of the sand box
وعلشان كدة ال security manager بتا ع ال jvm ممكن استخدامه لمنع invoking native libraries وده نفسه اللى بيحصل مع ال applets لانها متقدرش ت invoke native libraries
ال security manager بي run out of the sand box وبيوفر حماية لل outer boundaries بتاع البرنامج
أحد الأشياء الجميلة برده فى الجافا هى انه عند حدوث أى error فيه exception بيت thrown والبرنامج مش بي crash غير كدة كمان لو عندك كذا thread وال exception كان حصل فى thread .... الthreads التانية تفضل شغالة
4 security manager and java APIاعطينا نبذة عنه ... سابقا ومش هنتكلم عنه كتير ..... ممكن بعدين نبقى نتكلم أكتر بأمثلة حية ... ممكن تعرف بس انه بيدعم authentication بحيث لو الكلاس جاى من trusted vendor ممكن البرنامج يستخدمه بسهولة وبيدعم انك تعمل customized security policy
كل سنة وانت طيبين
Author
Topic: inside jvm -part 4- "Security" (Read 379 times)