مفاهیم SELinux

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

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

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

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

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

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

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

سطوح اجرایی

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

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

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

انواع، ویژگی‌ها و قوانین

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

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

یک قانون سیاست به این شکل است: allow source target : class permissions ; که در آن:

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

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

allow untrusted_app app_data_file:file { read write };

این می‌گوید که برنامه‌ها مجاز به خواندن و نوشتن فایل‌هایی با برچسب app_data_file هستند. انواع دیگری برای برنامه‌ها وجود دارد. برای مثال، isolated_app برای سرویس‌های برنامه با isolatedProcess=true در مانیفست آنها استفاده می‌شود. به جای تکرار این قانون برای هر دو نوع، اندروید از یک ویژگی به نام 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 یک زمینه را نادیده بگیرید (به بخش Specificity مراجعه کنید). فیلد type در بخش قبلی توضیح داده شده است. categories بخشی از پشتیبانی Multi-Level Security (MLS) در SELinux هستند. در اندروید ۱۲ و بالاتر، categoryها برای موارد زیر استفاده می‌شوند:

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

ویژگی

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

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