انجمن‌های فارسی اوبونتو
تازه کار => انجمن تازه‌کاران => نویسنده: Alireza_Zangooei در 04 اسفند 1400، 08:43 ب‌ظ
-
سلام دوستان
دارو اوبونتو رو نصب میکنم
ممنون میشم این گزینه :
"برای امنیت بیشتر : بازنویسی فضای دیسک خالی"
رو کمی توضیح بدید
باید فعال کنم ؟
ممنون🌹
-
قبل از اینکه وارد اوبونتو بشی ازت پسورد میخواد بعد زمانی هم که وارد display manager هم میشید ازتون پسورد یوزر رو میپرسه.
من خودم فعالش نمیکردم . ولی اگه دقیق تر خواستید در موردش بدونید شاید دوستان بهتر راهنماییتون بکنند .
-
قبل از اینکه وارد اوبونتو بشی ازت پسورد میخواد بعد زمانی هم که وارد display manager هم میشید ازتون پسورد یوزر رو میپرسه.
من خودم فعالش نمیکردم . ولی اگه دقیق تر خواستید در موردش بدونید شاید دوستان بهتر راهنماییتون بکنند .
تشکر 🌺
-
نه. ولی پیش از نصب، حتماً safe boot رو از کار بنداز
-
قبل از اینکه وارد اوبونتو بشی ازت پسورد میخواد بعد زمانی هم که وارد display manager هم میشید ازتون پسورد یوزر رو میپرسه.
من خودم فعالش نمیکردم . ولی اگه دقیق تر خواستید در موردش بدونید شاید دوستان بهتر راهنماییتون بکنند .
نه. اینی که گفتید مربوط به رمزنگاری تنها هست. فعال کردن اون گزینه باعث فضای خالی با اطلاعات تصادفی یا شاید ۱ یا ۰ باز نویسی بشه. اینجوری اگه قبلا اطلاعتی اونجا بوده، تقریبا غیر قابل بازیابی میشن.
نه. ولی پیش از نصب، حتماً safe boot رو از کار بنداز
منظورتون secure boot هست؟ اگه آره، با غیرفعال کردنش راه‌هایی برای بدست آوردن کلید رمزنگاری دیسک بوجود میاد.
-
منظورتون secure boot هست؟ اگه آره، با غیرفعال کردنش راه‌هایی برای بدست آوردن کلید رمزنگاری دیسک بوجود میاد.
بله. با فعّال بودنش هم اون راه‌ها همچنان وجود دارن!
-
خب وقتی secure boot غیرفعاله، یه کسی می‌تونه بوتلودری که توی esp هست رو تغییر بده تا کلید‌هایی که فشرده میشن رو ذخیره کنه و اینجوری رمزی که باهاش هارد قفل شده رو بدست بیاره یا اینکه یه کرنل و initramfs مشکل دار رو در قالب یه برنامه uefi در بیاره و جایگزین بوتلودر اصلی کنه. اینجوری به کل فعالیت‌هایی که میشه دسترسی داره یا خیلی کار‌های دیگه. درسته که این نوع حمله در صورتی ممکنه که دسترسی فیزیکی به دستگاه داشت یا یه جوری محتویات esp رو عوض کرد، ولی باز هم یه راه نفوذ هست.
چرا باید secure boot رو غیرفعال کنیم؟ من خودم secure boot رو فعال کردم، ولی از اونجایی که به مایکروسافت اعتماد ندارم، گواهی‌های secure boot رو با گواهی‌های خودم عوض کردم، بوتلودر هم امضای خودم رو داره. در نتیجه هر چیزی که توسط خودم امضا نشده باشه، توسط uefi بوت نمیشه. مگه اینکه خود firmware یه آسیب‌پذیری چیزی داشته باشه، که تا اونجایی که می‌دونم، برای من اینجوری نیست.
بله. با فعّال بودنش هم اون راه‌ها همچنان وجود دارن!
چجوری؟ تنها راهی که به ذهنم میرسه اینه که توی کیبورد یه چیزی کار گذاشت تا کلید‌هایی که فشرده میشن رو ذخیره کنه. اگه لپ‌تاپ باشه، این مورد سخت‌تره.
-
این‌ها همه در صورت رمزنگاری بودن دیسکه که صحبتی ازش نشده. حتا در اون صورت هم افراز boot رمزنگاری نمیشه که خیلی راحت میشه اصلاً کرنل رو عوض کرد. یادمون باشه که همیشه boot access = root access
در این مورد،بهترین چیزی که من دیدم، اینه: https://puri.sm/posts/new-pureboot-feature-scanning-root-for-tampering
-
این‌ها همه در صورت رمزنگاری بودن دیسکه که صحبتی ازش نشده.
از اونجایی که موضوع درباره رمزنگاری هست، از اول فرض کردم دیسک رمزنگاری شده.
حتا در اون صورت هم افراز boot رمزنگاری نمیشه که خیلی راحت میشه اصلاً کرنل رو عوض کرد. یادمون باشه که همیشه boot access = root access
لازم نیست حتما کرنل و initramfs داخل جایی باشند که رمزنگاری نشده. گراب از lucks پشتیبانی می‌کنه پس میشه بوت رو جدا نکرد و گذاشت جز روت باقی بمونه. اینجوری کسی نمی‌تونه کرنل یا initramfs رو دستکاری کنه. نسخه‌های قبلی گراب فقط ا ز lucks1 پشتیبانی می‌کردند ولی الان، پشتیبانی از lucks2 هم به گراب اضافه شده. حدود ۲ ساله.
توی ادامه فرض می‌کنیم که بوت جزیی از روت هست، روت با lucks2 رمزنگاری شده، secure boot روشنه، از گواهی‌ها خودمون برای secure boot استفاده کردیم و گراب هم توسط خودمون امضا شده.
موقع بوت، اول firmware میاد بالا و بعد گراب رو بررسی می‌کنه، اگه امضای اون معتبر باشه، گراب بوت میشه، تنظیمات اولیه خودش توی esp رو می‌خونه و بعد سعی می‌کنه تنظیمات اصلی خودش رو پیدا کنه.
اگه تنظیمات اصلیش جایی توی فایل‌سیستم روت باشه (که اینجا اینجوری فرض کردیم) سعی می‌کنه اون lucks رو باز کنه، بعد که lucks باز شد، تنظیمات اصلی خونده و اعمال میشن و منوی گراب ظاهر میشه اینجا کاربر می‌تونه هر چی رو خواست بوت کنه.
لازمه کلید lucks توی initramfs قرار بگیره تا برای باز کردن lucks، دو بار رمز پرسیده نشه. (یه بار توسط گراب و یه بار توسط سیستم‌عامل)
اگه کلید lucks داخل initramfs قرار گرفته، باید دسترسی خوندن initramfs رو محدود به روت کرد تا پروسه‌ها و کاربر‌های غیرمجاز نتونند کلید رو بدست بیارن. initramfs-tools که توی دبیان به طور پیش‌فرض استفاده میشه، قابلیت این رو داره تا دسترسی initramfs ساخته شده رو تعیین کرد. dracut که توی اکثر توزیع‌ها استفاده میشه هم همینطور. در مورد mkinitcpio که توی آرچ استفاده میشه، چیزی نمی‌دونم. در مورد booster هم همینطور.
با این روش، کرنل و initramfs داخل یه جای رمزنگاری شده قرار دارند و نمیشه تغییرشون داد. اگه هم کسی بخواهد خود گراب رو تغییر بده، امضای اون دیگه معتبر حساب نمیشه و firmware هم اون رو اجرا نمی‌کنه.
تنظیمات گراب توی esp آسیب‌پذیر هست؛ هر چند بعید می‌دونم کسی بتونه با تغییر این فایل، کرنل خودش رو بوت کنه چون وقتی secure boot روشنه، گراب فقط کرنل‌هایی رو بوت می‌کنه که امضای اونها معتبر هست. معمولا توزیع‌ها، کرنل خودشون رو با کلید‌های خودشون امضا می‌کنند، نسخه‌ای از گراب که داخل مخازن توزیع‌ها هست، گواهی متناظر با کلیدی که کرنل باهاش امضا شده رو همراهش داره، پس اگه گراب و کرنلی که قراره بوت بشه مال یه توزیع باشند، لازم نیست چیز خاصی امضا بشه تا گراب کرنل رو بوت کنه.
ولی فکر کنم بشه یه جوری کاری کرد تا یه initramfs آلوده استفاده بشه، مطمئن نیستم.
همینطور ممکنه فایل تنظیم گراب توی esp پیدا نشه، در این حالت گراب یه پوسته نجات (rescue shell) باز می‌کنه، که شاید دسترسی ناخواسته بده.
میشه کاری کرد تا گراب، فایل تنظیمات داخل esp رو هم بررسی کنه، اگه چیزی پیدا نکرد، یه پیغام نمایش بده که چیزی پیدا نشد و بعد 10 ثانیه، کامپیوتر راه‌اندازی مجدد بشه، اینجوری دسترسی به پوسته نجات هم مسدود میشه.
اینجا (https://ruderich.org/simon/notes/secure-boot-with-grub-and-signed-linux-and-initrd) یه سری توضیحاتی درباره این داده.
اینجا (https://gist.github.com/huntrar/e42aee630bee3295b2c671d098c81268) هم یه راهنما برای نصب آرچ به همراه دیسک رمزنگاری شده (بوت جزئی از روت باقی می‌مونه)، وجود داره.
یه راه دیگه این هست که از گراب استفاده نکنیم، به جاش خود کرنل، initramfs وخط فرمان کرنل رو به همراه efi stub جمع‌آوری کنیم و یه فایل اجرایی EFI بسازیم. بعد این رو امضا کنیم و داخل esp بذاریم. در آخر هم firmware رو با چیزی مثل دستور efibootmgr تنظیم کنیم تا این فایل اجرایی EFI رو بوت کنه. ولی اینجوری دیگه نمیشه به همین راحتی، خط فرمان کرنل رو موقع بوت عوض کرد، برای بوت دوگانه با ویندوز یا توزیع‌های دیگه هم زیاد مناسب نیست چون دردسر بیشتری نسبت به گراب داره.
تا جایی که می‌دونم، dracut می‌تونه به طور خودکار چنین فایل‌هایی بسازه و حتی اونها رو امضا کنه، اگه کلید و گواهی درست رو بهش معرفی کنیم. initramfs-tools این قابلیت رو نداره، در مورد mkinitcpio و booster چیزی نمی‌دونم.
ساختن این فایل به طور دستی هم کار سختی نیست. با دستور objcopy ممکنه. معمولا این ابزار داخل بسته binutils هست. امضا کردن فایل‌های EFI با استفاده از دستور sbsign ممکنه، این ابزار معمولا همراه بسته sbsigntool هست.