مقدمه

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

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

لینوکس برای مدیریت چنین شرایطی از Permission ویژه‌ای به نام SUID استفاده می‌کند. وقتی SUID روی یک فایل اجرایی فعال باشد، برنامه هنگام اجرا با Effective UID مالک فایل اجرا می‌شود، نه صرفاً با دسترسی کاربری که آن را اجرا کرده است.

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

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

• SUID چیست و چگونه کار می‌کند؟
• تفاوت Real UID و Effective UID
• روش شناسایی فایل‌های SUID
• فعال‌سازی و حذف SUID
• تفاوت s و S
• آزمایش عملی و کنترل‌شده SUID
• فایل‌سیستم‌های دارای گزینه nosuid
• خطرات امنیتی فایل‌های SUID
• جایگزین‌هایی مانند sudo و Linux Capabilities
• بررسی و عیب‌یابی فایل‌های SUID

SUID چیست؟

SUID مخفف Set User ID است و یکی از Permissionهای ویژه فایل در سیستم‌های Unix و Linux محسوب می‌شود.

هنگامی که SUID روی یک فایل اجرایی فعال باشد، سیستم هنگام اجرای آن، Effective UID پردازش را به UID مالک فایل تغییر می‌دهد. Real UID کاربر اجراکننده بدون تغییر باقی می‌ماند.

برای مثال:

File owner: root
Executing user: ali

Real UID: ali
Effective UID: root

در این حالت، برنامه می‌تواند عملیات مشخصی را با دسترسی مالک فایل انجام دهد.

SUID فقط باید روی فایل‌های اجرایی قابل‌اعتماد و طراحی‌شده برای اجرای Privileged فعال شود.

چرا به SUID نیاز داریم؟

برخی برنامه‌ها باید عملیاتی انجام دهند که کاربران معمولی مستقیماً اجازه انجام آن را ندارند.

برای مثال، تغییر رمز عبور به دسترسی روی فایل‌های امنیتی سیستم نیاز دارد. برنامه مربوط می‌تواند با SUID به‌صورت کنترل‌شده عملیات لازم را انجام دهد، بدون اینکه کاربر به تمام دسترسی‌های root دست پیدا کند.

برنامه SUID باید:

• ورودی کاربر را کنترل کند.
• فقط عملیات موردنیاز را انجام دهد.
• از اجرای Commandهای دلخواه جلوگیری کند.
• دسترسی اضافه را در سریع‌ترین زمان ممکن کنار بگذارد.
• فایل‌ها و مسیرهای قابل‌اعتماد را استفاده کند.
• متغیرهای Environment را با احتیاط مدیریت کند.

وجود آسیب‌پذیری در یک برنامه SUID متعلق به root ممکن است به افزایش سطح دسترسی تا root منجر شود.

تفاوت Real UID و Effective UID

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

Real UID

Real UID مشخص می‌کند پردازش در اصل توسط چه کاربری اجرا شده است.

برای مثال:

Real UID: ali

Effective UID

Effective UID برای بسیاری از بررسی‌های Permission سیستم استفاده می‌شود.

در یک برنامه عادی:

Real UID: ali
Effective UID: ali

در یک برنامه SUID متعلق به root:

Real UID: ali
Effective UID: root

هنگام اجرای یک فایل SUID، Linux می‌تواند Effective UID را به مالک فایل تغییر دهد و سپس آن را در Saved Set-User-ID ذخیره کند. Real UID کاربر اجراکننده تغییر نمی‌کند.

Saved Set-User-ID

Saved Set-User-ID به برنامه اجازه می‌دهد در صورت طراحی صحیح، دسترسی بالاتر را موقتاً کنار بگذارد و در مراحل موردنیاز دوباره آن را فعال کند.

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

مشاهده Permission یک فایل

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

ls -l /path/to/application

نمونه فایل معمولی:

-rwxr-xr-x 1 root root 54256 Jul 27 10:00 application

نمونه فایل دارای SUID:

-rwsr-xr-x 1 root root 54256 Jul 27 10:00 application

حرف s در محل Execute مالک نشان می‌دهد SUID فعال است.

ساختار:

-rwsr-xr-x
 |||
 ||└── Owner execute position
 |└─── Owner write
 └──── Owner read

مشاهده Permission عددی

برای مشاهده Permission عددی:

stat -c '%a %A %U %G %n' /path/to/application

نمونه خروجی:

4755 -rwsr-xr-x root root /path/to/application

عدد اول یعنی 4 نشان‌دهنده SUID است.

ساختار عددی SUID

Permissionهای ویژه در رقم اول Mode چهاررقمی نمایش داده می‌شوند:

برای مثال:

4755

تجزیه:

4 = SUID
7 = Owner: Read, Write, and Execute
5 = Group: Read and Execute
5 = Other: Read and Execute

Permission نمادین:

-rwsr-xr-x

GNU Coreutils برای فعال‌کردن Set-User-ID استفاده از u+s را تعریف کرده است.

فعال‌کردن SUID

برای فعال‌کردن SUID به‌صورت نمادین:

sudo chmod u+s /path/to/application

بررسی:

ls -l /path/to/application

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

-rwsr-xr-x 1 root root 54256 Jul 27 10:00 application

فعال‌کردن SUID به‌صورت عددی

sudo chmod 4755 /path/to/application

این دستور هم‌زمان Permission عادی و SUID را تنظیم می‌کند.

بررسی:

stat -c '%a %A %U %G %n' /path/to/application

خروجی:

4755 -rwsr-xr-x root root /path/to/application

حذف SUID

برای حذف SUID به‌صورت نمادین:

sudo chmod u-s /path/to/application

بررسی:

ls -l /path/to/application

خروجی:

-rwxr-xr-x 1 root root 54256 Jul 27 10:00 application

روش عددی:

sudo chmod 0755 /path/to/application

در Scriptهای قابل‌حمل، بهتر است حذف Bit ویژه را به‌صورت صریح انجام دهید:

sudo chmod u-s /path/to/application

تفاوت s و S

SUID ممکن است با حرف کوچک s یا حرف بزرگ S نمایش داده شود.

حرف کوچک s

اگر SUID و Execute مالک هر دو فعال باشند:

-rwsr-xr-x

حرف کوچک s نمایش داده می‌شود.

این حالت معمول یک فایل اجرایی SUID است.

حرف بزرگ S

اگر SUID فعال باشد اما مالک فایل مجوز Execute نداشته باشد:

-rwSr--r--

حرف بزرگ S نمایش داده می‌شود.

نمونه ساخت چنین وضعیتی:

sudo chmod 4644 application

بررسی:

ls -l application

خروجی:

-rwSr--r-- 1 root root 54256 Jul 27 10:00 application

در این حالت فایل برای مالک Executable نیست و SUID کاربرد اجرایی موردانتظار را ندارد.

برای اصلاح، Execute را اضافه کنید:

sudo chmod u+x application

یا SUID را حذف کنید:

sudo chmod u-s application

بررسی دستور passwd

در بسیاری از توزیع‌ها، فایل اجرایی passwd دارای SUID متعلق به root است. وضعیت واقعی را روی همان سیستم بررسی کنید:

command -v passwd

سپس:

ls -l "$(command -v passwd)"

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

-rwsr-xr-x 1 root root 68248 Feb 10 09:00 /usr/bin/passwd

بررسی عددی:

stat -c '%a %A %U %G %n' "$(command -v passwd)"

نمونه:

4755 -rwsr-xr-x root root /usr/bin/passwd

وجود SUID به برنامه اجازه می‌دهد عملیات محدود و کنترل‌شده مربوط به تغییر رمز عبور را با Effective UID مالک انجام دهد.

SUID به این معنا نیست که کاربر یک Shell کامل root دریافت می‌کند. رفتار نهایی به طراحی داخلی برنامه بستگی دارد.

پیدا کردن فایل‌های SUID

برای پیدا کردن فایل‌های SUID در کل فایل‌سیستم جاری:

sudo find / \
-xdev \
-type f \
-perm -4000 \
-ls 2>/dev/null

گزینه‌ها:

-xdev = Do not cross filesystem boundaries
-type f = Match regular files
-perm -4000 = Match files with SUID enabled
-ls = Display detailed information

نمایش فقط مسیر فایل‌ها

sudo find / \
-xdev \
-type f \
-perm -4000 \
-print 2>/dev/null

نمونه خروجی:

/usr/bin/passwd
/usr/bin/su
/usr/bin/mount
/usr/bin/umount
/usr/bin/chsh

فهرست واقعی به توزیع، Packageهای نصب‌شده و تنظیمات سیستم بستگی دارد.

جست‌وجو در یک مسیر خاص

find /usr/bin /usr/sbin \
-type f \
-perm -4000 \
-ls 2>/dev/null

برای مسیرهای Application:

find /usr/local /opt \
-type f \
-perm -4000 \
-ls 2>/dev/null

فایل‌های SUID غیرمنتظره در /tmp، /var/tmp، Home کاربران، /opt یا /usr/local باید با حساسیت بیشتری بررسی شوند.

پیدا کردن فایل‌های SUID و SGID

برای پیدا کردن فایل‌هایی که SUID یا SGID دارند:

sudo find / \
-xdev \
-type f \
-perm /6000 \
-ls 2>/dev/null

توضیح:

4000 = SUID
2000 = SGID
6000 = SUID or SGID search mask

برای فقط SUID:

sudo find / -xdev -type f -perm -4000 -ls 2>/dev/null

برای فقط SGID:

sudo find / -xdev -type f -perm -2000 -ls 2>/dev/null

ثبت فهرست فایل‌های SUID

برای ایجاد Baseline:

sudo find / \
-xdev \
-type f \
-perm -4000 \
-printf '%m %u %g %p\n' 2>/dev/null \
| sort \
> /root/suid-baseline.txt

مشاهده:

less /root/suid-baseline.txt

نمونه:

4755 root root /usr/bin/passwd
4755 root root /usr/bin/su
4755 root root /usr/bin/chsh

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

sudo find / \
-xdev \
-type f \
-perm -4000 \
-printf '%m %u %g %p\n' 2>/dev/null \
| sort \
> /root/suid-current.txt

مقایسه:

diff -u \
/root/suid-baseline.txt \
/root/suid-current.txt

بررسی Package مالک فایل SUID

در Ubuntu و Debian:

dpkg -S /usr/bin/passwd

نمونه خروجی:

passwd: /usr/bin/passwd

در AlmaLinux، Rocky Linux و RHEL:

rpm -qf /usr/bin/passwd

نمونه خروجی:

passwd-0.80-14.el9.x86_64

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

بررسی Hash فایل

برای محاسبه Hash:

sha256sum /usr/bin/passwd

نمونه خروجی:

f1c80a...  /usr/bin/passwd

برای چند فایل:

sudo find /usr/bin /usr/sbin \
-type f \
-perm -4000 \
-exec sha256sum {} +

Hash فقط زمانی مفید است که با Baseline معتبر یا Package رسمی مقایسه شود.

بررسی تغییرات Package

Ubuntu و Debian

sudo dpkg -V passwd

در صورت وجود فایل‌های Checksum مرتبط، تغییرات احتمالی گزارش می‌شوند.

AlmaLinux و RHEL

sudo rpm -V passwd

خروجی خالی معمولاً به این معنا است که فایل‌های Package نسبت به Metadata ثبت‌شده تغییر مهمی ندارند.

هر خروجی باید براساس معنی ستون‌های ابزار Package Manager بررسی شود.

آزمایش امن SUID

برای مشاهده تفاوت Real UID و Effective UID می‌توان یک برنامه ساده آزمایشی ساخت که فقط شناسه‌ها را نمایش دهد و هیچ Command یا Shell دیگری اجرا نکند.

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

مرحله اول: ایجاد کد آزمایشی

nano /tmp/suid-demo.c

محتوا:

#include <stdio.h>
#include <unistd.h>

int main(void) {
    printf("Real UID: %d\n", getuid());
    printf("Effective UID: %d\n", geteuid());
    printf("Real GID: %d\n", getgid());
    printf("Effective GID: %d\n", getegid());
    return 0;
}

مرحله دوم: نصب Compiler

در Ubuntu:

sudo apt update
sudo apt install build-essential -y

در AlmaLinux:

sudo dnf install gcc -y

مرحله سوم: Compile برنامه

gcc \
-Wall \
-Wextra \
-O2 \
-o /tmp/suid-demo \
/tmp/suid-demo.c

بررسی:

ls -l /tmp/suid-demo

خروجی:

-rwxr-xr-x 1 ali ali 16064 Jul 27 10:00 /tmp/suid-demo

مرحله چهارم: انتقال به مسیر آزمایشی

از اجرای SUID داخل /tmp خودداری کنید؛ زیرا این مسیر در بسیاری از سیستم‌ها ممکن است با گزینه‌های امنیتی مانند nosuid یا noexec Mount شده باشد.

sudo install \
-o root \
-g root \
-m 0755 \
/tmp/suid-demo \
/usr/local/libexec/suid-demo

در صورت نبود مسیر:

sudo mkdir -p /usr/local/libexec

سپس دوباره دستور install را اجرا کنید.

مرحله پنجم: اجرای عادی

/usr/local/libexec/suid-demo

نمونه خروجی برای کاربر ali:

Real UID: 1001
Effective UID: 1001
Real GID: 1001
Effective GID: 1001

مرحله ششم: فعال‌کردن SUID

sudo chmod u+s /usr/local/libexec/suid-demo

بررسی:

stat -c '%a %A %U %G %n' \
/usr/local/libexec/suid-demo

خروجی:

4755 -rwsr-xr-x root root /usr/local/libexec/suid-demo

مرحله هفتم: اجرای مجدد

/usr/local/libexec/suid-demo

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

Real UID: 1001
Effective UID: 0
Real GID: 1001
Effective GID: 1001

این خروجی نشان می‌دهد:

Real UID: Calling user
Effective UID: File owner

مرحله هشتم: پاک‌سازی فوری

ابتدا SUID را حذف کنید:

sudo chmod u-s /usr/local/libexec/suid-demo

سپس فایل‌ها را حذف کنید:

sudo rm -f /usr/local/libexec/suid-demo
rm -f /tmp/suid-demo /tmp/suid-demo.c

بررسی:

test ! -e /usr/local/libexec/suid-demo \
&& echo "SUID demo removed"

خروجی:

SUID demo removed

SUID روی Shell Script

Linux مانند بیشتر سیستم‌های Unix مدرن، Bitهای SUID و SGID روی Interpreter Scriptها را نادیده می‌گیرد. بنابراین قراردادن SUID روی یک فایل Bash، Python یا PHP معمولاً باعث اجرای Script با مالک فایل نمی‌شود. این تصمیم به دلیل مشکلات امنیتی و Race Conditionهای مرتبط با اجرای Scriptها است.

مثال:

sudo chmod 4755 backup.sh

ممکن است ls مقدار زیر را نمایش دهد:

-rwsr-xr-x 1 root root 512 Jul 27 10:00 backup.sh

اما Linux هنگام اجرای مستقیم Script، SUID را اعمال نمی‌کند.

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

sudo with restricted sudoers rules
A reviewed compiled helper
systemd service or timer
Linux file capabilities
PolicyKit where appropriate

تأثیر گزینه nosuid

اگر فایل‌سیستم با گزینه nosuid Mount شده باشد، SUID، SGID و File Capabilityهای اجرایی روی آن فایل‌سیستم اعمال نمی‌شوند.

برای بررسی Mount Option مسیر:

findmnt -T /path/to/application \
-o TARGET,FSTYPE,OPTIONS

نمونه خروجی:

TARGET FSTYPE OPTIONS
/tmp   tmpfs  rw,nosuid,nodev

وجود nosuid نشان می‌دهد Bit SUID در آن مسیر هنگام اجرا مورد استفاده قرار نمی‌گیرد.

بررسی /tmp

findmnt -T /tmp \
-o TARGET,FSTYPE,OPTIONS

نمونه:

TARGET FSTYPE OPTIONS
/tmp   tmpfs  rw,nosuid,nodev,noexec

در چنین شرایطی:

nosuid = Ignore SUID, SGID, and file capabilities
noexec = Prevent direct executable execution
nodev = Ignore device files

دلایل دیگر نادیده‌گرفتن SUID

تغییر Effective UID ناشی از SUID در بعضی شرایط اعمال نمی‌شود، از جمله:

no_new_privs is enabled
Filesystem is mounted nosuid
Process is being ptraced

این محدودیت‌ها در رفتار execve() لینوکس تعریف شده‌اند.

برای بررسی NoNewPrivs یک پردازش:

grep '^NoNewPrivs:' /proc/$$/status

نمونه خروجی:

NoNewPrivs:	0

مقدار 1 نشان می‌دهد Process اجازه کسب Privilege جدید از طریق SUID یا File Capability را ندارد.

SUID و SELinux

SUID بخشی از Permissionهای Unix است، اما SELinux یک لایه امنیتی جداگانه ایجاد می‌کند.

در AlmaLinux، Rocky Linux و RHEL وضعیت SELinux را بررسی کنید:

getenforce

نمونه:

Enforcing

Context فایل:

ls -Z /path/to/application

کاربران SELinux محدودشده ممکن است فقط در صورتی بتوانند برنامه‌های SetUID را اجرا کنند که Policy اجازه دهد.

خطاهای اخیر:

sudo ausearch -m AVC -ts recent

برای بازگرداندن Context استاندارد:

sudo restorecon -v /path/to/application

SUID جایگزین تنظیم صحیح SELinux نیست.

SUID و AppArmor

در Ubuntu ممکن است AppArmor رفتار برنامه را محدود کند؛ حتی اگر SUID فعال باشد.

بررسی وضعیت:

sudo aa-status

Logهای احتمالی:

sudo journalctl -k | grep -i apparmor

وجود SUID به‌تنهایی تضمین نمی‌کند برنامه بتواند خارج از Policy امنیتی فعالیت کند.

خطرات امنیتی SUID

یک فایل SUID متعلق به root می‌تواند هدف مهمی برای مهاجم باشد.

خطرات رایج:

Command injection
Path hijacking
Unsafe environment variables
Buffer overflow
Race conditions
Insecure temporary files
Arbitrary file overwrite
Untrusted configuration loading
Unsafe library loading
Privilege retention
Shell escape

اگر مهاجم بتواند رفتار یک برنامه SUID را کنترل کند، ممکن است عملیات را با Effective UID مالک فایل انجام دهد.

خطر استفاده از PATH نسبی

یک برنامه SUID نباید Commandها را فقط با نام اجرا کند.

نمونه ناامن:

system("backup-tool");

در این حالت ممکن است برنامه براساس PATH کاربر، Binary اشتباهی را اجرا کند.

روش مناسب‌تر استفاده از مسیر Absolute و حذف وابستگی به Shell است:

/usr/local/sbin/backup-tool

حتی با مسیر Absolute، ورودی‌ها و Environment باید دقیق بررسی شوند.

خطر system() و Shell

استفاده از توابعی که Shell اجرا می‌کنند در برنامه‌های Privileged خطرناک است.

نمونه‌های حساس:

system()
popen()
execlp()
execvp()

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

در برنامه‌های Privileged بهتر است:

• از Shell استفاده نشود.
• Argumentها به‌صورت ثابت و کنترل‌شده باشند.
• مسیر کامل Binary مشخص شود.
• Environment پاک‌سازی شود.
• File Descriptorهای اضافی بسته شوند.
• Privilege در اولین فرصت Drop شود.

فایل SUID نباید قابل‌نوشتن باشد

فایل SUID متعلق به root نباید توسط کاربران معمولی یا گروه غیرقابل‌اعتماد Write شود.

بررسی:

stat -c '%a %A %U %G %n' /path/to/application

نمونه امن‌تر:

4755 -rwsr-xr-x root root /path/to/application

نمونه بسیار خطرناک:

4777 -rwsrwxrwx root root /path/to/application

اگر کاربر بتواند محتوای Binary SUID را تغییر دهد، می‌تواند کد دلخواه را با دسترسی مالک فایل اجرا کند.

بررسی فایل‌های SUID قابل‌نوشتن

پیداکردن فایل‌های SUID که برای Group یا Other قابل‌نوشتن هستند:

sudo find / \
-xdev \
-type f \
-perm -4000 \
\( -perm -0020 -o -perm -0002 \) \
-ls 2>/dev/null

خروجی این دستور باید با حساسیت بررسی شود.

برای مسیرهای محلی:

sudo find /usr/local /opt \
-type f \
-perm -4000 \
\( -perm -0020 -o -perm -0002 \) \
-ls 2>/dev/null

بررسی پوشه‌های والد فایل SUID

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

namei -l /usr/local/libexec/application

نمونه:

f: /usr/local/libexec/application
drwxr-xr-x root root /
drwxr-xr-x root root usr
drwxr-xr-x root root local
drwxr-xr-x root root libexec
-rwsr-xr-x root root application

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

اثر chown روی SUID

تغییر مالکیت یک فایل اجرایی ممکن است باعث پاک‌شدن Bitهای SUID یا SGID شود.

قبل از تغییر:

stat -c '%a %A %U %G %n' application

خروجی:

4755 -rwsr-xr-x root root application

تغییر مالک:

sudo chown ali:developers application

بررسی مجدد:

stat -c '%a %A %U %G %n' application

ممکن است SUID پاک شده باشد. GNU Coreutils نیز اشاره می‌کند که عملیات تغییر مالکیت می‌تواند Bitهای Set-User-ID یا Set-Group-ID را حذف کند.

بعد از هر chown روی فایل Privileged، Permissionها را دوباره بررسی کنید.

اثر chmod روی SUID

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

sudo chmod u-s application

اما در Directoryها، رفتار Modeهای عددی کوتاه ممکن است بسته به پیاده‌سازی در حفظ یا حذف Bitهای ویژه متفاوت باشد. برای تغییر قابل‌پیش‌بینی، Bit ویژه را به‌صورت صریح مشخص کنید.

بررسی همیشه لازم است:

stat -c '%a %A %n' application

SUID روی Directory

در Linux، SUID روی Directory رفتار کاربردی و قابل‌اتکای عمومی مشابه فایل اجرایی ندارد. GNU نیز توضیح می‌دهد که رفتار Set-User-ID روی Directory در سیستم‌های مختلف می‌تواند متفاوت یا نادیده گرفته شود.

برای ارث‌بری گروه در پوشه‌های اشتراکی باید از SGID استفاده شود:

sudo chmod 2770 /srv/developers

برای محدودکردن حذف فایل‌های کاربران دیگر در پوشه عمومی باید از Sticky Bit استفاده شود:

sudo chmod 1777 /srv/shared

تفاوت SUID، SGID و Sticky Bit

نمونه‌ها:

4755 = SUID executable
2755 = SGID executable
2770 = SGID shared directory
1777 = Sticky shared directory

تفاوت SUID با sudo

SUID

• Bit روی فایل اجرایی ثبت می‌شود.
• برای هر اجرای فایل فعال است.
• برنامه باید از ابتدا برای Privileged Execution طراحی شده باشد.
• آسیب‌پذیری Binary می‌تواند خطر جدی ایجاد کند.
• کنترل کاربر و Argumentها داخل خود برنامه انجام می‌شود.

sudo

• دسترسی در فایل sudoers تعریف می‌شود.
• می‌توان کاربر، گروه، Command و Argument را محدود کرد.
• فعالیت‌ها ثبت می‌شوند.
• امکان درخواست رمز وجود دارد.
• Ruleها بدون تغییر Binary قابل مدیریت هستند.

برای بسیاری از وظایف مدیریتی، sudo با Rule محدود انتخاب مناسب‌تری نسبت به ساخت فایل SUID جدید است.

نمونه Rule:

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

تفاوت SUID با Linux Capabilities

در مدل سنتی Unix، Effective UID برابر صفر دسترسی گسترده root ایجاد می‌کند. Linux Capabilities این دسترسی را به مجموعه‌ای از Privilegeهای کوچک‌تر تقسیم می‌کند.

برای مثال، برنامه‌ای که فقط باید روی پورت کمتر از 1024 Listen کند، ممکن است به‌جای SUID root فقط Capability زیر را دریافت کند:

CAP_NET_BIND_SERVICE

بررسی Capability:

getcap /usr/local/bin/myserver

تعریف Capability:

sudo setcap \
'cap_net_bind_service=+ep' \
/usr/local/bin/myserver

بررسی:

getcap /usr/local/bin/myserver

خروجی:

/usr/local/bin/myserver cap_net_bind_service=ep

ابزار setcap برای تنظیم File Capability و getcap برای مشاهده آن استفاده می‌شود.

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

حذف File Capability

sudo setcap -r /usr/local/bin/myserver

بررسی:

getcap /usr/local/bin/myserver

در صورت حذف موفق، خروجی خالی خواهد بود.

بررسی همه File Capabilityها

sudo getcap -r / 2>/dev/null

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

sudo getcap -r /usr /usr/local /opt 2>/dev/null

File Capabilityها نیز مانند SUID باید در Baseline امنیتی ثبت و دوره‌ای بررسی شوند.

انتخاب میان SUID، sudo و Capability

راهنمای کلی:

مانیتورینگ فایل‌های SUID

برای ثبت فهرست همراه با Hash:

sudo find / \
-xdev \
-type f \
-perm -4000 \
-print0 2>/dev/null \
| sudo xargs -0 sha256sum \
> /root/suid-hashes.txt

فایل را محافظت کنید:

sudo chmod 600 /root/suid-hashes.txt

برای بررسی دوره‌ای:

sudo find / \
-xdev \
-type f \
-perm -4000 \
-print0 2>/dev/null \
| sudo xargs -0 sha256sum \
> /root/suid-hashes-current.txt

مقایسه:

diff -u \
/root/suid-hashes.txt \
/root/suid-hashes-current.txt

تغییر Package رسمی پس از Update می‌تواند Hash را تغییر دهد؛ بنابراین هر تفاوت باید با تاریخچه بروزرسانی Packageها مقایسه شود.

بررسی فایل‌های SUID جدید

فایل‌های SUID ایجادشده یا تغییرکرده در روزهای اخیر:

sudo find / \
-xdev \
-type f \
-perm -4000 \
-mtime -7 \
-ls 2>/dev/null

فایل‌های تغییرکرده در 24 ساعت اخیر:

sudo find / \
-xdev \
-type f \
-perm -4000 \
-mtime -1 \
-ls 2>/dev/null

این بررسی به‌تنهایی نشانه آلودگی نیست؛ ممکن است Package Update فایل را تغییر داده باشد.

بررسی Log نصب Packageها

در Ubuntu:

grep -iE 'install|upgrade' \
/var/log/apt/history.log

در AlmaLinux:

sudo dnf history

برای بررسی جزئیات یک Transaction:

sudo dnf history info TRANSACTION_ID

هدف این است که مشخص شود تغییر فایل SUID با نصب یا بروزرسانی معتبر مرتبط بوده است یا خیر.

حذف SUID غیرضروری

قبل از حذف SUID بررسی کنید:

• فایل متعلق به چه Package است؟
• برنامه برای عملکرد صحیح به SUID نیاز دارد؟
• سرویس یا Login به آن وابسته است؟
• جایگزین sudo یا Capability وجود دارد؟
• Vendor چه Permissionی را توصیه کرده است؟

سپس:

sudo chmod u-s /path/to/application

بررسی:

stat -c '%a %A %U %G %n' /path/to/application

بعد از حذف، عملکرد برنامه را آزمایش کنید.

حذف تصادفی SUID از برنامه‌هایی مانند passwd یا sudo می‌تواند عملکرد مدیریتی سیستم را مختل کند.

بازیابی SUID فایل Package

اگر Permission یک فایل Package رسمی اشتباه شده است، ابتدا Package مالک را پیدا کنید.

Ubuntu:

dpkg -S /usr/bin/passwd

AlmaLinux:

rpm -qf /usr/bin/passwd

سپس Permission موردانتظار را از Package رسمی یا یک سیستم سالم هم‌نسخه بررسی کنید.

نصب مجدد Package نیز ممکن است فایل و Permission آن را بازیابی کند.

Ubuntu:

sudo apt install --reinstall passwd

AlmaLinux:

sudo dnf reinstall passwd

قبل از Reinstall، اثر آن روی تنظیمات و سرویس‌ها را بررسی کنید.

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

SUID فعال است اما Effective UID تغییر نمی‌کند

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

stat -c '%a %A %U %G %n' application

خروجی باید شامل SUID باشد:

4755 -rwsr-xr-x root root application

سپس Mount Option را بررسی کنید:

findmnt -T application \
-o TARGET,FSTYPE,OPTIONS

دلایل احتمالی:

Filesystem mounted with nosuid
no_new_privs is enabled
Program is an interpreter script
Process is being traced
SELinux policy denies execution
Container security settings block privilege gain
File owner is not the expected user

فایل با s بزرگ نمایش داده می‌شود

نمونه:

-rwSr-xr-x

مالک فایل Execute ندارد.

اصلاح:

sudo chmod u+x application

یا حذف SUID:

sudo chmod u-s application

chmod u+s خطای Operation not permitted می‌دهد

نمونه:

chmod: changing permissions of 'application': Operation not permitted

دلایل احتمالی:

• کاربر مالک فایل نیست.
• دسترسی root وجود ندارد.
• فایل‌سیستم Read-only است.
• فایل Immutable است.
• فایل روی NFS یا CIFS قرار دارد.
• Container Capability لازم را ندارد.

با sudo آزمایش کنید:

sudo chmod u+s application

بررسی Read-only بودن فایل‌سیستم

findmnt -T application \
-o TARGET,FSTYPE,OPTIONS

وجود گزینه زیر:

ro

نشان‌دهنده Read-only بودن Mount است.

بررسی Immutable Attribute

lsattr application

نمونه:

----i----------------- application

برای حذف موقت:

sudo chattr -i application

پس از تغییر در صورت نیاز:

sudo chattr +i application

فایل SUID اجرا نمی‌شود

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

file application
ldd application
namei -l application
findmnt -T application -o TARGET,FSTYPE,OPTIONS

دلایل احتمالی:

Missing execute permission
Filesystem mounted noexec
Missing dynamic linker or library
Wrong architecture
SELinux or AppArmor denial
Corrupted binary
Invalid interpreter

خطای Permission denied

Permission:

ls -l application

پوشه‌های والد:

namei -l application

Mount Option:

findmnt -T application \
-o TARGET,FSTYPE,OPTIONS

SELinux:

getenforce
sudo ausearch -m AVC -ts recent

SUID بعد از chown ناپدید شده است

این رفتار می‌تواند طبیعی باشد؛ تغییر مالکیت ممکن است Bitهای SUID یا SGID را پاک کند.

بررسی:

stat -c '%a %A %U %G %n' application

فقط اگر برنامه واقعاً به SUID نیاز دارد و امنیت آن تأیید شده است، دوباره فعال کنید:

sudo chmod u+s application

SUID روی Script کار نمی‌کند

Linux SUID روی Interpreter Scriptها را نادیده می‌گیرد.

روش‌های جایگزین:

Restricted sudoers rule
Compiled and audited helper
systemd service
Linux file capability

از ساخت Wrapper ناامن یا SUID Shell برای دورزدن این محدودیت استفاده نکنید.

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

• فقط فایل‌های اجرایی قابل‌اعتماد باید SUID داشته باشند.
• فایل SUID root نباید توسط کاربران معمولی قابل‌نوشتن باشد.
• پوشه‌های والد فایل SUID نباید قابل‌نوشتن باشند.
• فایل‌های SUID را به‌صورت دوره‌ای فهرست کنید.
• از فایل‌های SUID Baseline و Hash تهیه کنید.
• فایل‌های جدید در /tmp، /var/tmp، /opt و /usr/local را بررسی کنید.
• Package مالک هر فایل SUID را مشخص کنید.
• از SUID روی Shell، Interpreter و ابزارهای تعاملی خودداری کنید.
• از SUID روی Scriptها استفاده نکنید.
• برای Commandهای مدیریتی مشخص از sudoers استفاده کنید.
• برای Privilege محدود از Linux Capabilities استفاده کنید.
• روی Mountهای غیرقابل‌اعتماد گزینه nosuid را در نظر بگیرید.
• SELinux و AppArmor را فعال و درست پیکربندی کنید.
• برنامه Privileged باید ورودی‌ها و Environment را پاک‌سازی کند.
• Privilege اضافی باید در اولین فرصت Drop شود.
• بعد از chown و Package Update، Permissionها را دوباره بررسی کنید.
• SUID را بدون بررسی از فایل سیستمی حذف نکنید.
• هر فایل SUID ناشناخته را به‌عنوان مورد امنیتی بررسی کنید.

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

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

• فعال‌کردن SUID روی Shell
• فعال‌کردن SUID روی Script و انتظار اجرای root
• دادن Permission نوشتن به فایل SUID
• قراردادن Binary SUID در پوشه قابل‌نوشتن
• استفاده از 4777
• نادیده‌گرفتن nosuid
• نادیده‌گرفتن no_new_privs
• تصور اینکه SUID همیشه Shell root ایجاد می‌کند
• حذف SUID فایل سیستمی بدون بررسی
• فعال‌کردن SUID روی برنامه دارای ورودی کنترل‌نشده
• استفاده از Commandهای نسبی داخل برنامه Privileged
• استفاده ناامن از system() یا Shell
• بررسی‌نکردن SELinux و AppArmor
• نداشتن Baseline از فایل‌های SUID
• نادیده‌گرفتن File Capabilityها
• بررسی‌نکردن فایل بعد از chown
• استفاده از SUID به‌جای sudoers محدود

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

پس از شناسایی یا تنظیم SUID، موارد زیر را بررسی کنید:

• فایل Regular Executable است.
• مالک فایل صحیح است.
• گروه فایل صحیح است.
• Permission فایل شامل Write برای کاربران غیرمجاز نیست.
• پوشه‌های والد امن هستند.
• فایل متعلق به Package معتبر است.
• Hash یا Package Verification بررسی شده است.
• SUID برای عملکرد برنامه واقعاً لازم است.
• جایگزین sudo یا Capability بررسی شده است.
• فایل‌سیستم با nosuid Mount نشده است.
• فایل‌سیستم با noexec Mount نشده است.
• no_new_privs مانع اجرا نیست.
• SELinux یا AppArmor بررسی شده است.
• فایل Script نیست.
• برنامه Shell Escape ندارد.
• Environment و PATH امن هستند.
• برنامه ورودی کاربر را اعتبارسنجی می‌کند.
• تغییرات در Baseline ثبت شده‌اند.
• عملکرد برنامه با کاربر محدود آزمایش شده است.

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

نمایش Permission:

ls -l application

نمایش عددی:

stat -c '%a %A %U %G %n' application

فعال‌کردن SUID:

sudo chmod u+s application

فعال‌کردن عددی:

sudo chmod 4755 application

حذف SUID:

sudo chmod u-s application

پیداکردن فایل‌های SUID:

sudo find / \
-xdev \
-type f \
-perm -4000 \
-ls 2>/dev/null

پیداکردن SUID و SGID:

sudo find / \
-xdev \
-type f \
-perm /6000 \
-ls 2>/dev/null

بررسی Mount Option:

findmnt -T application \
-o TARGET,FSTYPE,OPTIONS

بررسی Package در Ubuntu:

dpkg -S /path/to/application

بررسی Package در AlmaLinux:

rpm -qf /path/to/application

بررسی Capability:

getcap application

بررسی SELinux:

ls -Z application

جمع‌بندی

SUID یکی از Permissionهای ویژه لینوکس است که باعث می‌شود یک فایل اجرایی با Effective UID مالک فایل اجرا شود.

برای مثال:

File owner: root
Executing user: ali

Real UID: ali
Effective UID: root

SUID با حرف s در محل Execute مالک نمایش داده می‌شود:

-rwsr-xr-x

و مقدار عددی آن معمولاً با رقم 4 آغاز می‌شود:

4755

برای فعال‌سازی:

chmod u+s application

برای حذف:

chmod u-s application

SUID فقط روی برنامه‌های اجرایی طراحی‌شده و بررسی‌شده باید استفاده شود. Linux آن را روی Interpreter Scriptها نادیده می‌گیرد و روی فایل‌سیستم‌های دارای گزینه nosuid نیز اعمال نمی‌کند.

از آنجا که یک آسیب‌پذیری در برنامه SUID root می‌تواند دسترسی گسترده‌ای ایجاد کند، در بسیاری از سناریوها استفاده از sudoers محدود، systemd یا Linux Capabilities انتخاب امن‌تر و قابل‌کنترل‌تری است.