مفاهیم SELinux

این صفحه را مرور کنید تا با مفاهیم SELinux آشنا شوید.

کنترل دسترسی اجباری

لینوکس ارتقا یافته امنیتی (SELinux)، یک سیستم کنترل دسترسی اجباری (MAC) برای سیستم عامل لینوکس است. به عنوان یک سیستم MAC، با سیستم کنترل دسترسی اختیاری آشنا (DAC) لینوکس متفاوت است. در یک سیستم DAC، مفهومی از مالکیت وجود دارد که به موجب آن مالک یک منبع خاص، مجوزهای دسترسی مرتبط با آن را کنترل می‌کند. این معمولاً درشت دانه است و در معرض تشدید امتیازات ناخواسته است. با این حال، یک سیستم MAC با یک مقام مرکزی برای تصمیم گیری در مورد تمام تلاش های دسترسی مشورت می کند.

SELinux به عنوان بخشی از چارچوب ماژول امنیتی لینوکس (LSM) پیاده سازی شده است که اشیاء هسته های مختلف و اقدامات حساس انجام شده بر روی آنها را شناسایی می کند. در نقطه‌ای که هر یک از این اقدامات انجام می‌شود، یک تابع قلاب LSM فراخوانی می‌شود تا مشخص شود که آیا این عمل باید بر اساس اطلاعات ذخیره شده در یک شی امنیتی غیرشفاف مجاز باشد یا خیر. SELinux یک پیاده سازی برای این قلاب ها و مدیریت این اشیاء امنیتی ارائه می دهد که با خط مشی خود ترکیب می شود تا تصمیمات دسترسی را تعیین کند.

در کنار سایر اقدامات امنیتی اندروید، سیاست کنترل دسترسی اندروید تا حد زیادی آسیب احتمالی ماشین‌ها و حساب‌های در معرض خطر را محدود می‌کند. استفاده از ابزارهایی مانند کنترل‌های دسترسی اختیاری و اجباری Android به شما ساختاری می‌دهد تا مطمئن شوید نرم‌افزار شما فقط در سطح حداقل امتیاز اجرا می‌شود. این امر اثرات حملات را کاهش می دهد و احتمال بازنویسی یا حتی انتقال داده ها توسط فرآیندهای اشتباه را کاهش می دهد.

در اندروید 4.3 و بالاتر، SELinux یک چتر کنترل دسترسی اجباری (MAC) را بر روی محیط‌های کنترل دسترسی اختیاری سنتی (DAC) ارائه می‌کند. برای مثال، نرم‌افزار معمولاً باید به‌عنوان حساب کاربر اصلی برای نوشتن در دستگاه‌های بلوک خام اجرا شود. در یک محیط لینوکس مبتنی بر DAC سنتی، اگر کاربر ریشه در معرض خطر قرار گیرد، کاربر می‌تواند در هر دستگاه بلوک خام بنویسد. با این حال، SELinux می‌تواند برای برچسب‌گذاری این دستگاه‌ها استفاده شود، بنابراین فرآیند اختصاص داده شده به امتیاز ریشه می‌تواند فقط برای مواردی که در خط‌مشی مرتبط مشخص شده است بنویسد. به این ترتیب، فرآیند نمی تواند داده ها و تنظیمات سیستم را خارج از دستگاه بلوک خام خاص بازنویسی کند.

برای مثال‌های بیشتر از تهدیدها و راه‌های رسیدگی به آن‌ها با SELinux ، موارد استفاده را ببینید.

سطوح اجرایی

SELinux را می توان در حالت های مختلف پیاده سازی کرد:

• مجاز - خط مشی امنیتی SELinux اجرا نمی شود، فقط ثبت شده است.
• اجرا - سیاست امنیتی اجرا و ثبت شده است. خرابی ها به صورت خطای EPERM ظاهر می شوند.

این انتخاب باینری است و تعیین می کند که آیا خط مشی شما اقدامی انجام می دهد یا صرفاً به شما اجازه می دهد تا شکست های احتمالی را جمع آوری کنید. Permissive به ویژه در هنگام اجرا مفید است.

انواع، صفات و قواعد

Android برای خط مشی خود به مؤلفه Type Enforcement (TE) SELinux متکی است. به این معنی که همه اشیا (مانند فایل، پردازش یا سوکت) دارای یک نوع مرتبط با آنها هستند. به عنوان مثال، به طور پیش فرض، یک برنامه دارای نوع untrusted_app است. برای یک فرآیند، نوع آن به عنوان دامنه آن نیز شناخته می شود. امکان حاشیه نویسی یک نوع با یک یا چند ویژگی وجود دارد. ویژگی ها برای ارجاع همزمان به چندین نوع مفید هستند.

اشیاء به کلاس‌ها نگاشت می‌شوند (به عنوان مثال، یک فایل، یک فهرست، یک پیوند نمادین، یک سوکت) و انواع مختلف دسترسی برای هر کلاس با مجوزها نشان داده می‌شوند. به عنوان مثال، مجوز open برای file کلاس وجود دارد. در حالی که انواع و ویژگی‌ها به‌عنوان بخشی از خط‌مشی Android SELinux به‌طور منظم به‌روزرسانی می‌شوند، مجوزها و کلاس‌ها به‌طور ایستا تعریف می‌شوند و به ندرت به عنوان بخشی از نسخه جدید لینوکس به‌روزرسانی می‌شوند.

یک قانون خط مشی به شکل زیر ارائه می شود: allow source target : class permissions ; کجا:

• منبع - نوع (یا ویژگی) موضوع قاعده. چه کسی درخواست دسترسی دارد؟
• هدف - نوع (یا ویژگی) شی. دسترسی درخواستی به چه چیزی است؟
• کلاس - نوع شی (به عنوان مثال، فایل، سوکت) مورد دسترسی.
• مجوزها - عملیات (یا مجموعه ای از عملیات) (به عنوان مثال، خواندن، نوشتن) در حال انجام است.

یک مثال از یک قانون این است:

allow untrusted_app app_data_file:file { read write };

این می گوید که برنامه ها مجاز به خواندن و نوشتن فایل هایی با برچسب app_data_file هستند. انواع دیگری برای برنامه ها وجود دارد. برای مثال، isolated_app برای سرویس‌های برنامه با isolatedProcess=true در مانیفست آنها استفاده می‌شود. به جای تکرار قانون برای هر دو نوع، Android از یک ویژگی به نام appdomain برای همه انواعی که برنامه ها را پوشش می دهد استفاده می کند:

# Associate the attribute appdomain with the type untrusted_app.
typeattribute untrusted_app appdomain;

# Associate the attribute appdomain with the type isolated_app.
typeattribute isolated_app appdomain;

allow appdomain app_data_file:file { read write };

هنگامی که قاعده ای نوشته می شود که نام ویژگی را مشخص می کند، آن نام به طور خودکار به لیست دامنه ها یا انواع مرتبط با ویژگی گسترش می یابد. برخی از ویژگی های قابل توجه عبارتند از:

• domain - ویژگی مرتبط با انواع فرآیندها،
• file_type - ویژگی مرتبط با همه انواع فایل.

ماکروها

به طور خاص برای دسترسی به فایل، انواع مختلفی از مجوزها وجود دارد که باید در نظر گرفته شوند. به عنوان مثال، مجوز read برای باز کردن فایل یا فراخوانی stat روی آن کافی نیست. برای ساده‌تر کردن تعریف قانون، اندروید مجموعه‌ای از ماکروها را برای رسیدگی به رایج‌ترین موارد ارائه می‌کند. به عنوان مثال، برای گنجاندن مجوزهای از دست رفته مانند open ، قانون بالا می تواند به صورت زیر بازنویسی شود:

allow appdomain app_data_file:file rw_file_perms;

برای مثال بیشتر از ماکروهای مفید، فایل global_macros و te_macros را ببینید. ماکروها باید تا حد امکان استفاده شوند تا به کاهش احتمال خرابی به دلیل رد مجوزهای مرتبط کمک کنند.

هنگامی که یک نوع تعریف می شود، باید با فایل یا فرآیندی که نشان می دهد مرتبط شود. برای جزئیات بیشتر در مورد نحوه انجام این ارتباط، پیاده سازی SELinux را ببینید. برای اطلاعات بیشتر در مورد قوانین، به نوت بوک SELinux مراجعه کنید.

زمینه و دسته بندی های امنیتی

هنگام اشکال‌زدایی خط‌مشی‌های SELinux یا برچسب‌گذاری فایل‌ها (با استفاده از file_contexts یا هنگام استفاده از ls -Z )، ممکن است با یک زمینه امنیتی مواجه شوید (که به عنوان برچسب نیز شناخته می‌شود). به عنوان مثال: u:r:untrusted_app:s0:c15,c256,c513,c768 . یک زمینه امنیتی دارای قالب است: user:role:type:sensitivity[:categories] . معمولاً می‌توانید user ، role و زمینه‌های sensitivity یک زمینه را نادیده بگیرید (به ویژگی مراجعه کنید). فیلد type در قسمت قبل توضیح داده شده است. categories بخشی از پشتیبانی چند سطحی امنیت (MLS) در SELinux هستند. در اندروید 12 و بالاتر، دسته‌ها برای موارد زیر استفاده می‌شوند:

• جداسازی داده های برنامه از دسترسی توسط برنامه دیگر،
• داده های برنامه را از یک کاربر فیزیکی به کاربر دیگر جدا کنید.

خاص بودن

اندروید از تمام ویژگی های ارائه شده توسط SELinux استفاده نمی کند. هنگام مطالعه اسناد خارجی، این نکات را در نظر داشته باشید:

• اکثر سیاست ها در AOSP با استفاده از زبان خط مشی کرنل تعریف می شوند. برای استفاده از زبان میانی مشترک (CIL) استثناهایی وجود دارد.
• کاربران SELinux استفاده نمی شوند. تنها کاربر تعریف شده u است. در صورت لزوم، کاربران فیزیکی با استفاده از فیلد دسته‌بندی یک زمینه امنیتی نشان داده می‌شوند.
• نقش‌های SELinux و کنترل دسترسی مبتنی بر نقش (RBAC) استفاده نمی‌شوند. دو نقش پیش فرض تعریف و استفاده می شود: r برای موضوعات و object_r برای اشیا.
• از حساسیت های SELinux استفاده نمی شود. حساسیت پیش فرض s0 همیشه تنظیم شده است.
• Booleans SELinux استفاده نمی شود. وقتی خط‌مشی برای دستگاهی ساخته می‌شود، به وضعیت دستگاه بستگی ندارد. این امر ممیزی و رفع اشکال خط مشی ها را ساده می کند.