הקדמה

במסגרת סביבת ה-.Net Framework קיים לו מנגנון אבטחה מתקדם ועשיר הקרוי Code Access Security (CAS בקיצור). המנגנון מיועד לאפשר שליטה מדוייקת בהרשאות שמקבל כל קוד שרץ בסביבה. בסדרת המאמרים הקרובה נתמקד ב-CAS ונראה איך הוא פועל ומה ניתן להשיג באמצעותו. לפני מאמר זה רצוי לקרוא את המאמר הקודם העוסק ב-AppDomains.

בחלק הראשון נסקור את ה-CAS מגבוה ונדבר על מדיניות האבטחה (Security Policy) שיוצרים באמצעותו. לצורך כך נשתמש בתוסף הקונפיגורציה של ה-Framework Control Panel ->) Administrative Tools -> Microsoft .Net Framework XX Configuration -> Runtime Security Policy) ובכלי שורת-הפקודה caspol.exe. בחלקים עתידיים נראה איך עושים שימוש במדיניות האבטחה מתוך קוד.





CAS מגובה 10,000 רגל



מטרתו של ה-CAS, כפי שנכתב לעיל, היא למעשה פיקוח ובקרה על גישה למשאבי המערכת. רק קוד שקיבל הרשאות מפורשות יהיה רשאי להשתמש במשאבים כלשהם. המושג 'שימוש במשאב' בהקשר הזה הוא רחב מאוד – בין היתר הוא כולל גישות לרשת, גישות ל-Event Log, קריאה/כתיבה של קבצים וספריות, קריאה/כתיבה ל-Registry, נגישות לבסיסי נתונים ודברים רבים נוספים. לכל תוכנית ניתן להגדיר בצורה מדוייקת לאלו משאבים היא רשאית לגשת ומה היא רשאית לעשות איתם. לדוגמא, לא נרצה שתוכנית .Net שרצה בתור בקר (control) תחת Internet Explorer תוכל לקרוא באופן חופשי כל קובץ על המחשב או מפתחות ב-registry ולשדר אותן באינטרנט.

הדרך בה עובד ה-CAS היא ע'י מתן הרשאות לכל assembly בתוכנית בנפרד ברגע שהתוכנית עולה ולפני שהיא מתחילה לרוץ. הרשאות הן בדיוק אותן 'זכויות שימוש במשאב' שהוזכרו קודם: לדוגמא, assembly מסויים עשוי לקבל הרשאות קריאה בלבד מספריית C:\Temp. אם הוא ינסה לקרוא ממקום אחר – או לכתוב ל-C:\Temp – אז יזרק SecurityException. אם הוא יקבל גם הרשאות כתיבה או את הרשאות קריאה הנוספות אז התוכנית תרוץ כרגיל.

לאחר שה-CLR יודע בדיוק אלו הרשאות יש לכל assembly התוכנית יכולה להתחיל לרוץ. קוד כלשהוא יכול לדרוש שמי שקורא לו יהיה בעל הרשאות כלשהן ולסרב לעבוד (כלומר, לזרוק exception) במידה ודרישות אלה לא מתקיימות. במאמר עתידי נראה בדיוק איך ניתן לכתוב את הדרישות הללו ואלו אפשרויות קיימות.





מדיניות האבטחה ב-CAS והוכחות



הזכרנו קודם את העובדה שכל assembly מקבל הרשאות שמתאימות לו. הדרך שבה ניתן לדעת אלו הרשאות מתאימות ל-assembly כלשהוא היא ע'י בדיקת מדיניות האבטחה שהוגדרה ואיתור התנאים שאותם מקיים ה-assembly. כאשר assembly מקיים תנאי מסויים, אזי ניתן להעניק לו את ההרשאות שקשורות באותו תנאי. לצורך כך, נדרש כל assembly להציג הוכחות (evidence) שישמשו את ה-CLR לבדיקת התנאים. 'הוכחה' כזו היא בעצם הצהרה של assembly לגבי זהותו ומקורו. הוכחות לזהות ה-assembly עשויות לכלול strong name (חתימה דיגיטלית) או hash קריפטוגרפי, והוכחות למקור ה-assembly עשויות לכלול publisher (לשימוש עם טכנולוגית Microsoft Authenticode), את ה-zone (מחשב מקומי, אינטרא-נט, אינטרנט) ו/או את המיקום (בצורת URL או מסלול) ממנו מגיע ה-assembly. ככל שיש יותר הוכחות כאלה וככל שההוכחות חזקות יותר ניתן לסמוך על ה-assembly יותר ובהתאם לתת לו הרשאות רבות יותר – לדוגמא, ניתן בקלות לזייף אתר או מסלול בקלות יחסית בעוד שהרבה יותר קשה לזייף את החתימה ב-strong name.

כעת, לאחר שהבנו את מושג ההוכחה, ניתן להגדיר את מדיניות האבטחה באופן פשוט בתור מיפוי של הוכחה לקבוצת הרשאות (permission set). או במילים פשוטות – אם הוכחת שאתה מקיים את תנאים X ו-Y, תוכל לקבל קבוצת הרשאות שהוגדרה עבור תנאים אלו. אם נפתח את כלי הקונפיגורציה שהוזכר לעיל, נוכל לראות 3 רמות של מדיניות אבטחה: Enterprise (לרמת הארגון), Machine (לרמת המכונה הבודדת על כל משתמשיה) ו-User (לרמת המשתמש הבודד). תחת כל אחד מאלה נוכל לראות אוסף של permission sets. בהקלקה על אחד האיברים באוסף ובחירת ‘View Permissions’ אפשר לראות את ההרשאות השונות, ולצלול לפרטים השונים שלהם.





שיוך הוכחות להרשאות ומושג ה-Code Group



השאלה הבאה שנשאלת היא כמובן איך מתבצע המיפוי בין ההוכחות לקבוצת ההרשאות. לצורך כך קיימים code groups. באופן פשוט, code group מורכב מתנאי חברות (membership condition) ומקבוצת ההרשאות שכבר ראינו. אם ה-assembly מקיים את תנאי החברות ב-code group – כלומר, מציג את ההוכחות הנדרשות בתנאי החברות – אזי הוא מקבל את ההרשאות שמשויכות לאותו code group.

כפי שניתן לראות בכלי הקונפיגורציה (תחת מדיניות ה-machine), מדיניות האבטחה היא בעצם עץ של code groups: במקרה ש-assembly כלשהוא מקיים את תנאי החברות ב-code group שהוא צומת פנימי בעץ, אז בודקים גם את ה-code groups שהם הילדים של אותו עץ. למשל, אם assembly כלשהוא עונה לתנאי החברות של ה-code group בשם ‘all code’, אז בודקים גם את כל הילדים: My_Computer_Zone, LocalIntranet_Zone וכך הלאה, עד Trusted_Zone. אם ה-assembly עונה לתנאי החברות של My_Computer_Zone אז בודקים גם את הילדים שלו: Microsoft_Strong_Name ו-ECMA_Strong_Name. קבוצת ההרשאות הסופית שמתקבלת היא איחוד של כל ההרשאות שנובעות מכל ה-code groups שה-assembly עונה להם. למשל, אם ה-assembly ענה לתנאי החברות של Microsoft_Strong_Name, אז הוא מקבל את איחוד ההרשאות של Microsoft_Strong_Name, My_Computer_Zone (האבא הישיר) ו-All_Code (הסבא).

אם נסתכל ב-code group של Microsoft_Strong_Name (קליק ימני ובחירת ‘properties&#8217 נראה שההוכחה הנדרשת היא strong name (קשה לזיוף) והגמול לסוג כזה של הוכחה הוא קבוצת ההרשאות FullTrust (כלומר, כל ההרשאות). באופן דומה, אם נסתכל על My_Computer_Zone, נראה שההוכחה הנדרשת היא zone של המחשב המקומי (כלומר, התוכנית רצה ממסלול שיושב במחשב המקומי). גם כאן, קבוצת ההרשאות היא FullTrust והתוכנית רשאית לעשות הכל. מנגד, אם נסתכל על ה-code group של LocalIntranet_Zone נראה שתנאי החברות הוא zone של האינטרא-נט המקומי אבל כאן קבוצת ההרשאות היא מצומצמת יותר – רק LocalIntranet. תוכנית כזו לא תוכל למשל לגשת ל-registry.

סדר בדיקת ה-code groups הוא מלמעלה-למטה: כלומר, קודם בודקים האם ה-assembly מגיע מהמחשב המקומי, אח'כ האם הוא מגיע מהרשת המקומית, וכך הלאה.





רמות מדיניות



כפי שניתן לראות בכלי, קיימות שלוש רמות של מדיניות אבטחה, שכבר מנינו: Enterprise, Machine ו-User. באמצעות רמת ה-Enterprise יכול מנהל הרשת לקבוע מדיניות אבטחה כלל-ארגונית שחלה על כל המחשבים בארגון. רמת ה-Machine מיועדת למדיניות שחלה על המכונה המקומית ותקפה לכל המשתמשים בה. לבסוף, ישנה מדיניות ה-User שכל משתמש יכול לקבוע לעצמו. המדיניות הסופית, זו שבה יעשה שימוש ה-CAS, היא חיתוך של כל הרמות. כלומר, אם מנהל הרשת קבע מדיניות ברמת ה-Enterprise שמרשה קריאת קבצים רק ל-assemblies בעלי strong name והמשתמש קבע מדיניות שבה כל ה-assemblies יכולים לקרוא קבצים, הרי שהתוצאה הסופית תהיה החיתוך בין הרמות, קרי, קריאה רק עבור strong-names assemblies.

קיימת רמת מדיניות רביעית שאיננה זמינה בכלי הקונפיגורציה. זוהי רמת מדיניות שחלה על AppDomains בודדים. בעת יצירה של AppDomain חדש ניתן להגדיר את המדיניות שתהיה פעילה בו. יש לשים לב שמדיניות ב-AppDomain ניתנת להגדרה פעם אחת בלבד, בעת יצירתו.





כלים להגדרת מדיניות אבטחה



כפי שראינו, תוסף הקונפיגורציה של ה-Framework מאפשר הגדרה של קבוצות הרשאה ושיוכן להירארכיית code groups. יש לשים לב שהחל מגרסא 2.0, הכלי הגרפי נמצא רק בסביבת הפיתוח של ה-Framework. כאשר אנחנו עובדים על מחשב שעליו מותקנת רק סביבת הריצה, יש להשתמש בכלי המקביל בשורת הפקודה שנקרא caspol.exe.



דוגמאות לשימוש ב-caspol:

הצגת כל ה-code groups ו-permission sets:

caspol –l

הצגת כל ה-code groups ברמת ה-:user

caspol –u –lg

הצגת כל ה-permission sets ברמת ה-machine:

caspol –m –lp

עדכון ה-permission set של ה-code group בשם TestGroup:

caspol –cg TestGroup FullTrust

הצגת כל ה-code groups עבור assembly כלשהוא:

caspol –rsg MyAssembly

הצגת כל ההרשאות עבור assembly כלשהוא:

caspol –rsp MyAssembly

איפוס מדיניות האבטחה לברירת המחדל:

caspol -reset







סיכום חלק ראשון



בחלק זה ראינו כיצד מגדירים מדיניות אבטחה עבור assemblies שונים בסביבת ה-.Net. הגדרת מדיניות האבטחה על רמותיה השונות היא הבסיס לשימוש נכון ב-Code Access Security. בחלקים הבאים נראה כיצד כותבים קוד בעל דרישות אבטחה.

להלן דוגמת קוד לשימוש ב-CAS מתוך AppDomains. בפעם הראשונה אנחנו מעבירים evidence שגורם ל-CLR לחשוב שכל assembly מגיע מהרשת המקומית. היות ול-assemblies כאלה אין הרשאות לקרוא קבצים מקומיים, אנחנו מקבלים SecurityException עבור FileIOPermission. בפעם השניה, ה-CLR חושב שכל ה-assemblies מגיעים מהמחשב המקומי, ולכן יש הרשאות מלאות ואנחנו מצליחים לקרוא את הקובץ.

קוד:

using System;
using System.Collections.Generic;
using System.Text;
using System.IO;
using System.Security.Policy;
using System.Security;
using System.Reflection;

namespace AppDomainCAS
{
	class Program
	{
		private static void tryRunningInAppDomain(
			object[] hostEvidence,
			object[] assemblyEvidence
			)
		{
			AppDomain newAppDomain = null;

			try
			{

				// Create a new AppDomain with specific security settings
				newAppDomain = AppDomain.CreateDomain(
				   "appdomain with less security",
				   new Evidence(
					hostEvidence,	   // This is evidence from the CLR Host
					assemblyEvidence	// This is evidence for the assembly
				   )
				);

				// Execute the current assembly in the new AppDomain
				newAppDomain.ExecuteAssemblyByName(				   
					Assembly.GetExecutingAssembly().FullName);
			}
			catch (SecurityException ex)
			{
				Console.WriteLine("Security exception:  {0}\n\n",
					ex.Message);
			}
			finally
			{
				if (newAppDomain != null)
					AppDomain.Unload(newAppDomain);
			}


		}


		static void Main(string[] args)
		{

			if (!AppDomain.CurrentDomain.IsDefaultAppDomain())
			{
				// In a different AppDomain, try reading the number
				// of lines in a file

				int lineCount = 0;
				using (StreamReader reader = File.OpenText(
					@"C:\Windows\System32\drivers\etc\hosts"))
				{
					while (!(reader.ReadLine().Length == 0))
						lineCount++;
				}
				Console.WriteLine("File has {0} lines\n\n", lineCount);
				
			}
			else
			{
				// In the Default AppDomain, run this assembly
				// using different security settings

				// This AppDomain considers all assemblies to come from
				// the Intranet Zone (no permissions to read files)
				tryRunningInAppDomain(
					new object[] { new Zone(SecurityZone.Intranet) },
					null
				);


				// This AppDomain considers all assemblies to come from
				// the LocalComputer Zone (full permissions to do anything)
				tryRunningInAppDomain(
					new object[] { new Zone(SecurityZone.MyComputer) },
					null
				);

			}

		}
	}
}

לא לגמרי הבנתי מה זה ההוכחות. זה איזה אישור שמאפשר לך לעשות הכל? ולמה קשה לזיף אותו?
אשמח להסבר עמוק יותק בקשר לזה.

אוקי, תחשוב שאתה ניגש לדואר, לאסוף חבילה או מכתב שהגיע אליך בדואר רשום. אתה מגיע עם הפתק שהשאירו לך בתיבה, ובשביל דואר רשום בדרך כלל תצטרך גם תעודת זהות.
זה בעצם אותו דבר כמו ההוכחות שדיברתי עליהן. כשאתה אוסף חבילה, מספיק שתזדהה בתור מקבל החבילה ע'י זה שאתה מראה לפקיד בדואר את הפתק. למה? כי מי ששלח לך את החבילה לא חשב שהיא מספיק חשובה כדי לדרוש שתזדהה בצורה יותר יסודית.
אם זה כן מספיק חשוב, אז שולחים בדואר רשום. ואז, אתה צריך להראות גם תעודת זהות. הנחת היסוד פה היא שתעודת הזהות הרשמית של מדינת ישראל היא משהו שיותר קשה לזייף, לכן אתה צריך אותה בשביל לקבל את הדואר הרשום שנחשב לסוג דואר יותר חשוב מסתם חבילה רגילה. כנראה שאם היית מגיע עם הפתק של הדואר הרשום והכרטיס מנוי לבריכה או הכרטיס של בלוקבאסטר לא היו מסכימים לתת לך את הדואר. וזאת כי (כנראה) יותר קל לזייף את הכרטיסים האלה והם לא מספיקים בשביל לזהות אותך מעבר לכל ספק.
אותו דבר זה ההוכחות ב-Net. אתה assembly כלשהוא ואתה רוצה שיתנו לך Full Trust לעשות הכל על המחשב של המשתמש. 'רגע אחד', אומר לך ה-CLR. 'איך אני יודע שמגיע לך Full Trust?' ופה בעצם אתה צריך להוכיח לו בצורה חד-חד ערכית שמגיע לך. אתה יכול להגיד 'הגעתי מ-microsoft.com' שזה כמו הכרטיס של הבריכה - כולם יכולים להגיד את זה ואין דרך קלה לברר אם זה אמת או לא. אתה יכול גם להגיד 'הנה ה-strong name שלי, שהמפתח הציבורי שלו זה המפתח הציבורי של מיקרוסופט', שזה כמו תעודת הזהות הרשמית - בשביל לזייף את זה צריך לעבוד יותר קשה. (למען האמת, צריך לעבוד הרבה יותר קשה - לזייף strong name זה בעצם לפצח הצפנת RSA).
ולכן - כדי לבנות מדיניות אבטחה טובה, אתה צריך לוודא שההוכחות (אמצעי הזיהוי) שה-assemblies שלך מציגים ל-CLR הם מספיק חזקות כדי שאף אחד אחר לא יוכל לתפוס טרמפ על ההרשאות שאתה נותן, להתחזות ל-assemblies האלה ובעצם להריץ קוד זדוני.
אני מקווה שזה הסביר יותר טוב. כמובן, אם משהו עדיין לא ברור, אתה מוזמן לשאול.

תודה, ההסבר ברור, אבל עדין יש לי שאלה. כאשר ה-CLR קורא את המפתח, אז בדיוק כמו שהוא מפענח אותו, אפשר להישתמש באותו "מנוע" לא? הרי הוא חיב לפענח אותו כדי לדעת אם הוא מורשה...

רמי, עוד שאלה מצויינת!! אני מבסוט שאתה מזהה את הפינות האלה.
התשובה במקרה הזה היא שהשימוש ב-RSA פה הוא לצורך חתימה דיגיטלית ולא להצפנה. התהליך שקורה הוא כזה:
1. אתה מחשב את ה-Hash Code של ה-Assembly באמצעות פונקציית SHA-1
2. את ה-hash הזה אתה חותם באמצעות המפתח הפרטי שלך, והחתימה היא חלק מה-strong name שנמצא ב-metadata של ה-assembly
3. כאשר ה-CLR טוען את ה-assembly הוא מחשב מחדש את ה-hash code ומשתמש במפתח הציבורי כדי לפענח את החתימה. אם שני ה-hashים זהים, אז יש אישור. אם לא - ה-strong name לא תקף. הביטחון פה נובע מהעובדה שמאוד, מאוד קשה לחשב את המפתח פרטי אם כל מה שיש לך הוא רק מפתח ציבורי, ולכן אם ערכי ה-hash code זהים אז כנראה שה-assembly באמת הגיע מאיפה שהוא אומר שהוא הגיע.
כמובן שהכל נובע מכך שאי אפשר להתלבש על הקוד בתוך ה-CLR שעושה את הפענוח (כי למה לטרוח לנסות לחשב מפתחות אם אתה פשוט יכול לשבור את המנעול?) התשובה פה היא כזו: מכון התקנים האמריקאי הוציא תקן בשם FIPS (קיצור של Federal Information Processing Standard) שמציב דרישות לאבטחת תוכנה של אלגוריתמים קריפטוגרפים. כדי לספק תוכנה עם רכיבי הצפנה לממשלת ארה'ב אתה צריך להוכיח שהמימוש שלך של אלגוריתמי הצפנה כאלה ואחרים הוא תואם FIPS, ובכך בעצם מתייחס לשאלה שלך. ה-CryptoAPI של Windows תואם FIPS, ולכן גם ה-CLR תואם FIPS ואמור להתמודד עם הבעייה שאתה מעלה. וסתם לידיעה - קיימת הגדרת Registry שגורמת ל-CLR להסכים לעבוד רק עם אלגוריתמים תואמי FIPS, כך שאם תממש RSA משלך ותנסה להשתמש בו תקבל Exception. מקווה שזה ענה לך.

אז אתה אומר שההצפנה היא חד כיוונית...
אוקי!. תודה שוב!. אני אקרא קצת מידע באינטרנט על FIPS ...