چرا جابه‌جایی گواهی VPN برچسب SELinux آن را می‌شکند

گواهی‌ها می‌توانند در پوشه درست با حالت خواندنی و مالکیت root باشند و سرویس باز هم گزارش دهد که نمی‌تواند فایل را باز کند. در سامانه SELinux این ترکیب به یک سازوکار مشخص اشاره می‌کند، نه به مجوزها. برچسب همراه فایل سفر کرد، چون تغییر نام شیء تازه‌ای نمی‌سازد. inode بافت امنیتی‌ای را که در مسیر قدیم داشت نگه داشت، و سیاست مسیر جدید هرگز فرصت نیافت بافت خودش را تعیین کند.

تغییر نام در واقع با برچسب چه می‌کند

فایل بافت SELinux خود را به‌صورت داده‌های ویژگی متصل به inode حمل می‌کند. تغییر نام درون یک سامانه فایل، ورودی پوشه را عوض می‌کند و نه چیز دیگری، که سریع و اتمی است و همان دلیل ماندگاری بافت پس از جابه‌جایی است. هیچ سیاستی پرسیده نمی‌شود، هیچ پیش‌فرضی اعمال نمی‌شود و هیچ هشداری چاپ نمی‌شود.

رونوشت‌برداری رفتار دیگری دارد. رونوشت، inode تازه‌ای در پوشه مقصد می‌سازد و سیاست بر اساس نوع همان پوشه بافتی تعیین می‌کند، پس گواهی رونوشت‌شده معمولاً برچسب درست می‌گیرد، در حالی که گواهی جابه‌جاشده نادرست می‌ماند. همین یک تفاوت بیشتر سردرگمی این دسته از تیکت‌ها را توضیح می‌دهد.

جابه‌جایی بین سامانه‌های فایل به معناشناسی رونوشت برمی‌گردد، پس همان فرمان می‌تواند روی دو ماشین بسته به اینکه /etc روی حجم مستقل خود باشد متفاوت رفتار کند. پیش از نتیجه‌گیری درباره غیرقابل‌اعتماد بودن ابزار، این را بررسی کنید. یک نگاه به جدول سوارکردن به شما می‌گوید کدام نوع جابه‌جایی را انجام داده‌اید.

برچسب کنونی را در برابر برچسب انتظاری بخوانید

سه فرمان فقط‌خواندنی بدون تغییر هیچ‌چیز به پرسش پاسخ می‌دهند. اولی نشان می‌دهد فایل اکنون چه دارد، دومی گزارش می‌دهد سیاست برای همان مسیر دقیق چه انتظاری دارد، و سومی هر فایلی زیر آن پوشه را فهرست می‌کند که برچسبش تفاوت دارد.

ls -lZ /etc/openvpn/client/office-ca.crt
matchpathcon /etc/openvpn/client/office-ca.crt
restorecon -Rn -v /etc/openvpn/client

اجرای آزمایشی همان چیزی است که باید به آن اعتماد کرد، چون هر فایلی را که بافتش از سیاست فاصله گرفته نام می‌برد و سامانه را دست‌نخورده می‌گذارد. اگر گواهی در آن فهرست ظاهر شود، ناسازگاری میان آنچه مسیر یعنی و آنچه فایل ادعا می‌کند را یافته‌اید. اگر ظاهر نشود، برچسب همان است که سیاست می‌خواهد و وقت شما جای دیگری است.

سپس تفاوت را با یک امتناع واقعی هم‌بسته کنید. ناسازگاری شواهد برچسب نادرست است، نه اثبات اینکه سرویس به‌خاطر آن شکست خورده، و اصلاحی که بدون امتناع متناظر در گزارش اعمال شود حدسی با گام‌های اضافه است.

نگاشت را بازگردانید، نه اینکه استثنا بسازید

برای مکان استاندارد، سیاست از پیش مسیر را نگاشت می‌کند، پس restorecon آن را اعمال می‌کند و کار تمام است. دامنه را به همان پوشه‌ای محدود کنید که تعمیر می‌کنید؛ برچسب‌گذاری دوباره کل سامانه فایل کند و آشفته‌کننده است و خطای اصلی را زیر تغییری بسیار بزرگ دفن می‌کند.

برای پوشه سفارشی ترتیب اهمیت دارد، و برعکس کردنش فرمانی می‌سازد که موفقیت گزارش می‌کند و هیچ چیز را تغییر نمی‌دهد. نگاشت به سیاست تعلق دارد، برچسب‌گذاری دوباره به پایان، و اجرای آزمایشی به پیش از هر دو. رد کردن آن بخش آخر همان راهی است که مسیری هرگز نادرست نبوده هم برچسب‌گذاری دوباره می‌شود.

semanage fcontext -a -t openvpn_etc_t '/etc/openvpn/custom(/.*)?'
restorecon -Rv /etc/openvpn/custom

restorecon نگاشتی را اعمال می‌کند؛ نمی‌تواند یکی بسازد. اگر هیچ قاعده‌ای مسیر را توصیف نکند، چیزی برای بازگرداندن نیست، و به همین دلیل نگاشت پایدار باید پیش از برچسب‌گذاری دوباره وجود داشته باشد. ثبت کنید کدام پیکربندی مالک آن نگاشت است، چون در غیر این صورت جابه‌جایی بعدی، به‌روزرسانی بسته یا برچسب‌گذاری دوباره ایراد را دوباره می‌سازد و نفر بعد از صفر شروع می‌کند.

چرا chcon راه‌حل نیست

chcon بافتی را مستقیماً روی فایل می‌نویسد. بی‌درنگ اثر می‌کند و کم‌دوام‌ترین گزینه موجود است، چون برچسب‌گذاری دوباره سامانه فایل سیاست را از نو اعمال می‌کند و تغییرات دستی را بدون پرسیدن دور می‌ریزد. فایل تعمیرشده به نظر می‌رسد و تعمیر تاریخ انقضایی دارد که هیچ‌کس ننوشته است. چیزی که در عوض می‌خواهید قاعده‌ای است که مسیر را توصیف کند، تا هر فایلی که به آنجا می‌رسد خودکار همان رفتار را بگیرد.

بدتر آنکه درس اشتباه می‌دهد: نگاشت زیرین هنوز غایب است، پس ایراد هفته‌ها بعد بدون محرک آشکار و بدون خاطره‌ای از راه‌حل موقت برمی‌گردد. chcon را فقط به‌عنوان آزمایشی موقت برای تأیید یک فرضیه به کار ببرید، سپس آن را با نگاشتی جایگزین کنید که برچسب‌گذاری دوباره بعدی را دوام می‌آورد، و بررسی کنید که جایگزین واقعاً سر جایش است.

وقتی برچسب درست است و دسترسی باز هم شکست می‌خورد

از پوشه‌های والد شروع کنید. مجوز عبور روی هر جزء مسیر بررسی می‌شود، پس گواهی درست‌برچسب‌خورده درون پوشه‌ای که سرویس نمی‌تواند به آن وارد شود همچنان ناخواناست. هم SELinux و هم مجوز معمولی باید هر گام را اجازه دهند، و درست کردن یکی دیگری را درست نمی‌کند.

سپس هویت فرایند و جعبه‌شنی خود سرویس را بررسی کنید. واحدی با جعبه‌شنی محدودکننده می‌تواند دسترسی به فایلی را که سیاست با کمال میل اجازه می‌داد ببندد، و از خط گزارش دو علت یکسان به نظر می‌رسند. تأیید کنید کدام فرایند واقعاً می‌پرسد، نه کدام را فرض می‌کنید که می‌پرسد.

به یاد داشته باشید که قواعد dontaudit می‌توانند پیام‌های امتناع را سرکوب کنند، پس گزارش حسابرسی خالی شواهد ضعیفی است نه اثبات. اگر سیاست درست به نظر می‌رسد و دسترسی باز هم شکست می‌خورد، پیش از تولید یک ماژول اجازه گسترده تحقیق کنید، و SELinux را برای ناپدید شدن نشانه خاموش نکنید. هر دو میان‌بر سامانه‌ای می‌سازند که به نظر کار می‌کند و موضع امنیتی‌ای که هیچ‌کس نمی‌تواند توصیفش کند. یک تحقیق کوتاه از هر دو بهتر است.