مقدمه

در لینوکس، کاربر root بالاترین سطح دسترسی را دارد و می‌تواند تمام فایل‌ها، سرویس‌ها و تنظیمات سیستم را تغییر دهد. استفاده مستقیم و روزمره از حساب root خطرناک است؛ زیرا یک دستور اشتباه می‌تواند باعث حذف اطلاعات، توقف سرویس‌ها یا اختلال کامل سیستم شود.

ابزار sudo به کاربران مجاز اجازه می‌دهد یک دستور مشخص را با سطح دسترسی کاربر دیگری، معمولاً root، اجرا کنند. قوانین sudo در فایل sudoers و فایل‌های داخل مسیر /etc/sudoers.d تعریف می‌شوند.

با استفاده صحیح از sudoers می‌توان مشخص کرد:

• کدام کاربر اجازه اجرای sudo داشته باشد.
• کاربر چه دستورهایی را اجرا کند.
• دستور با هویت کدام کاربر اجرا شود.
• اجرای دستور به رمز عبور نیاز داشته باشد یا خیر.
• دسترسی فقط روی یک Host مشخص اعمال شود.
• مدت اعتبار احراز هویت sudo چقدر باشد.
• فعالیت‌های sudo چگونه ثبت شوند.

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

sudo چیست؟

sudo مخفف عبارت Superuser Do است و برای اجرای کنترل‌شده دستورها با سطح دسترسی بالاتر استفاده می‌شود.

برای مثال، کاربر معمولی معمولاً اجازه Restart کردن Nginx را ندارد:

systemctl restart nginx

اما در صورت داشتن مجوز sudo می‌تواند دستور را به‌شکل زیر اجرا کند:

sudo systemctl restart nginx

sudo ابتدا قوانین تعریف‌شده در sudoers را بررسی می‌کند. اگر کاربر مجاز باشد، دستور با دسترسی تعیین‌شده اجرا می‌شود.

داشتن دسترسی sudo لزوماً به‌معنای داشتن دسترسی کامل root نیست. می‌توان دسترسی کاربر را فقط به چند دستور مشخص محدود کرد.

فایل sudoers چیست؟

فایل اصلی تنظیمات sudo در مسیر زیر قرار دارد:

/etc/sudoers

فایل‌های تنظیمات جداگانه نیز معمولاً در مسیر زیر قرار می‌گیرند:

/etc/sudoers.d/

برای مشاهده Permission فایل اصلی:

ls -l /etc/sudoers

نمونه خروجی:

-r--r----- 1 root root 1714 Jul 25 10:20 /etc/sudoers

Permission استاندارد این فایل معمولاً برابر است با:

0440

مالک و گروه آن نیز معمولاً باید root باشند.

بررسی عددی Permission:

stat -c '%a %U %G %n' /etc/sudoers

نمونه خروجی:

440 root root /etc/sudoers

چرا نباید sudoers را مستقیماً ویرایش کنیم؟

برای ویرایش sudoers نباید مستقیماً از دستورهایی مانند موارد زیر استفاده کرد:

nano /etc/sudoers

یا:

vim /etc/sudoers

یک اشتباه کوچک در Syntax فایل ممکن است باعث شود تمام دسترسی‌های sudo از کار بیفتند.

ابزار استاندارد و امن برای ویرایش sudoers دستور visudo است:

sudo visudo

دستور visudo مزایای زیر را دارد:

• فایل sudoers را قفل می‌کند.
• از ویرایش هم‌زمان جلوگیری می‌کند.
• قبل از ذخیره، Syntax را بررسی می‌کند.
• در صورت وجود خطا هشدار می‌دهد.
• احتمال قطع دسترسی مدیریتی را کاهش می‌دهد.

نصب sudo

در بیشتر توزیع‌ها sudo به‌صورت پیش‌فرض نصب است.

برای بررسی:

command -v sudo

نمونه خروجی:

/usr/bin/sudo

نصب در Ubuntu و Debian

با دسترسی root:

apt update
apt install sudo -y

نصب در AlmaLinux، Rocky Linux و RHEL

dnf install sudo -y

برای مشاهده نسخه:

sudo --version

افزودن کاربر به گروه مدیریتی

ساده‌ترین روش اعطای دسترسی عمومی sudo، اضافه‌کردن کاربر به گروه مدیریتی توزیع است.

Ubuntu و Debian

در Ubuntu معمولاً از گروه sudo استفاده می‌شود:

sudo usermod -aG sudo ali

بررسی عضویت:

id ali

نمونه خروجی:

uid=1001(ali) gid=1001(ali) groups=1001(ali),27(sudo)

قانون مربوط به گروه sudo معمولاً به‌شکل زیر است:

%sudo ALL=(ALL:ALL) ALL

AlmaLinux، Rocky Linux و RHEL

در این توزیع‌ها معمولاً از گروه wheel استفاده می‌شود:

sudo usermod -aG wheel ali

بررسی:

id ali

نمونه خروجی:

uid=1001(ali) gid=1001(ali) groups=1001(ali),10(wheel)

قانون گروه wheel معمولاً به‌شکل زیر است:

%wheel ALL=(ALL) ALL

یا در برخی تنظیمات:

%wheel ALL=(ALL:ALL) ALL

کاربر باید از Session فعلی خارج و دوباره وارد شود تا عضویت جدید گروه اعمال شود.

بررسی دسترسی‌های sudo کاربر

برای مشاهده دستورهایی که کاربر فعلی اجازه اجرای آن‌ها را دارد:

sudo -l

نمونه خروجی:

User ali may run the following commands on server:
    (ALL : ALL) ALL

برای بررسی دسترسی یک کاربر دیگر:

sudo -l -U ali

اجرای این دستور به دسترسی مدیریتی نیاز دارد.

برای بررسی اینکه sudo کار می‌کند:

sudo whoami

خروجی صحیح:

root

ساختار کلی یک قانون sudoers

ساختار کلی Rule به‌شکل زیر است:

USER HOST=(RUNAS_USER:RUNAS_GROUP) TAGS COMMANDS

نمونه:

ali ALL=(root) /usr/bin/systemctl restart nginx

اجزای این Rule:

User: ali
Host: ALL
Run as user: root
Allowed command: /usr/bin/systemctl restart nginx

این قانون به کاربر ali اجازه می‌دهد فقط دستور مشخص‌شده را با هویت root اجرا کند.

توضیح بخش‌های قانون sudoers

USER

این بخش مشخص می‌کند قانون برای چه کاربر یا گروهی اعمال شود.

برای یک کاربر:

ali

برای یک گروه، نام گروه با % آغاز می‌شود:

%developers

HOST

این بخش مشخص می‌کند قانون روی چه سیستم‌هایی معتبر است.

مقدار رایج:

ALL

در سرورهای مستقل معمولاً از ALL استفاده می‌شود.

نمونه محدودکردن به Host مشخص:

ali web-server=(root) /usr/bin/systemctl restart nginx

نام Host را می‌توان با دستور زیر مشاهده کرد:

hostname

RUNAS_USER

این بخش مشخص می‌کند دستور با هویت کدام کاربر اجرا شود.

برای اجرای دستور با کاربر root:

(root)

برای اجازه اجرا با هر کاربر:

(ALL)

RUNAS_GROUP

می‌توان گروه اجرایی را نیز تعیین کرد:

(root:root)

یا:

(ALL:ALL)

نمونه:

ali ALL=(root:root) /usr/bin/id

COMMANDS

این بخش دستورها و Argumentهای مجاز را مشخص می‌کند.

نمونه:

/usr/bin/systemctl status nginx

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

برای پیدا کردن مسیر کامل:

command -v systemctl

نمونه خروجی:

/usr/bin/systemctl

دسترسی کامل sudo برای یک کاربر

برای دادن دسترسی کامل:

ali ALL=(ALL:ALL) ALL

این Rule به کاربر ali اجازه می‌دهد تمام دستورها را با هویت تمام کاربران و گروه‌ها اجرا کند.

این سطح دسترسی تقریباً معادل دسترسی مدیریتی کامل است و باید فقط در صورت نیاز واقعی داده شود.

استفاده از فایل‌های /etc/sudoers.d

بهتر است به‌جای قراردادن تمام Ruleها داخل /etc/sudoers، برای هر کاربر، گروه یا سرویس یک فایل جداگانه در /etc/sudoers.d ایجاد شود.

مزایای این روش:

• مدیریت آسان‌تر
• کاهش احتمال خراب‌شدن فایل اصلی
• تفکیک Ruleهای کاربران
• حذف و Backup ساده‌تر
• مناسب برای Automation و Configuration Management

برای کاربر ali فایل جداگانه ایجاد کنید:

sudo visudo -f /etc/sudoers.d/ali

محتوای نمونه:

ali ALL=(root) /usr/bin/systemctl status nginx

فایل را ذخیره کنید.

بررسی Permission فایل sudoers.d

فایل‌های این مسیر معمولاً باید Permission برابر 0440 داشته باشند:

sudo chmod 440 /etc/sudoers.d/ali

مالکیت:

sudo chown root:root /etc/sudoers.d/ali

بررسی:

stat -c '%a %U %G %n' /etc/sudoers.d/ali

خروجی موردانتظار:

440 root root /etc/sudoers.d/ali

نام‌گذاری فایل‌های sudoers.d

برای نام فایل از ساختار ساده استفاده کنید:

ali
developers
nginx-operators
backup-admins

بهتر است از موارد زیر در نام فایل استفاده نشود:

Dots
Spaces
Temporary suffixes
Editor backup suffixes

برخی نسخه‌های sudo فایل‌هایی را که نام آن‌ها شامل . باشد یا با ~ تمام شوند، در Include Directory نادیده می‌گیرند.

نمونه نام مناسب:

nginx-operators

نمونه نام نامناسب:

nginx-operators.conf
nginx-operators~

بررسی Syntax فایل sudoers

برای بررسی تمام فایل‌ها:

sudo visudo -c

خروجی صحیح:

/etc/sudoers: parsed OK
/etc/sudoers.d/ali: parsed OK

برای بررسی یک فایل مشخص:

sudo visudo -c -f /etc/sudoers.d/ali

خروجی:

/etc/sudoers.d/ali: parsed OK

قبل از بستن Session مدیریتی، همیشه این بررسی را انجام دهید.

محدودکردن کاربر به یک دستور

برای اجازه مشاهده وضعیت Nginx:

ali ALL=(root) /usr/bin/systemctl status nginx

کاربر می‌تواند اجرا کند:

sudo /usr/bin/systemctl status nginx

اما اجرای دستور زیر مجاز نخواهد بود:

sudo /usr/bin/systemctl restart nginx

خروجی احتمالی:

Sorry, user ali is not allowed to execute '/usr/bin/systemctl restart nginx' as root.

اجازه Restart یک سرویس مشخص

برای اجازه Restart کردن Nginx:

ali ALL=(root) /usr/bin/systemctl restart nginx

اجرای مجاز:

sudo /usr/bin/systemctl restart nginx

این Rule اجازه Restart سرویس‌های دیگر را نمی‌دهد.

اگر کاربر امکان تغییر فایل Unit، Drop-in یا Binary مربوط به سرویس را داشته باشد، اجازه Restart کردن همان سرویس می‌تواند به افزایش سطح دسترسی منجر شود.

اجازه چند دستور مشخص

دستورها با کاما از هم جدا می‌شوند:

ali ALL=(root) /usr/bin/systemctl status nginx, /usr/bin/systemctl restart nginx, /usr/bin/systemctl reload nginx

برای خوانایی بهتر می‌توان از Line Continuation استفاده کرد:

ali ALL=(root) \
    /usr/bin/systemctl status nginx, \
    /usr/bin/systemctl restart nginx, \
    /usr/bin/systemctl reload nginx

دسترسی به مدیریت چند سرویس مشخص

نمونه برای کاربر Web Administrator:

ali ALL=(root) \
    /usr/bin/systemctl status nginx, \
    /usr/bin/systemctl restart nginx, \
    /usr/bin/systemctl reload nginx, \
    /usr/bin/systemctl status php8.3-fpm, \
    /usr/bin/systemctl restart php8.3-fpm

مسیر و نام دقیق سرویس‌ها را قبل از تعریف بررسی کنید:

command -v systemctl
systemctl list-unit-files | grep -E 'nginx|php'

اجازه مشاهده Log یک سرویس

برای دادن دسترسی به Logهای Nginx:

ali ALL=(root) /usr/bin/journalctl --no-pager -u nginx

دستور مجاز:

sudo /usr/bin/journalctl --no-pager -u nginx

استفاده از --no-pager اهمیت دارد؛ زیرا بعضی Pagerها قابلیت اجرای Command یا Shell Escape دارند.

برای مشاهده تعداد مشخصی از خطوط:

ali ALL=(root) /usr/bin/journalctl --no-pager -u nginx -n 100

کاربر باید همان Command و Argumentهای تعریف‌شده را اجرا کند:

sudo /usr/bin/journalctl --no-pager -u nginx -n 100

دسترسی ویرایش یک فایل مشخص با sudoedit

دادن اجازه اجرای Editorهایی مانند vim یا nano با sudo می‌تواند خطرناک باشد؛ زیرا بعضی Editorها امکان اجرای Shell یا Commandهای دیگر را دارند.

Rule خطرناک:

ali ALL=(root) /usr/bin/vim /etc/nginx/nginx.conf

روش امن‌تر استفاده از sudoedit است:

ali ALL=(root) sudoedit /etc/nginx/nginx.conf

کاربر فایل را با دستور زیر ویرایش می‌کند:

sudoedit /etc/nginx/nginx.conf

sudoedit یک نسخه موقت از فایل را با دسترسی کاربر باز می‌کند و پس از ذخیره، تغییرات را با کنترل sudo به فایل اصلی منتقل می‌کند.

اجرای دستور با کاربری غیر از root

فرض کنید سرویس برنامه با کاربر appuser اجرا می‌شود.

Rule:

ali ALL=(appuser) /usr/bin/id

اجرای دستور:

sudo -u appuser /usr/bin/id

نمونه خروجی:

uid=1002(appuser) gid=1002(appuser) groups=1002(appuser)

تعریف دسترسی برای یک گروه

برای دادن دسترسی به تمام اعضای گروه developers:

%developers ALL=(root) /usr/bin/systemctl restart nginx

علامت % نشان می‌دهد Rule مربوط به یک گروه است.

عضویت کاربر را بررسی کنید:

id ali

افزودن کاربر به گروه:

sudo usermod -aG developers ali

کاربر باید Logout و دوباره Login کند.

استفاده از NOPASSWD

به‌صورت پیش‌فرض sudo برای اجرای دستور از کاربر رمز عبور می‌خواهد.

برای اجرای یک دستور بدون رمز:

ali ALL=(root) NOPASSWD: /usr/bin/systemctl restart nginx

اجرای دستور:

sudo /usr/bin/systemctl restart nginx

در این حالت رمز عبور درخواست نمی‌شود.

محدودکردن NOPASSWD به دستور مشخص

روش مناسب:

ali ALL=(root) NOPASSWD: /usr/bin/systemctl restart nginx

روش بسیار خطرناک:

ali ALL=(ALL:ALL) NOPASSWD: ALL

Rule دوم به کاربر اجازه می‌دهد تمام دستورها را بدون رمز و با سطح دسترسی کامل اجرا کند.

از NOPASSWD فقط برای Commandهای دقیق، محدود و قابل‌اعتماد استفاده کنید.

ترکیب PASSWD و NOPASSWD

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

ali ALL=(root) \
    NOPASSWD: /usr/bin/systemctl status nginx, \
    PASSWD: /usr/bin/systemctl restart nginx

در این حالت:

Status command: No password required
Restart command: Password required

تعریف Command Alias

برای جلوگیری از تکرار دستورها می‌توان از Cmnd_Alias استفاده کرد.

نمونه:

Cmnd_Alias NGINX_CMDS = \
    /usr/bin/systemctl status nginx, \
    /usr/bin/systemctl restart nginx, \
    /usr/bin/systemctl reload nginx

سپس:

ali ALL=(root) NGINX_CMDS

برای گروه:

%webadmins ALL=(root) NGINX_CMDS

نام Aliasها معمولاً با حروف بزرگ نوشته می‌شود.

تعریف User Alias

برای گروه‌بندی چند کاربر داخل sudoers:

User_Alias WEB_ADMINS = ali, reza, sara

سپس:

WEB_ADMINS ALL=(root) NGINX_CMDS

در مدیریت معمول سیستم بهتر است تا حد امکان از گروه‌های واقعی لینوکس استفاده شود؛ زیرا مدیریت عضویت گروه‌ها ساده‌تر است.

تعریف Runas Alias

برای تعیین مجموعه‌ای از کاربران مقصد:

Runas_Alias APP_USERS = appuser, www-data

نمونه Rule:

ali ALL=(APP_USERS) /usr/bin/id

تعریف Host Alias

در محیط‌هایی که یک sudoers مشترک میان چند سیستم استفاده می‌شود:

Host_Alias WEB_SERVERS = web01, web02, web03

سپس:

%webadmins WEB_SERVERS=(root) NGINX_CMDS

نمونه کامل Aliasها

User_Alias WEB_ADMINS = ali, reza
Host_Alias WEB_SERVERS = web01, web02
Runas_Alias ROOT_USER = root

Cmnd_Alias NGINX_CMDS = \
    /usr/bin/systemctl status nginx, \
    /usr/bin/systemctl restart nginx, \
    /usr/bin/systemctl reload nginx

WEB_ADMINS WEB_SERVERS=(ROOT_USER) NGINX_CMDS

محدودکردن Argumentهای دستور

sudoers می‌تواند Command و Argumentهای آن را بررسی کند.

Rule زیر فقط اجازه Restart کردن Nginx را می‌دهد:

ali ALL=(root) /usr/bin/systemctl restart nginx

دستور مجاز:

sudo /usr/bin/systemctl restart nginx

دستور غیرمجاز:

sudo /usr/bin/systemctl restart ssh

هرچه Rule دقیق‌تر باشد، سطح دسترسی محدودتر و امن‌تر خواهد بود.

خطر استفاده از Wildcard

می‌توان در Ruleها از Wildcard استفاده کرد، اما این کار ممکن است خطرناک باشد.

نمونه:

ali ALL=(root) /usr/bin/systemctl restart *

این Rule ممکن است به کاربر اجازه Restart کردن هر سرویسی را بدهد:

sudo /usr/bin/systemctl restart ssh
sudo /usr/bin/systemctl restart firewalld
sudo /usr/bin/systemctl restart database

نمونه دیگر:

ali ALL=(root) /bin/cat /var/log/*

Wildcardها ممکن است با Argumentها، Spaceها یا رفتار Command ترکیب شده و دسترسی بیش‌ازحد ایجاد کنند.

بهتر است Commandها به‌صورت صریح تعریف شوند:

ali ALL=(root) /bin/cat /var/log/nginx/access.log, /bin/cat /var/log/nginx/error.log

خطر اجازه اجرای Shell

Ruleهای زیر عملاً دسترسی کامل root ایجاد می‌کنند:

ali ALL=(root) /bin/bash

ali ALL=(root) /bin/sh

ali ALL=(root) /usr/bin/su

ali ALL=(root) /usr/bin/sudo

کاربر می‌تواند با دستور زیر Shell کامل root دریافت کند:

sudo /bin/bash

خروجی:

root

به کاربرانی که نباید دسترسی کامل داشته باشند، اجازه اجرای Shell، su، sudo یا ابزارهای مشابه ندهید.

خطر Editorها و ابزارهای تعاملی

بعضی برنامه‌ها قابلیت اجرای Shell یا Command دارند، از جمله:

vim
vi
less
more
man
awk
find
tar
rsync
python
perl
ruby
php
bash
sh

برای مثال، دادن دسترسی root به vim می‌تواند امکان اجرای Shell را فراهم کند.

Rule پرخطر:

ali ALL=(root) /usr/bin/vim

در زمان محدودسازی دسترسی، فقط نام Command را بررسی نکنید؛ قابلیت‌های داخلی آن را نیز در نظر بگیرید.

خطر اجازه اجرای Package Manager

Ruleهای زیر دسترسی بسیار گسترده‌ای ایجاد می‌کنند:

ali ALL=(root) /usr/bin/apt *

ali ALL=(root) /usr/bin/dnf *

Package Managerها می‌توانند Package، Script و Repositoryهایی را با دسترسی root نصب یا اجرا کنند.

دادن دسترسی Package Manager معمولاً معادل دسترسی کامل مدیریتی است.

خطر اجازه chmod و chown

دسترسی آزاد به دستورهای زیر نیز می‌تواند باعث افزایش سطح دسترسی شود:

ali ALL=(root) /usr/bin/chmod *

ali ALL=(root) /usr/bin/chown *

کاربر می‌تواند مالکیت یا Permission فایل‌های حساس را تغییر دهد.

Ruleها باید به مسیر و Argument دقیق محدود شوند و حتی در این حالت نیز اثرات امنیتی بررسی شوند.

استفاده از علامت ! برای منع دستور

می‌توان یک Command را با ! منع کرد:

ali ALL=(root) ALL, !/bin/bash

اما این روش برای ایجاد دسترسی محدود توصیه نمی‌شود.

کاربر ممکن است از مسیر یا Command دیگری به Shell دسترسی پیدا کند:

sh
dash
sudo
su
python
perl
vim
less
find

روش امن‌تر این است که به‌جای اجازه ALL و مسدودکردن چند Command، فقط Commandهای لازم را Allow کنید.

مشاهده مسیر واقعی دستور

همیشه مسیر Command را روی همان سرور بررسی کنید:

command -v systemctl
command -v journalctl
command -v nginx
command -v apt
command -v dnf

نمونه خروجی:

/usr/bin/systemctl
/usr/bin/journalctl
/usr/sbin/nginx

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

تنظیم زمان اعتبار رمز sudo

پس از واردکردن رمز، sudo معمولاً برای مدتی دوباره رمز درخواست نمی‌کند. این مدت با timestamp_timeout کنترل می‌شود.

برای کاربر ali:

Defaults:ali timestamp_timeout=5

این مقدار اعتبار احراز هویت را روی پنج دقیقه قرار می‌دهد.

برای درخواست رمز در هر بار اجرا:

Defaults:ali timestamp_timeout=0

برای غیرفعال‌کردن Timeout و اعتبار تا پایان Session:

Defaults:ali timestamp_timeout=-1

مقدار منفی از نظر امنیتی برای سیستم‌های اشتراکی توصیه نمی‌شود.

حذف اعتبار فعلی sudo

برای حذف Timestamp فعلی:

sudo -k

پس از اجرای این دستور، sudo در اجرای بعدی دوباره رمز درخواست می‌کند:

sudo whoami

برای حذف کامل Credentialهای ذخیره‌شده:

sudo -K

تازه‌سازی اعتبار sudo

برای تأیید رمز و تازه‌سازی Timestamp بدون اجرای Command:

sudo -v

این دستور در Scriptها یا قبل از اجرای چند عملیات مدیریتی کاربرد دارد.

اجرای غیرتعاملی sudo

گزینه -n مانع درخواست تعاملی رمز می‌شود:

sudo -n whoami

اگر رمز لازم باشد، دستور با خطا متوقف می‌شود:

sudo: a password is required

این گزینه برای Automation مناسب است؛ اما Rule باید به‌درستی و با حداقل دسترسی تعریف شده باشد.

تنظیم تعداد دفعات ورود رمز

برای محدودکردن تعداد تلاش:

Defaults passwd_tries=3

این تنظیم مشخص می‌کند کاربر چند بار بتواند رمز را اشتباه وارد کند.

نمایش پیام هنگام واردکردن رمز

در حالت عادی sudo هنگام واردکردن رمز چیزی نمایش نمی‌دهد.

می‌توان نمایش ستاره را فعال کرد:

Defaults pwfeedback

نمونه:

[sudo] password for ali: ********

این تنظیم بیشتر جنبه رابط کاربری دارد و در بعضی محیط‌ها ممکن است توصیه نشود.

تنظیم secure_path

متغیر secure_path مسیر جست‌وجوی Commandها را هنگام اجرای sudo مشخص می‌کند.

نمونه:

Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

این تنظیم خطر اجرای Binaryهای جعلی از مسیرهای کنترل‌شده توسط کاربر را کاهش می‌دهد.

بااین‌حال، در Ruleهای محدودشده همچنان باید مسیر کامل Command نوشته شود.

کنترل متغیرهای محیطی

sudo معمولاً بسیاری از Environment Variableها را حذف یا بازنشانی می‌کند.

برای مشاهده Environment:

sudo env

استفاده از گزینه زیر Environment کاربر را حفظ می‌کند:

sudo -E command

اما این قابلیت می‌تواند خطرناک باشد؛ زیرا متغیرهایی مانند موارد زیر ممکن است رفتار برنامه را تغییر دهند:

PATH
PYTHONPATH
PERL5LIB
LD_PRELOAD
LD_LIBRARY_PATH
EDITOR
VISUAL

اجازه حفظ Environment فقط در صورت نیاز واقعی داده شود.

استفاده از SETENV

Tag زیر به کاربر اجازه تغییر Environment در sudo را می‌دهد:

ali ALL=(root) SETENV: /usr/local/bin/application

این Tag می‌تواند سطح دسترسی را افزایش دهد و باید با احتیاط استفاده شود.

ثبت فعالیت‌های sudo

sudo معمولاً فعالیت‌ها را از طریق Syslog یا Journal ثبت می‌کند.

Ubuntu و Debian

جست‌وجوی Logهای sudo:

sudo journalctl | grep sudo

یا:

sudo grep sudo /var/log/auth.log

AlmaLinux و RHEL

sudo journalctl | grep sudo

یا:

sudo grep sudo /var/log/secure

نمونه Log:

ali : TTY=pts/0 ; PWD=/home/ali ; USER=root ; COMMAND=/usr/bin/systemctl restart nginx

تعریف فایل Log اختصاصی

می‌توان یک فایل Log برای sudo تعریف کرد:

Defaults logfile="/var/log/sudo.log"

پس از اعمال، فایل را بررسی کنید:

sudo tail -f /var/log/sudo.log

Permission و Rotation فایل Log باید به‌درستی مدیریت شود.

مشاهده Commandهای مجاز بدون اجرا

برای مشاهده Ruleهای کاربر:

sudo -l

برای بررسی دقیق یک Command:

sudo -l /usr/bin/systemctl restart nginx

اگر مجاز باشد، اطلاعات مربوط نمایش داده می‌شود.

برای کاربر دیگر:

sudo -l -U ali

مثال عملی: مدیر محدود Nginx

فرض کنید کاربر ali باید فقط بتواند:

• وضعیت Nginx را مشاهده کند.
• تنظیمات Nginx را آزمایش کند.
• Nginx را Reload کند.
• Logهای Nginx را مشاهده کند.

فایل ایجاد کنید:

sudo visudo -f /etc/sudoers.d/nginx-operator

محتوا:

Cmnd_Alias NGINX_OPERATOR = \
    /usr/bin/systemctl status nginx, \
    /usr/sbin/nginx -t, \
    /usr/bin/systemctl reload nginx, \
    /usr/bin/journalctl --no-pager -u nginx -n 100

ali ALL=(root) NGINX_OPERATOR

Syntax را بررسی کنید:

sudo visudo -c

خروجی:

/etc/sudoers: parsed OK
/etc/sudoers.d/nginx-operator: parsed OK

دسترسی کاربر:

sudo -l -U ali

مثال عملی: دسترسی بدون رمز برای Backup Script

فرض کنید Script امن Backup در مسیر زیر قرار دارد:

/usr/local/sbin/run-backup

مالکیت و Permission را بررسی کنید:

sudo chown root:root /usr/local/sbin/run-backup
sudo chmod 750 /usr/local/sbin/run-backup

بررسی:

stat -c '%a %U %G %n' /usr/local/sbin/run-backup

خروجی:

750 root root /usr/local/sbin/run-backup

Rule:

backupuser ALL=(root) NOPASSWD: /usr/local/sbin/run-backup

اجرا:

sudo /usr/local/sbin/run-backup

کاربر نباید امکان ویرایش Script، فایل‌های فراخوانی‌شده توسط Script یا دایرکتوری والد آن را داشته باشد.

بررسی امنیت Script مجازشده

اگر sudo اجازه اجرای یک Script را می‌دهد، موارد زیر را بررسی کنید:

namei -l /usr/local/sbin/run-backup

مالکیت Script:

stat -c '%a %U %G %n' /usr/local/sbin/run-backup

تمام فایل‌ها و برنامه‌های فراخوانی‌شده توسط Script نیز باید امن باشند.

موارد خطرناک:

User-writable script
User-writable parent directory
Relative command paths
Untrusted configuration files
Unvalidated user input
Writable environment files
Wildcard expansion

داخل Scriptهای مدیریتی از مسیر کامل Commandها استفاده کنید:

#!/bin/bash

set -euo pipefail
/usr/bin/tar -czf /var/backups/data.tar.gz /srv/data

نه:

#!/bin/bash

tar -czf /var/backups/data.tar.gz /srv/data

ویرایش sudoers با Editor مشخص

visudo معمولاً از Editor پیش‌فرض سیستم استفاده می‌کند.

برای اجرای موقت با Nano:

sudo EDITOR=nano visudo

برای ویرایش فایل مشخص:

sudo EDITOR=nano visudo -f /etc/sudoers.d/ali

این Environment فقط برای همان اجرا استفاده می‌شود.

ترتیب اعمال Ruleها

ممکن است چند Rule برای یک کاربر یا گروه وجود داشته باشد.

برای مشاهده همه Ruleهای مؤثر:

sudo -l

در sudoers، ترتیب و تطبیق Ruleها اهمیت دارد. در بعضی شرایط آخرین Tag یا Rule منطبق می‌تواند نتیجه نهایی را تغییر دهد.

برای جلوگیری از رفتار پیچیده:

• Ruleهای تکراری ایجاد نکنید.
• دسترسی کاربر و گروه را هم‌زمان بررسی کنید.
• از Allow و Denyهای متداخل خودداری کنید.
• Ruleها را در فایل‌های جداگانه و مستند نگه دارید.
• نتیجه را با sudo -l -U USER آزمایش کنید.

حذف دسترسی sudo کاربر

حذف از گروه sudo در Ubuntu

sudo gpasswd -d ali sudo

حذف از گروه wheel در AlmaLinux

sudo gpasswd -d ali wheel

حذف فایل اختصاصی

sudo rm -f /etc/sudoers.d/ali

سپس Syntax را بررسی کنید:

sudo visudo -c

عضویت کاربر:

id ali

دسترسی‌ها:

sudo -l -U ali

غیرفعال‌کردن موقت یک Rule

برای غیرفعال‌کردن یک خط می‌توان آن را Comment کرد:

# ali ALL=(root) /usr/bin/systemctl restart nginx

اما برای فایل اختصاصی، می‌توان فایل را با ابزار مناسب به مسیری خارج از /etc/sudoers.d منتقل کرد.

قبل از تغییر همیشه Session مدیریتی فعلی را باز نگه دارید.

رفع خطاهای رایج sudoers

خطای user is not in the sudoers file

نمونه خطا:

ali is not in the sudoers file.

در Ubuntu:

usermod -aG sudo ali

در AlmaLinux:

usermod -aG wheel ali

این دستورها باید با دسترسی root یا یک حساب مدیریتی دیگر اجرا شوند.

کاربر سپس باید Logout و دوباره Login کند.

خطای syntax error near line

نمونه:

/etc/sudoers: syntax error near line 25

فایل را با visudo باز کنید:

visudo

یا فایل مربوط:

visudo -f /etc/sudoers.d/ali

بررسی:

visudo -c

تا زمان رفع خطا، Session فعلی root یا sudo را نبندید.

فایل sudoers.d نادیده گرفته می‌شود

موارد زیر را بررسی کنید:

ls -la /etc/sudoers.d/

Permission:

stat -c '%a %U %G %n' /etc/sudoers.d/ali

مقدار مطلوب:

440 root root /etc/sudoers.d/ali

Syntax:

sudo visudo -c -f /etc/sudoers.d/ali

نام فایل نباید شامل ساختارهای Backup یا Temporary باشد.

کاربر عضو گروه sudo است اما دسترسی ندارد

عضویت را بررسی کنید:

id ali

Session جدید ایجاد کنید:

su - ali

یا کاربر Logout و Login کند.

سپس:

sudo -l

همچنین Rule گروه را در sudoers بررسی کنید:

sudo visudo

Ubuntu:

%sudo ALL=(ALL:ALL) ALL

AlmaLinux:

%wheel ALL=(ALL) ALL

sudo همچنان رمز درخواست می‌کند

بررسی کنید Tag به‌شکل صحیح نوشته شده باشد:

ali ALL=(root) NOPASSWD: /usr/bin/systemctl restart nginx

Command اجراشده باید دقیقاً با Rule مطابقت داشته باشد:

sudo /usr/bin/systemctl restart nginx

بررسی دسترسی:

sudo -l

ممکن است Rule دیگری Tag PASSWD را دوباره اعمال کرده باشد.

Command not allowed با وجود Rule

مسیر Command را بررسی کنید:

command -v systemctl

Rule:

ali ALL=(root) /usr/bin/systemctl restart nginx

دستور اجراشده:

sudo /usr/bin/systemctl restart nginx

موارد زیر می‌توانند باعث عدم تطبیق شوند:

• مسیر متفاوت
• Argument متفاوت
• ترتیب متفاوت Argumentها
• استفاده از Symlink متفاوت
• تفاوت نام سرویس
• وجود Space یا Option اضافه

خطای bad permissions

نمونه:

sudo: /etc/sudoers.d/ali is world writable

اصلاح:

sudo chown root:root /etc/sudoers.d/ali
sudo chmod 440 /etc/sudoers.d/ali

بررسی:

sudo visudo -c

دسترسی sudo کاملاً قطع شده است

در صورت داشتن Session باز root، همان Session را نبندید.

Syntax را بررسی کنید:

visudo -c

فایل را اصلاح کنید:

visudo

اگر مشکل مربوط به فایل جداگانه است:

visudo -f /etc/sudoers.d/ali

اگر هیچ دسترسی مدیریتی وجود ندارد، از یکی از روش‌های زیر استفاده کنید:

Provider console
KVM console
VNC console
Serial console
Rescue mode
Single-user mode
Direct root login if enabled

فایل sudoers را بدون ابزار بررسی Syntax و بدون داشتن مسیر بازگشت تغییر ندهید.

نکات امنیتی و بهترین روش‌ها

• فایل sudoers را فقط با visudo ویرایش کنید.
• برای Ruleهای جدید از /etc/sudoers.d استفاده کنید.
• قبل از خروج، visudo -c اجرا کنید.
• Session مدیریتی فعلی را تا پایان آزمایش باز نگه دارید.
• به‌جای ALL فقط Commandهای ضروری را مجاز کنید.
• مسیر کامل Command را وارد کنید.
• Argumentهای Command را نیز محدود کنید.
• از Wildcard تا حد امکان استفاده نکنید.
• NOPASSWD را فقط برای دستورهای مشخص فعال کنید.
• به کاربران محدود اجازه اجرای Shell، Editor یا Interpreter ندهید.
• Package Managerها را معادل دسترسی مدیریتی کامل در نظر بگیرید.
• برای ویرایش فایل از sudoedit استفاده کنید.
• Script مجازشده باید متعلق به root و غیرقابل‌ویرایش توسط کاربر باشد.
• دایرکتوری والد Script نیز نباید قابل‌نوشتن باشد.
• فعالیت‌های sudo را مانیتور کنید.
• Ruleهای قدیمی و بلااستفاده را حذف کنید.
• دسترسی کاربران را به‌صورت دوره‌ای با sudo -l -U USER بررسی کنید.
• برای تیم‌ها از گروه‌های لینوکس استفاده کنید.
• دسترسی‌ها را براساس اصل کمترین سطح دسترسی تعریف کنید.

اشتباهات رایج

موارد زیر از اشتباهات متداول هنگام مدیریت sudoers هستند:

• ویرایش مستقیم /etc/sudoers
• ذخیره Rule اشتباه بدون بررسی Syntax
• دادن ALL به کاربری که فقط یک Command نیاز دارد
• استفاده گسترده از NOPASSWD
• استفاده از Wildcardهای ناامن
• اجازه اجرای bash، sh یا su
• اجازه اجرای Editorهای تعاملی با root
• اجازه اجرای Package Manager
• تعریف Command بدون مسیر کامل
• استفاده از Script قابل‌ویرایش توسط کاربر
• نادیده‌گرفتن فایل‌های فراخوانی‌شده توسط Script
• استفاده از Allow کامل و چند Deny با !
• تعریف Ruleهای متداخل در چند فایل
• نام‌گذاری نامناسب فایل‌های /etc/sudoers.d
• تنظیم Permission اشتباه برای فایل Rule
• بستن Session root قبل از آزمایش
• بررسی‌نکردن Logهای sudo
• فراموش‌کردن Logout بعد از تغییر عضویت گروه

چک‌لیست نهایی sudoers

پس از تعریف دسترسی، موارد زیر را بررسی کنید:

• بسته sudo نصب است.
• کاربر یا گروه موردنظر وجود دارد.
• Rule با visudo ایجاد شده است.
• فایل داخل /etc/sudoers.d قرار دارد.
• مالک فایل root است.
• گروه فایل root است.
• Permission فایل برابر 0440 است.
• مسیر کامل Command نوشته شده است.
• Argumentها تا حد امکان محدود شده‌اند.
• از Wildcard غیرضروری استفاده نشده است.
• NOPASSWD فقط برای Command مشخص فعال است.
• کاربر به Shell یا Interpreter دسترسی ندارد.
• Script مجازشده قابل‌ویرایش توسط کاربر نیست.
• visudo -c بدون خطا اجرا می‌شود.
• دسترسی با sudo -l -U USER بررسی شده است.
• Command مجاز آزمایش شده است.
• Command غیرمجاز نیز آزمایش شده است.
• Log اجرای sudo بررسی شده است.
• Session مدیریتی تا پایان آزمایش باز مانده است.

دستورات پرکاربرد sudoers

ویرایش فایل اصلی:

sudo visudo

ایجاد فایل اختصاصی:

sudo visudo -f /etc/sudoers.d/ali

بررسی Syntax:

sudo visudo -c

مشاهده دسترسی کاربر فعلی:

sudo -l

مشاهده دسترسی یک کاربر:

sudo -l -U ali

آزمایش sudo:

sudo whoami

حذف اعتبار فعلی:

sudo -k

تازه‌سازی اعتبار:

sudo -v

اجرای Command با کاربر دیگر:

sudo -u appuser command

بررسی Log:

sudo journalctl | grep sudo

نمونه Ruleهای پرکاربرد

دسترسی کامل:

ali ALL=(ALL:ALL) ALL

دسترسی گروه sudo:

%sudo ALL=(ALL:ALL) ALL

دسترسی گروه wheel:

%wheel ALL=(ALL) ALL

Restart یک سرویس:

ali ALL=(root) /usr/bin/systemctl restart nginx

اجرای بدون رمز:

ali ALL=(root) NOPASSWD: /usr/bin/systemctl restart nginx

مشاهده Log:

ali ALL=(root) /usr/bin/journalctl --no-pager -u nginx -n 100

ویرایش فایل مشخص:

ali ALL=(root) sudoedit /etc/nginx/nginx.conf

اجرای Script امن:

backupuser ALL=(root) NOPASSWD: /usr/local/sbin/run-backup

جمع‌بندی

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

فایل اصلی تنظیمات در مسیر /etc/sudoers قرار دارد، اما برای مدیریت بهتر توصیه می‌شود Ruleهای اختصاصی داخل /etc/sudoers.d ایجاد شوند.

مهم‌ترین ابزار مدیریت sudoers دستور زیر است:

visudo

این ابزار Syntax فایل را قبل از ذخیره بررسی می‌کند و احتمال قطع دسترسی sudo را کاهش می‌دهد.

در طراحی Ruleهای sudo باید اصل کمترین سطح دسترسی رعایت شود. به‌جای دادن ALL، فقط مسیر و Argument دقیق دستورهای موردنیاز مجاز شوند. همچنین NOPASSWD، Wildcardها، Editorها، Shellها، Interpreterها و Scriptهای قابل‌ویرایش باید با حساسیت بیشتری بررسی شوند.

پس از هر تغییر باید Syntax با visudo -c بررسی شده و نتیجه واقعی دسترسی با sudo -l و اجرای Commandهای مجاز و غیرمجاز آزمایش شود.