הקדמה לחלק שני



בחלק הקודם ראינו כיצד סביבת ה-.Net מחליטה אלו הרשאות לתת לכל assembly. ראינו גם כיצד ניתן לקבוע מה יהיו הרשאות אלו. בחלק זה נראה כיצד ניתן מתוך קוד להתייחס להרשאות שניתנו. לצורך כך, מצורף למאמר קובץ zip המכיל solution ובו שני פרוייקטים – פרוייקט conosole application אחד ופרוייקט library אחד. פרוייקט ה-console הוא תוכנית קטנה המגדירה AppDomain חדש ומריצה בו מספר מתודות, שכל אחת מהן מבצעת פעולת CAS כלשהיא. ה-AppDomain מגדיר מדיניות אבטחה (security policy) משלו (כלומר, לא קשורה למדיניות האבטחה המוגדרת בכלי הקונפיגורציה), בה כל assembly מקבל הרשאות ריצה מינימליות. כמו כן, assemblies שמציגים הוכחות כאילו הגיעו מהאתר www.fresh.co.il מקבלים הרשאות מלאות (FullTrust) – וזהו ה-assembly שמוגדר בפרוייקט ה-library. בצורה כזו, אנו יכולים לראות את ההתנהגות של ה-CLR כאשר הוא עובד עם assemblies בעלי הרשאות שונות.







מעברי מחסנית



על מנת להבין כיצד להשתמש ב-CAS מתוך קוד עלינו להבין תחילה את המושג מעבר מחסנית (stack walk). המושג 'מחסנית' בהקשר זה מתייחס למחסנית זמן-הריצה, כלומר למבנה הנתונים בזכרון בו נשמרים הפרטים על מהלך התוכנית ואלו מתודות נקראו בה (בפרט, זוהי אותה מחסנית שממנה מוציאים את ה-stack trace כאשר נזרק exception). בכל פעם שמתודה כלשהיא נקראת, נוצר במחסנית רישום של שם המתודה, הפרמטרים שלה והמשתנים המקומיים בה. רישום זה מסולק מהמחסנית כאשר המתודה מסתיימת. מכאן נובע שתוכן המחסנית מתעדכן תוך כדי ריצה, בהתאם למתודה שרצה ברגע נתון. מעבר המחסנית, כפי שרומז השם, הוא בעצם מעבר על כל הרישומים במחסנית – ממתודת ה-main ועד למתודה הנוכחית - ובדיקה האם יש להם הרשאות שימוש במשאב כלשהוא. בצורה כזו, ניתן לאכוף רמת אבטחה גבוהה.

למעשה, כל פעולות בדיקות ההרשאות שנראה בהמשך הן הוראות לתהליך מעבר המחסנית כיצד להתנהג במצבים מסויימים.





פעולות על הרשאות



נסתכל כעת על הפעולות השונות על הרשאות שניתן לבצע בקוד. בדוגמאות למאמר זה נעשה שימוש ב-attributes (כלומר, סימון הפעולה בסוגריים מרובעים מעל המתודה ב-C#). לכל פעולה כזו יש גם גרסא המאפשרת קריאה למתודה על אובייקט רגיל. בפרט, כאשר רוצים לבצע פעולות על הרשאות העושות שימוש בערכים המוכלים במשתנים, יש להשתמש בגרסאות האובייקטים ולא ב-attributes.





דרישת הרשאות



הפעולה הראשונה שנראה היא דרישת הרשאות (permission demand). בפעולה זו, הקוד שמציב את הדרישה (נקרא לו d) מצפה שלכל הקוד שקדם ל-d במחסנית יהיה את ההרשאה הרצוייה. כלומר, אם main קרא ל-a שקרא ל-d, ו-d דורש הרשאות כתיבה לקובץ, הרי שגם ל-main וגם ל-a צריכות להיות הרשאות כאלה. אם לאחד מהם אין את ההרשאות, ה-CLR יסרב להריץ את d ויזרוק במקום SecurityException. מצב כזה יכול לקרות לדוגמא אם main ו/או a נמצאות ב-assembly שלא קיבל הרשאות (במקרה הנ'ל, הרשאות כתיבה לקובץ כלשהוא). במונחי מעבר מחסנית, זהו מעבר מלא: כל רישום במחסנית חייב את ההרשאה הרלוונטית.

בפרוייקט הדוגמא שלנו השימוש ב-demand מוצג ב-example 1. במקרה המוצג, יש לנו מתודה (שנקראת calculateFileName) אשר תפקידה הוא לחשב שם של קובץ. המתודה דורשת הרשאות כתיבה (FileIOPermission) לספרייה C:\MyAppDirectory והסיבה לכך היא פשוטה – אם אין לקוד שקורא לה הרשאה לכתוב לספרייה, אז אין טעם לחשב שם של קובץ לכתיבה בספריה. בפרט, אם החישוב הוא ארוך ומורכב אז אנחנו מונעים מהמחשב לעשות עבודה שאין בה צורך. כמו כן, נסתכל על מקרה בו המתודה אינה דורשת הרשאות כאלה: במידה והקוד שקורא לה אינו רשאי לכתוב לקובץ אז אנחנו מסתכנים בכך שאנחנו חושפים בפני תוקף פוטנציאלי חלק ממבנה הספריות של התוכנה שלנו. בדוגמא זו, נקבל SecurityException.

בהקשר של דרישות אבטחה חשוב להבין שאובייקטים והמתודות המוכנים של .Net כבר יש דרישות CAS. אובייקטים שכותבים לקובץ ידרשו FileIOPermission, אובייקטים שפועלים על משתני סביבה ידרשו EnvironmentPermission וכך הלאה. אם קוד שלנו קורא אך ורק לאובייקטים ששייכים לספריות המוכנות של ה-Framework הרי שלרוב אין צורך בדרישות אבטחה.





הצהרת הרשאות



הפעולה הבאה שנראה היא הצהרה (Assert). קוד שמבצע פעולה כזו (נקרא לו a) בעצם מצהירשהוא לוקח על עצמו את האחריות של עבודה מאובטחת כאשר נדרשת הרשאה מסויימת. נסתכל על מצב שבו ל-a יש הרשאה לכתוב לקובץ, ולקוד אחר כלשהוא (נקרא לו b) אין הרשאה כזו. אם b ינסה לבצע כתיבה, ה-CLR יסרב ונקבל SecurityException. אך אם b יקרא ל-a הפעולה תצליח היות ו-a לקח על עצמו את האחריות. כמובן שכדי שדבר כזה יצליח ה-assembly שבו נמצא a חייב היה לקבל את ההרשאות האלה מה-CLR מלכתחילה. במונחי מעבר מחסנית, התהליך נעצר ב-a ואינו ממשיך הלאה ל-b.

בפרוייקט הדוגמא שלנו מוצג השימוש ב-assert ב-example 2. במקרה הראשון, יש קריאה למתודה calculateUsingProcessorCount שעושה שימוש במספר המעבדים במחשב לצורך חישוב ארוך ומורכב. מידע זה נשמר במשתנה הסביבה NUMBER_OF_PROCESSORS. המתודה קוראת למתודה בעל שם זהה בספריה Library שקיבלה הרשאות מלאות. על המתודה בספרייה Library לוודא בעצמה ששום מידע רגיש לא נחשף החוצה כאשר היא רצה ובתמורה היא יכולה להצהיר שכל מי שקורא לה יחשב כאילו הוא בעל הרשאת קריאה של משתנה הסביבה הנ"ל (EnvironmentPermission).

במקרה השני, אנחנו מנסים לקרוא את משתנה הסביבה ישירות. היות ואין לנו הרשאות, נקבל SecurityException.





שלילת הרשאות



הפעולה הבאה היא שלילה (Deny). קוד שמבצע פעולה כזו (נקרא לו d) בעצם מסירהרשאה קיימת שכבר קיבל. לדוגמא, קוד e כלשהוא הוא בעל הרשאות כתיבה לקובץ וקורא ל-d, ששוללת את ההרשאה הזו. במצב כזה, d לא יוכל לכתוב לקובץ למרות של-e יש את ההרשאות המתאימות, ויתכן אף של-assembly של d יש גם את הרשאות אלו (ובאופן רגיל, מתודות מתוך assembly זה רשאיות לכתוב). במונחי מעבר מחסנית, deny גורם לתהליך להכשל במתודה הספציפית ובכך להכשיל את המעבר כולו.

בפרוייקט הדוגמא שלנו נעשה שימוש ב-deny ב-example 3. בדוגמא זו אנו מדמים מצב שבו אנו מטפלים במידע רגיש (ססמא של משתמש, מספר כרטיס אשראי, וכו'). אנחנו רוצים למנוע כל אפשרות שהמידע הזה יכתב לדיסק באיזושהיא צורה ע'י קוד כלשהוא שנקרא מתוך המתודה handleSensitiveInformation ולכן אנחנו שוללים ממנה את הזכות לכל סוג של פעילות עם קבצים. וכך, למרות שנתנו ל-assembly של handleSensitiveInformation הרשאות כתיבה ל-C:\Temp הקריאה ל-File.AppendAllText נכשלת.





הרשאה חלקית



הפעולה האחרונה שנדון בה היא הרשאה חלקית (PermitOnly). קוד שמבצע פעולה כזו (נקרא לו p) מצהיר שהוא מאפשר רק הרשאות מסוימות (למרות שיתכן שה-assembly בו הוא נמצא מאפשר הרשאות נוספות). למעשה, זוהי פעולה הפוכה ל-deny: בעוד ש-deny מגדיר מה יכשיל מעבר מחסנית, ה-permitOnly מגדיר מה הדבר היחיד שיעביר מעבר מחסנית.

בפרוייקט הדוגמא פעולה זו מוצגת ב-example 4. אנחנו רוצים לכתוב מידע רגיש כלשהוא לקובץ, אבל רוצים שליטה מלאה לאיזה קובץ. בצורה כזו, ניתן להגן על הקובץ הפיזי באמצעים אחרים של מערכת ההפעלה. וכך, למרות של-assembly של outputSensitiveInformation יש הרשאות כתיבה ל-C:\Temp, הרי שבמקרה שלנו מותרת כתיבה רק לקובץ בשם KnownFile.txt. היות ואנו מנסים לומר למתודה לכתוב ל-HackedPassword.txt, נקבל SecurityException.



פעולות נוספות

קיימות פעולות CAS נוספות בשם LinkDemand, InheritanceDemand ו-IdentityDemand. לא נדון בהן במסגרת מאמר זה.





סיכום חלק שני



בחלק זה של המאמר ראינו כיצד ניתן להשתמש בפעולות CAS כדי לבצע בדיקות אבטחה על קוד. היתרון הגדול של בדיקות כאלה הוא שאנו עושים שימוש בתשתית מוכנה ובדוקה של מיקרוסופט ואין לנו צורך לממש דברים כאלו בעצמנו. בחלק הבא של המאמר נראה כיצד קובעים אלו הרשאות מקבל assembly בודד מבין כל אלו המגיעות לו, ונתן טיפים לשימוש יעיל ב-CAS בעת כתיבת תוכניות.





https://2008-uploaded.fresh.co.il/2...19/51643852.zip https://2008-uploaded.fresh.co.il/2...19/51643852.zip