با سلام خدمت دوستان عزیزم

یکی از آرگومان های امنیتی که باید در هر سیستم عاملی رعایت بشه ، کنترل و مدیریت استفاده از منابع چه در سطح User و چه در سطح Process ، هست . این تمهید توی اکثر سیستم عامل ها اندیشیده شده ولی خوب توی بی اس دی ، یه چورایی قرص و محکم تره ( البته این نظر منه :دی )

FreeBsd روش های مختلفی رو برای پیاده سازی محدودیت های اصطلاحا System Resource در خودش جای داده که تا حدودی سعی میکنم به طور کامل توی این پست عنوان کنم . البته یه سری از موارد مثل disk qoutas از حوصله ی این بحث خارجه که باید در وقتی مجزا در موردش حرف زده بشه . با استفاده از Resource limits میشه محدودیت هایی رو برای استفاده از CPU و Memory ایجاد کرد ، که نتیجه این کار Stable شدن سیستم هست . روش سنتی که قبلا توی ورژن های پائین تر استفاده می کردن ، استفاده از کلاس هایی به خصوص توی فایل کانفیگ لاگین که توی پست قبل در موردش صحبت کردم هست . البته این روش توی ورژن های جدید هم به کار میاد و جواب میده . توی روش فوق نیاز به یه سری تغییرات چند مرحله ای توی فایل و Rebuild کردن فایل دیتابیس منابع و اعمال تغییرات توی /etc/master.passwd و دوباره سازی دیتابیس پسورد ها ، هست .

حتما میپرسین عیب و ایراد روش بالا چیه ؟ خوب معلومه یکی اینکه توی اتلاف وقت نقش به سزایی داره :دی , از همه مهمتر این که واسه هر کدوم از یوزر ها باید پروسه رو تکرار کرد .

توی این پست سعی میکنم هر دو روش رو بهتون یاد بدم ، دیگه تصمیم با خودتون :دی

Login Classes Configuration

خوب تو این روش (سنتی) login class  و resource limits توی قالب کلاس لاگین در فایل /etc/login.conf قرار میگیره .

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

طبق عرایضی که توی پست قبل داشتم بعد از هر تغییر لازمه که دیتابیس آپدیت بشه .

n3td3vil@oslearn-lab # cap_mkdb /etc/login.conf

Resource limit از قابلیت ورود به طور پیش فرض از دو روش استفاده میکنه ،

روش اول : برای هر محدودیت دو روش Hard Limit و Soft limit وجود داره .

soft limit توسط خود کاربر یا یه application ایجاد میشه که بالاتر از Hard Limit هم نیست ، جالبه بدونین hard limit میتونه توسط یوزر عادی کم بشه و اصطلاحا مسطح بشه اما برای افزایش محدودیت حتما باید دسترسی سوپر یوزر داشته باشیم .

روش دوم : پیاده سازی کمترین یا بیشترین محدودیت به صورت process به process برای یک یوزر خاص .

خوب حالا معمول ترین Resource Limit هایی که توی فایل login.conf میشه استفاده کرد به شرح زیر هست :

Resource Limit	Description
coredumpsize	The limit on the size of a core file generated by a program is subordinate to other limits on disk usage, such as filesize or disk quotas. This limit is often used as a less severe method of controlling disk space consumption. Since users do not generate core files and often do not delete them, this setting may save them from running out of disk space should a large program crash.
cputime	The maximum amount of CPU time a user’s process may consume. Offending processes will be killed by the kernel. This is a limit on CPU time consumed, not the percentage of the CPU as displayed in some of the fields generated by top and ps.
filesize	The maximum size of a file the user may own. Unlike disk quotas , this limit is enforced on individual files, not the set of all files a user owns.
maxproc	The maximum number of foreground and background processes a user can run. This limit may not be larger than the system limit specified by kern.maxproc. Setting this limit too small may hinder a user’s productivity as some tasks, such as compiling a large program, start lots of processes.
memorylocked	The maximum amount of memory a process may request to be locked into main memory using mlock. Some system-critical programs, such as amd, lock into main memory so that if the system begins to swap, they do not contribute to disk thrashing.
memoryuse	The maximum amount of memory a process may consume at any given time. It includes both core memory and swap usage. This is not a catch-all limit for restricting memory consumption, but is a good start.
openfiles	The maximum number of files a process may have open. In FreeBSD, files are used to represent sockets and IPC channels, so be careful not to set this too low. The system-wide limit for this is defined by kern.maxfiles.
sbsize	The limit on the amount of network memory a user may consume. This can be generally used to limit network communications.
stacksize	The maximum size of a process stack. This alone is not sufficient to limit the amount of memory a program may use, so it should be used in conjunction with other limits.

خوب یه سری چیزارو تو این روش موقع تنظیم کردن رول ها و کلاس ها باید به خاطر داشته باشین :

•  تمام پروسس هایی که تحت /etc/rc هستند به صورت استارت آپ اند و تحت لاگین کلاس deamon
• مقادیر پیشفرض خود فایل login.conf منبع خوبیه واسه یادگیری خیلی از limit ها که شاید به درد سیستمی هم که دارید باهاش کار میکنید نخورند . پس اول مواردی رو که قبلا تست کردید رو توی محیط واقعی پیاده کنید :دی
• Xorg میتونه کمک خوبی تو این زمینه بکنه هم از نظر کاربری هم منبع ، به طوری که میشه چندین برنامه رو به صورت Simulate شده اجرا کنید.
• محدودیت ها توی این روش به صورت یوزر به یوزر اعمال میشه یه جورایی فردی میشه . مثلا اگه openfiles رو واسه یه یوزر بزاریم رو 100 هم زمان میتونه فقط 100 تا فایل رو در حالت open بزاره . ( یه چیزی تو مایه های ulimit توی gnu )

Resource Limits Configurations

به صورت پیشفرض کرنل فری بی اس دی ، rctl رو ساپورت نمیکنه یعنی اگه بخوایم از این روش استفاده کنیم لازمه که کرنل رو یک بار Recompile کنیم ، زیاد سخت نیست :دی اگه بشه یه پست اختصاصی برای کامپایل کرنل بی اس دی توی پورتال قرار میدم .

خوب توی پروسه ریکامپایل باید خطوط زیر رو به GENERIC اضافه کنیم :

options         RACCT
options         RCTL

وقتی کامپایل تموم شد و سیستم رو ریبوت کردیم rctl قابل استفاده میشه برای پیاده سازی رول ها.

syntax رول ها هم به شکل زیره :

user:n3td3vil:maxproc:deny=50/user

به ترتیب subject ، subject-id ، Resource ، actions

خوب رول بالا میگه که یوزر n3td3vil بیشتر از 50 تا پروسس نمیتونه ایجاد کنه ، هر پروسس جدیدی بعد از 50 تا بخواد ایجاد بشه لاگ میشه و یه Alert یا notify به devd میده که یا مدیریت کنه پروسس های جدید رو قبل از ایجاد ( یعنی تو نوبت اجرا بزاره ) یا کلا سیگنال sigterm به سمت پروسس بفرسته .

اینجا یه مساله ای رو باید گوشزد کنم اونم اینه که حواستون به تعداد پروسس هایی که برای یه یوزر تعریف میکنید باشه ، یعنی مثلا واسه روت 50 پروسس نذارید :دی اتفاق خوبی نمیوفته مثلا موقع بوت شدن ممکنه بوت نشه سیستم یا موقعی که سیستم up هست توی forke گیر کنه نمونه :

% man netstat
    /usr/bin/man: Cannot fork: Resource temporarily unavailable
eval: Cannot fork: Resource temporarily unavailable

مثال دیگه اینه که بیایم از jail برای memory limit استفاده کنیم :

root@oslearn-lab # rctl -a jail:varnish:memoryuse:deny=2G/jail

لازم به ذکره که رول هایی که به صورت دستی به فایل /etc/rctl.conf اضافه میشوند بعد از هر ریبوت باقی میمونن . خوبی دستی اضافه کردن اینه که میتونین تو فایل کانفیگ کامنت هم بزارین مثل :

# Block jail from using more than 256M memory:
jail:sshd:memoryuse:deny=256M/jail

برای حذف کردن رول هم میتونین از دستور زیر استفاده کنید :

# rctl -r user:n3td3vil:maxproc:deny=10/user

برای پاک کردن همه رول هایی هم که برای یوزر در نظر گرفته شده :

root@oslearn-lab # rctl -r user:n3td3vil

خوب اینم یکی دیگه از موارد امنیتی که باید نه تنها در بی اس دی بلکه در هر سیستم عاملی به فراخور نوع سیستم عامل رعایت بشه .

امیدوارم که در پناه ایزد منان پیروز و سربلند باشید.

نویسنده : محمد ورمزیار (N3td3v!l)

منبع : او اس لرن دات آی آر