SUDOERS(5) sudo-rs SUDOERS(5)

sudoers - پیکربندی امنیتی سازگار با sudo

خط‌مشی sudo-rs امتیازات sudo کاربر را تعیین می‌کند. این خط‌مشی توسط پرونده /etc/sudoers هدایت می‌شود. قالب خط‌مشی به تفصیل در بخش قالب پرونده SUDOERS شرح داده شده است.

قالب استفاده‌شده توسط sudo-rs زیرمجموعه‌ای از قالبی است که توسط پروژه sudo به نگهداری تاد میلر (Todd Miller) استفاده می‌شود، اما از نظر نحو سازگار است.

خط‌مشی امنیتی sudoers ایجاب می‌کند که بیشتر کاربران پیش از آنکه بتوانند از sudo استفاده کنند، هویت خود را احراز کنند. اگر کاربر فراخواننده root باشد، اگر کاربر هدف همان کاربر فراخواننده باشد، یا اگر خط‌مشی احراز هویت را برای آن کاربر یا دستور غیرفعال کرده باشد، گذرواژه لازم نیست. برخلاف su، هنگامی که sudo-rs نیازمند احراز هویت است، اعتبارنامه‌های کاربر فراخواننده را می‌سنجد، نه اعتبارنامه‌های کاربر هدف (یا root) را. این رفتار می‌تواند از طریق پرچم rootpw که بعداً شرح داده شده است، تغییر یابد.

برنامه sudo-rs برای ذخیره موقت اعتبارنامه‌ها از پرونده‌های مهرزمانی به‌ازای هر کاربر استفاده می‌کند. پس از آنکه کاربری احراز هویت شد، رکوردی نوشته می‌شود شامل شناسه کاربری (user-ID) که برای احراز هویت به کار رفته است، شناسه نشست پایانه، زمان آغاز سرنشست (یا فرایند والد) و یک مهرزمانی (با استفاده از ساعت یکنواخت در صورت در دسترس بودن). کاربر سپس می‌تواند برای مدت کوتاهی بدون گذرواژه از sudo استفاده کند (۱۵ دقیقه مگر آنکه با گزینه timestamp_timeout بازنویسی شود). برنامه sudo-rs برای هر پایانه از رکوردی جداگانه استفاده می‌کند، بدین معنا که نشست‌های ورود کاربر به طور جداگانه احراز هویت می‌شوند.

به‌طور پیش‌فرض، sudo-rs هم تلاش‌های موفق و هم ناموفق (و نیز خطاها) را گزارش می‌کند. پیام‌ها به syslog(3) ارسال می‌شوند.

از آنجا که متغیرهای محیطی می‌توانند بر رفتار برنامه اثر بگذارند، sudo-rs متغیرهایی را که از محیط کاربر توسط دستوری که باید اجرا شود به ارث برده می‌شوند، محدود می‌کند.

در sudo-rs، پرچم env_reset نمی‌تواند غیرفعال شود. این امر موجب می‌شود دستورها با یک محیط جدید و کمینه اجرا شوند. متغیرهای محیطی HOME، SHELL، LOGNAME و USER بر پایه کاربر هدف مقداردهی اولیه می‌شوند و متغیرهای SUDO_* بر پایه کاربر فراخواننده تنظیم می‌گردند. متغیرهای دیگر، مانند DISPLAY، PATH و TERM، در صورتی که گزینه‌های env_check یا env_keep اجازه دهند، از محیط کاربر فراخواننده نگه داشته می‌شوند. با چند متغیر محیطی به شکل ویژه رفتار می‌شود. اگر متغیرهای PATH و TERM از محیط کاربر نگه‌داری نشوند، به مقادیر پیش‌فرض تنظیم خواهند شد. با LOGNAME و USER به عنوان موجودیتی واحد رفتار می‌شود. اگر یکی از آنها از محیط کاربر حفظ شود (یا حذف شود)، دیگری نیز چنین خواهد شد. اگر قرار باشد LOGNAME و USER حفظ شوند اما تنها یکی از آنها در محیط کاربر موجود باشد، دیگری به همان مقدار تنظیم خواهد شد. این کار از ناسازگاری در محیط جلوگیری می‌کند؛ وضعیتی که در آن یکی از متغیرهای توصیف‌کننده نام کاربری روی کاربر فراخواننده و دیگری روی کاربر هدف تنظیم شده باشد. متغیرهای محیطی با مقداری که با () آغاز می‌شود حذف می‌شوند، زیرا ممکن است توسط پوسته bash به عنوان تابع تفسیر شوند.

متغیرهای محیطی مشخص‌شده با env_check یا env_keep ممکن است شامل یک یا چند نویسه `*' باشند که با صفر یا چند نویسه تطابق می‌یابد. هیچ نویسه عام (wildcard) دیگری پشتیبانی نمی‌شود. گزینه‌های دیگر sudoers ممکن است بر محیط دستور اثر بگذارند، مانند secure_path.

متغیرهای محیط PAM ممکن است با محیط ترکیب شوند. اگر متغیری در محیط PAM از قبل در محیط کاربر وجود داشته باشد، مقدار آن تنها در صورتی بازنویسی می‌شود که آن متغیر توسط sudo-rs حفظ نشده باشد. متغیرهای حفظ‌شده از محیط کاربر فراخواننده توسط فهرست env_keep بر متغیرهای موجود در محیط PAM اولویت دارند.

توجه داشته باشید که پیونددهنده پویا در بیشتر سیستم‌عامل‌ها متغیرهایی را که می‌توانند پیوند پویای برنامه‌های set-user-ID (از جمله sudo) را مهار کنند، از محیط حذف می‌کند. بسته به سیستم‌عامل این موارد ممکن است شامل _RLD*، DYLD_*، LD_*، LDR_*، LIBPATH، SHLIB_PATH و موارد دیگر باشد. این دست متغیرها پیش از آنکه حتی اجرای sudo آغاز شود از محیط حذف می‌شوند، و بنابراین امکان نگهداری آنها برای sudo وجود ندارد.

برنامه sudo از روش بومی سیستم‌عامل برای تنظیم محدودیت‌های منابع جهت کاربر هدف استفاده می‌کند. روی سیستم‌های لینوکس، محدودیت‌های منابع معمولاً توسط پیمانه PAM به نام pam_limits.so تنظیم می‌شوند. روی برخی سیستم‌های BSD، پرونده /etc/login.conf محدودیت‌های منابع را برای کاربر مشخص می‌کند. اگر سازوکاری در سیستم برای تنظیم محدودیت‌های منابع به‌ازای هر کاربر نباشد، دستور با همان محدودیت‌های کاربر فراخواننده اجرا خواهد شد.

پرونده sudoers از دو نوع مدخل تشکیل شده است: نام‌های مستعار (اساساً متغیرها) و مشخصات کاربری (که تعیین می‌کنند چه کسی مجاز به اجرای چه چیزی است).

هنگامی که چند مدخل با یک کاربر تطابق یابند، به ترتیب اعمال می‌شوند. در صورت وجود چند تطابق، آخرین تطابق به کار می‌رود (که لزوماً خاص‌ترین تطابق نیست).

دستور زبان پرونده sudoers در ادامه به صورت فرم باکوس-نائور گسترش‌یافته (EBNF) برگرفته از مستندات sudoers تاد میلر شرح داده می‌شود.

فرمت EBNF روشی موجز و دقیق برای توصیف دستور زبان یک زبان است. هر تعریف EBNF از قواعد تولید تشکیل شده است. برای نمونه،

symbol ::= definition | alternate1 | alternate2 ...

هر قاعده تولید به قواعد دیگری ارجاع می‌دهد و بدین ترتیب دستور زبانی برای آن زبان پدید می‌آورد. فرمت EBNF همچنین عملگرهای زیر را دربردارد که بسیاری از خوانندگان از عبارات منظم می‌شناسند. با این حال، آنها را با نویسه‌های “عام” که معانی متفاوتی دارند اشتباه نگیرید.

?     Means that the preceding symbol (or group of symbols) is optional.  That is, it may appear once or not at all.
*     Means that the preceding symbol (or group of symbols) may appear zero or more times.
+     Means that the preceding symbol (or group of symbols) may appear one or more times.

پرانتزها می‌توانند برای گروه‌بندی نمادها با یکدیگر استفاده شوند. برای وضوح، از گیومه‌های تکی (’’) برای نشان دادن رشته نویسه‌ای دقیق (در برابر نام نماد) استفاده می‌کنیم.

چهار گونه نام مستعار وجود دارد: User_Alias، Runas_Alias، Host_Alias و Cmnd_Alias.

Alias ::= 'User_Alias'  User_Alias_Spec (':' User_Alias_Spec)* |
          'Runas_Alias' Runas_Alias_Spec (':' Runas_Alias_Spec)* |
          'Host_Alias'  Host_Alias_Spec (':' Host_Alias_Spec)* |
          'Cmnd_Alias'  Cmnd_Alias_Spec (':' Cmnd_Alias_Spec)* |
          'Cmd_Alias'   Cmnd_Alias_Spec (':' Cmnd_Alias_Spec)*
User_Alias ::= NAME
User_Alias_Spec ::= User_Alias '=' User_List
Runas_Alias ::= NAME
Runas_Alias_Spec ::= Runas_Alias '=' Runas_List
Host_Alias ::= NAME
Host_Alias_Spec ::= Host_Alias '=' Host_List
Cmnd_Alias ::= NAME
Cmnd_Alias_Spec ::= Cmnd_Alias '=' Cmnd_List
NAME ::= [A-Z]([A-Z][0-9]_)*

تعریف هر نام مستعار به صورت زیر است:

Alias_Type NAME = item1, item2, ...

که در آن Alias_Type یکی از User_Alias، Runas_Alias، Host_Alias، یا Cmnd_Alias است. یک NAME رشته‌ای از حروف بزرگ، اعداد و نویسه‌های زیرخط (’_’) است. یک NAME باید با یک حرف بزرگ آغاز شود. امکان قرار دادن چندین تعریف نام مستعار از یک نوع روی یک سطر، با اتصال توسط دونقطه (`:') وجود دارد. برای نمونه،

Alias_Type NAME = item1, item2, item3 : NAME = item4, item5

تعاریف آنچه یک عضو معتبر نام مستعار را تشکیل می‌دهد در پی می‌آید.

User_List ::= User |
              User ',' User_List
User ::= '!'* user name |
         '!'* #user-ID |
         '!'* %group |
         '!'* %#group-ID |
         '!'* User_Alias

یک User_List از یک یا چند نام کاربری، شناسه کاربری (با پیشوند `#')، نام‌های گروه سیستم و شناسه‌های گروه (به ترتیب با پیشوندهای `%' و `%#') و User_Aliasها تشکیل شده است. هر قلم در فهرست می‌تواند با صفر یا چند عملگر `!' پیشوند شود. تعداد فردی از عملگرهای `!' مقدار آن قلم را نفی می‌کنند؛ تعداد زوج صرفاً اثر یکدیگر را خنثی می‌کنند.

Runas_List ::= Runas_Member |
               Runas_Member ',' Runas_List
Runas_Member ::= '!'* user name |
                 '!'* #user-ID |
                 '!'* %group |
                 '!'* %#group-ID |
                 '!'* Runas_Alias

یک Runas_List شبیه به User_List است با این تفاوت که به جای User_Alias می‌تواند Runas_Alias را دربرگیرد. توجه داشته باشید که نام‌های کاربری و گروه‌ها به صورت رشته مطابقت داده می‌شوند. به بیان دیگر، دو کاربر (گروه) با شناسه کاربری (گروه) یکسان، متمایز در نظر گرفته می‌شوند. اگر می‌خواهید تمام نام‌های کاربری با شناسه کاربری یکسان (مانند root و toor) را تطابق دهید، می‌توانید به جای نام از شناسه کاربری (#0 در مثال یادشده) استفاده کنید.

Host_List ::= Host |
              Host ',' Host_List
Host ::= '!'* host name |
         '!'* Host_Alias

یک Host_List از یک یا چند نام میزبان تشکیل می‌شود. باز هم، مقدار یک قلم می‌تواند با عملگر `!' نفی شود.

Cmnd_List ::= Cmnd |
              Cmnd ',' Cmnd_List
command name ::= file name |
                 file name args ['*'] |
                 file name '""'
Cmnd ::= '!'* command name |
         '!'* directory |
         '!'* Cmnd_Alias
         '!'* "list"
         '!'* "sudoedit" [file name]

یک Cmnd_List فهرستی از یک یا چند نام دستور، دایرکتوری و نام‌های مستعار دیگر است. یک نام دستور، یک نام پرونده کاملاً واجد شرایط (مسیر کامل) است که ممکن است شامل نویسه‌های عام سبک پوسته باشد (بخش نویسه‌های عام را در زیر ببینید). یک نام پرونده ساده به کاربر اجازه می‌دهد دستور را با هر آرگومانی که می‌خواهد اجرا کند. با این حال، شما همچنین می‌توانید آرگومان‌های خط فرمانی را تعیین کنید که باید به کار روند؛ در این حالت خط فرمان باید دقیقاً تطابق یابد. می‌توانید از آرگومان ویژه “” استفاده کنید تا نشان دهید دستور تنها می‌تواند بدون آرگومان خط فرمان اجرا شود، یا آرگومان ’*’ برای تطابق با هر آرگومان پایانی. نمی‌توانید از نویسه‌های عام درون فهرست آرگومان‌ها استفاده کنید. یک دایرکتوری، یک مسیر کامل است که به `/' ختم می‌شود. هنگامی که یک دایرکتوری را در Cmnd_List مشخص می‌کنید، کاربر قادر خواهد بود هر پرونده‌ای را درون آن دایرکتوری اجرا کند (اما نه در هیچ‌یک از زیردایرکتوری‌های آن).

اگر یک Cmnd دارای آرگومان‌های خط فرمان وابسته باشد، آنگاه آرگومان‌های موجود در Cmnd باید دقیقاً با آنچه توسط کاربر در خط فرمان داده شده تطابق داشته باشند. توجه داشته باشید که نویسه‌های زیر در صورت استفاده در آرگومان‌های دستور باید با `\' فرار (escape) داده شوند: `,', `:', `=', `\'.

دو دستور توکار در درون خود sudo وجود دارند: “list” و “sudoedit”. برخلاف سایر دستورها، این دو باید بدون مسیر اولیه در پرونده sudoers مشخص شوند.

دستور توکار “list” می‌تواند برای اجازه دادن به یک کاربر جهت فهرست کردن امتیازات کاربر دیگر با گزینه -U در sudo استفاده شود. برای نمونه، “sudo -l -U otheruser”. کاربری با امتیاز “list” قادر است امتیازات کاربر دیگری را فهرست کند حتی اگر اجازه اجرای دستورها به عنوان آن کاربر را نداشته باشد. به‌طور پیش‌فرض، تنها root یا کاربری با قابلیت اجرای هر دستوری به عنوان root یا کاربر مشخص‌شده روی میزبان جاری می‌تواند از گزینه -U استفاده کند. هیچ آرگومان خط فرمانی نمی‌تواند با دستور توکار “list” مشخص شود.

دستور توکار “sudoedit” برای اجازه دادن به کاربر جهت اجرای sudo با گزینه -e (یا به صورت sudoedit) استفاده می‌شود. این دستور می‌تواند درست مانند یک دستور عادی آرگومان‌های خط فرمان دریافت کند. برخلاف سایر دستورها، “sudoedit” درون خود sudo تعبیه شده است و باید بدون مسیر اولیه در پرونده sudoers مشخص شود. اگر یک مسیر اولیه وجود داشته باشد، برای نمونه /usr/bin/sudoedit، این کار به کاربر مجوز استفاده از sudoedit را نخواهد داد. اگر هیچ آرگومانی ارائه نشود، “sudoedit” به کاربر مجوز ویرایش هر پرونده‌ای را می‌دهد؛ اگر آرگومانی حاضر باشد، باید یک مسیر مطلق باشد که حاوی پیوندهای نمادین نباشد، وگرنه دستور تطابق داده نخواهد شد.

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

Default_Type ::= 'Defaults' |
                 'Defaults' '@' Host_List |
                 'Defaults' ':' User_List |
                 'Defaults' '!' Cmnd_List |
                 'Defaults' '>' Runas_List
Default_Entry ::= Default_Type Parameter_List
Parameter_List ::= Parameter |
                   Parameter ',' Parameter_List
Parameter ::= Parameter '=' Value |
              Parameter '+=' Value |
              Parameter '-=' Value |
              '!'* Parameter

پارامترها می‌توانند پرچم‌ها، مقادیر عددی صحیح، رشته‌ها، یا فهرست‌ها باشند. پرچم‌ها به طور ضمنی بولی هستند و می‌توانند از طریق عملگر `!' خاموش شوند. برخی پارامترهای عددی صحیح، رشته‌ای و فهرستی نیز ممکن است در زمینه بولی برای غیرفعال کردن آنها به کار روند. مقادیر در صورت دربرداشتن چندین کلمه می‌توانند در گیومه دوتایی (““) قرار گیرند. نویسه‌های ویژه را می‌توان با یک ممیز وارونه (`\') فرار داد.

برای گنجاندن نویسه ممیز وارونه دقیق در یک آرگومان خط فرمان باید ممیز وارونه را دو بار فرار دهید. برای نمونه، برای تطابق `\n' به عنوان بخشی از آرگومان خط فرمان، باید از `\\\\n' در پرونده sudoers استفاده کنید. این به دلیل وجود دو سطح فراردهی است، یکی در تجزیه‌گر sudoers به خودی خود و دیگری زمانی که آرگومان‌های خط فرمان توسط تابع fnmatch(3) تطابق داده می‌شوند.

فهرست‌ها دارای دو عملگر انتساب اضافی هستند، += و -=. این عملگرها به ترتیب برای افزودن به یک فهرست و حذف از آن به کار می‌روند. استفاده از عملگر -= برای حذف عنصری که در یک فهرست وجود ندارد، خطا نیست.

مدخل‌های پیش‌فرض به ترتیب زیر تجزیه می‌شوند: پیش‌فرض‌های عمومی، میزبان، کاربر، و runas به ترتیبی که ظاهر می‌شوند پردازش می‌گردند، و پیش‌فرض‌های به‌ازای هر دستور در گام دوم پس از آن پردازش می‌شوند.

برای فهرستی از پارامترهای پشتیبانی‌شده Defaults، بخش گزینه‌های SUDOERS را ببینید.

User_Spec ::= User_List Host_List '=' Cmnd_Spec_List \
              (':' Host_List '=' Cmnd_Spec_List)*
Cmnd_Spec_List ::= Cmnd_Spec |
                   Cmnd_Spec ',' Cmnd_Spec_List
Cmnd_Spec ::= Runas_Spec? Chdir_Spec? Tag_Spec* Cmnd
Runas_Spec ::= '(' Runas_List? (':' Runas_List)? ')'
Chdir_Spec ::= 'CWD=directory'
Tag_Spec ::= ('PASSWD:' | 'NOPASSWD:' |
              'SETENV:' | 'NOSETENV:'
              'EXEC:'   | 'NOEXEC')
AppArmor_Spec ::= 'APPARMOR_PROFILE=profile'

یک مشخصه کاربر تعیین می‌کند که یک کاربر مجاز به اجرای چه دستورهایی (و به عنوان چه کاربری) روی میزبان‌های مشخص‌شده است. به‌طور پیش‌فرض، دستورها به عنوان root اجرا می‌شوند، اما این رفتار می‌تواند به‌ازای هر دستور تغییر یابد.

ساختار پایه یک مشخصه کاربر چنین است: “who where = (as_whom) what” (چه کسی در کجا = (به‌عنوان چه کسی) چه چیزی). بیایید آن را به بخش‌های تشکیل‌دهنده‌اش تفکیک کنیم:

یک Runas_Spec کاربر و/یا گروهی را که یک دستور ممکن است به عنوان آن اجرا شود، تعیین می‌کند. یک Runas_Spec کامل شامل دو Runas_List (همان‌طور که در بالا تعریف شد) است که با یک دونقطه (`:') از هم جدا شده و در یک جفت پرانتز محصور شده‌اند. نخستین Runas_List مشخص می‌کند که دستور از طریق گزینه -u می‌تواند به عنوان چه کاربرانی اجرا شود. دومین مورد فهرستی از گروه‌ها را تعریف می‌کند که ممکن است از طریق گزینه -g مشخص شوند (افزون بر هریک از گروه‌های کاربر هدف). اگر هر دو Runas_List مشخص شده باشند، دستور می‌تواند با هر ترکیبی از کاربران و گروه‌های فهرست‌شده در Runas_List مربوط به خودشان اجرا شود. اگر تنها مورد نخست مشخص شده باشد، دستور می‌تواند به عنوان هر کاربری در فهرست و به صورت اختیاری با هر گروهی که کاربر هدف به آن تعلق دارد اجرا شود. اگر نخستین Runas_List خالی باشد اما دومی مشخص شده باشد، دستور می‌تواند به عنوان کاربر فراخواننده با گروهی تنظیم‌شده روی هریک از موارد فهرست‌شده در Runas_List اجرا شود. اگر هر دو Runas_List خالی باشند، دستور تنها می‌تواند به عنوان کاربر فراخواننده اجرا شود و گروه، در صورت تعیین شدن، باید گروهی باشد که کاربر فراخواننده عضوی از آن است. اگر هیچ Runas_Specای مشخص نشده باشد، دستور تنها می‌تواند به عنوان root اجرا شود و گروه، در صورت تعیین شدن، باید گروهی باشد که root عضوی از آن است.

یک Runas_Spec پیش‌فرضی برای دستورهای پس از خود تعیین می‌کند. معنای این امر آن است که برای مدخل زیر:

dgb     boulder = (operator) /bin/ls, /bin/kill, /usr/bin/lprm

کاربر dgb می‌تواند /bin/ls، /bin/kill و /usr/bin/lprm را روی میزبان boulder اجرا کند—اما تنها به عنوان operator. برای نمونه،

$ sudo -u operator /bin/ls

همچنین می‌توان یک Runas_Spec را بعداً در یک مدخل بازنویسی کرد. اگر مدخل را بدین‌گونه تغییر دهیم:

dgb     boulder = (operator) /bin/ls, (root) /bin/kill, /usr/bin/lprm

آنگاه کاربر dgb اکنون مجاز است /bin/ls را به عنوان operator، اما /bin/kill و /usr/bin/lprm را به عنوان root اجرا کند.

می‌توانیم این را گسترش دهیم تا به dgb اجازه دهیم /bin/ls را با کاربر یا گروه تنظیم‌شده روی operator اجرا کند:

dgb     boulder = (operator : operator) /bin/ls, (root) /bin/kill,\
        /usr/bin/lprm

توجه داشته باشید که در حالی که بخش گروه در Runas_Spec به کاربر اجازه می‌دهد دستوری را با آن گروه اجرا کند، کاربر را وادار به این کار نمی‌کند. اگر هیچ گروهی در خط فرمان مشخص نشود، دستور با گروه فهرست‌شده در مدخل پایگاه داده گذرواژه کاربر هدف اجرا خواهد شد. موارد زیر همگی توسط مدخل sudoers بالا مجاز خواهند بود:

$ sudo -u operator /bin/ls
$ sudo -u operator -g operator /bin/ls
$ sudo -g operator /bin/ls

در نمونه زیر، کاربر tcm می‌تواند دستورهایی را اجرا کند که به یک پرونده دستگاه مودم با گروه dialer دسترسی دارند:

tcm     boulder = (:dialer) /usr/bin/tip, /usr/bin/cu,\
        /usr/local/bin/minicom

توجه داشته باشید که در این نمونه تنها گروه تنظیم خواهد شد، و دستور همچنان به عنوان کاربر tcm اجرا می‌شود. برای نمونه:

$ sudo -g dialer /usr/bin/cu

چندین کاربر و گروه می‌توانند در یک Runas_Spec حاضر باشند، که در این حالت کاربر می‌تواند هر ترکیبی از کاربران و گروه‌ها را از طریق گزینه‌های -u و -g برگزیند. در این نمونه:

alan    ALL = (root, bin : operator, system) ALL

کاربر alan می‌تواند هر دستوری را به عنوان کاربر root یا bin اجرا کند، و به صورت اختیاری گروه را روی operator یا system تنظیم نماید.

دایرکتوری کاری که دستور در آن اجرا خواهد شد می‌تواند با استفاده از تنظیم CWD مشخص شود. دایرکتوری باید یک مسیر کامل باشد که با یک نویسه `/' یا `~' آغاز می‌شود، یا مقدار ویژه “*”. مقدار “*” نشان می‌دهد که کاربر می‌تواند با اجرای sudo به همراه گزینه -D دایرکتوری کاری را تعیین کند. به‌طور پیش‌فرض، دستورها از دایرکتوری کاری جاری کاربر فراخواننده اجرا می‌شوند، مگر آنکه گزینه -i داده شده باشد. نام‌های مسیر به شکل ~user/path/name به صورت نسبی نسبت به دایرکتوری خانگی کاربر نام‌برده تفسیر می‌شوند. اگر نام کاربر حذف شود، مسیر نسبت به دایرکتوری خانگی کاربر runas خواهد بود.

یک دستور می‌تواند صفر یا چند برچسب وابسته به خود داشته باشد. مقادیر برچسب‌های زیر پشتیبانی می‌شوند: PASSWD، NOPASSWD، SETENV، و NOSETENV. هنگامی که یک برچسب روی یک Cmnd تنظیم شد، Cmndهای بعدی در Cmnd_Spec_List آن برچسب را به ارث می‌برند مگر آنکه با برچسب متضاد بازنویسی شود (به عبارت دیگر، PASSWD بر NOPASSWD و NOSETENV بر SETENV غلبه می‌کند).

روی سیستم‌های لینوکس، برچسب NOEXEC می‌تواند برای جلوگیری از اجرای دستورهای بیشتر توسط یک برنامه اجرایی به کار رود.

در نمونه زیر، کاربر aaron مجاز به اجرای /usr/bin/more و /usr/bin/vi است اما فرارهای پوسته (shell escapes) غیرفعال خواهند بود.

aaron   shanty = NOEXEC: /usr/bin/more, /usr/bin/vi

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

به‌طور پیش‌فرض، sudo ایجاب می‌کند که کاربر پیش از اجرای یک دستور احراز هویت کند. این رفتار می‌تواند از طریق برچسب NOPASSWD تغییر یابد. مانند Runas_Spec، برچسب NOPASSWD یک پیش‌فرض برای دستورهای پس از خود در Cmnd_Spec_List تعیین می‌کند. برعکس، برچسب PASSWD می‌تواند برای معکوس کردن این حالت به کار رود. برای نمونه:

queen     rushmore = NOPASSWD: /bin/kill, /bin/ls, /usr/bin/lprm

به کاربر queen اجازه می‌دهد /bin/kill، /bin/ls، و /usr/bin/lprm را به عنوان root روی ماشین “rushmore” بدون احراز هویت خود اجرا کند. اگر تنها بخواهیم queen بتواند /bin/kill را بدون گذرواژه اجرا کند، مدخل چنین خواهد بود:

queen     rushmore = NOPASSWD: /bin/kill, PASSWD: /bin/ls, /usr/bin/lprm

به‌طور پیش‌فرض، اگر برچسب NOPASSWD برای هریک از مدخل‌های کاربر برای میزبان جاری اعمال شود، کاربر قادر خواهد بود “sudo -l” را بدون گذرواژه اجرا کند. افزون بر این، کاربر تنها در صورتی می‌تواند “sudo -v” را بدون گذرواژه اجرا کند که همه مدخل‌های کاربر برای میزبان جاری دارای برچسب NOPASSWD باشند.

این برچسب‌ها مقدار پرچم setenv را به‌ازای هر دستور بازنویسی می‌کنند. توجه داشته باشید که اگر SETENV برای یک دستور تنظیم شده باشد، کاربر می‌تواند پرچم env_reset را از خط فرمان از طریق گزینه -E غیرفعال کند. افزون بر این، متغیرهای محیطی تنظیم‌شده در خط فرمان مشمول محدودیت‌های اعمال‌شده توسط env_check، env_delete، یا env_keep نیستند. بدین سبب، تنها کاربران مورد اعتماد باید مجاز باشند متغیرها را بدین شیوه تنظیم کنند. اگر دستور مطابقت‌یافته ALL باشد، برچسب SETENV برای آن دستور به طور ضمنی در نظر گرفته می‌شود؛ این پیش‌فرض می‌تواند با استفاده از برچسب NOSETENV بازنویسی شود.

هنگامی که sudo-rs با پشتیبانی از AppArmor ساخته شود، مدخل‌های پرونده sudoers می‌توانند یک نمایه (profile) AppArmor را مشخص کنند که باید برای محدودسازی یک دستور به کار رود.

اگر یک نمایه AppArmor با دستور مشخص شود، مقادیر پیش‌فرض تعیین‌شده در sudoers را بازنویسی خواهد کرد. قواعد گذار نمایه مناسب باید برای پشتیبانی از تغییر نمایه مشخص‌شده برای یک کاربر تعریف شده باشند.

نمایه‌های AppArmor می‌توانند به هر روشی که با قوانین aa_change_profile(2) سازگار باشد مشخص شوند.

برنامه sudo اجازه می‌دهد نویسه‌های عام سبک پوسته (معروف به نویسه‌های meta یا glob) در نام‌های میزبان، مسیرها، و آرگومان‌های خط فرمان در پرونده sudoers استفاده شوند. تطابق نویسه‌های عام از طریق توابع glob(3) و fnmatch(3) مطابق با استاندارد IEEE Std 1003.1 (“POSIX.1”) انجام می‌شود.

*         Matches any set of zero or more characters (including white space).
?         Matches any single character (including white space).
[...]     Matches any character in the specified range.
[!...]    Matches any character not in the specified range.
\x        For any character ‘x’, evaluates to ‘x’.  This is used to escape special characters such as: ‘*’, ‘?’, ‘[’, and ‘]’.

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

نویسه‌های عام در آرگومان‌های خط فرمان پشتیبانی نمی‌شوند—استفاده از آنها در نسخه‌های اصلی sudo معمولاً نشانه‌ای از پیکربندی نادرست بود و در نتیجه sudo-rs صرفاً استفاده از آنها را منع می‌کند. تنها کاربرد پشتیبانی‌شده، ’*’ به عنوان آرگومان پایانی برای نشان دادن “صفر یا چند آرگومان بعدی” است، همان‌گونه که در بالا ذکر شد.

امکان گنجاندن سایر پرونده‌های sudoers از درون پرونده sudoers در حال تجزیه، با استفاده از رهنمودهای @include و @includedir وجود دارد؛ یا محتوای ارائه‌شده توسط یک برنامه کاربردی از طریق یک سوکت دامنه یونیکس با رهنمود @socket. برای سازگاری با نگارش‌های پیش از 1.9.1 برنامه sudo تاد میلر، #include و #includedir نیز پذیرفته می‌شوند.

یک پرونده شامل‌شده (include file) می‌تواند برای نمونه جهت نگهداری یک پرونده سراسری sudoers افزون بر یک پرونده محلی به‌ازای هر ماشین به کار رود. برای این مثال، پرونده سراسری /etc/sudoers و پرونده محلی ماشین /etc/sudoers.local خواهد بود. برای گنجاندن /etc/sudoers.local از درون /etc/sudoers می‌توان از سطر زیر در /etc/sudoers استفاده کرد:

@include /etc/sudoers.local

هنگامی که sudo به این سطر می‌رسد، پردازش پرونده جاری (/etc/sudoers) را به حالت تعلیق درمی‌آورد و به /etc/sudoers.local تغییر وضعیت می‌دهد. پس از رسیدن به پایان /etc/sudoers.local، بقیه /etc/sudoers پردازش خواهد شد. پرونده‌هایی که گنجانده می‌شوند می‌توانند خود پرونده‌های دیگری را بگنجانند. یک حد سخت‌گیرانه ۱۲۸ پرونده تودرتو برای جلوگیری از حلقه‌های گنجاندن اعمال می‌شود.

مسیر پرونده شامل‌شده ممکن است شامل فاصله‌های خالی باشد در صورتی که با ممیز وارونه (`\') فرار داده شود. متناوباً، کل مسیر می‌تواند در گیومه دوتایی (““) قرار گیرد، که در این حالت فراردهی لازم نیست. برای گنجاندن ممیز وارونه دقیق در مسیر، باید از `\\' استفاده شود. اگر مسیر پرونده شامل‌شده کامل نباشد (با `/' آغاز نشود)، باید در همان دایرکتوری پرونده sudoers که از آن گنجانده شده قرار داشته باشد. برای نمونه اگر /etc/sudoers شامل سطر زیر باشد:

@include sudoers.local

رهنمود @includedir می‌تواند برای ایجاد یک دایرکتوری sudoers.d استفاده شود تا مدیر بسته‌های سیستم بتواند قواعد پرونده sudoers را به عنوان بخشی از نصب بسته در آن قرار دهد. برای نمونه با داشتن:

@includedir /etc/sudoers.d

برنامه sudo پردازش پرونده جاری را معلق کرده و هر پرونده درون /etc/sudoers.d را می‌خواند، و نام پرونده‌هایی را که به `~' ختم می‌شوند یا شامل نویسه `.' هستند نادیده می‌گیرد تا از ایجاد مشکل در پرونده‌های موقت یا پشتیبان مدیر بسته یا ویرایشگر جلوگیری شود. پرونده‌ها به ترتیب الفبایی مرتب‌شده تجزیه می‌شوند. بدین معنا که /etc/sudoers.d/01_first پیش از /etc/sudoers.d/10_second تجزیه خواهد شد. توجه داشته باشید از آنجا که مرتب‌سازی الفبایی است نه عددی، /etc/sudoers.d/1_whoops پس از /etc/sudoers.d/10_second بارگذاری می‌شود. استفاده از تعداد ثابتی از صفرهای آغازین در نام پرونده‌ها می‌تواند برای جلوگیری از چنین مشکلاتی به کار رود. پس از تجزیه پرونده‌های درون دایرکتوری، کنترل به پرونده‌ای بازمی‌گردد که حاوی رهنمود @includedir بوده است.

توجه داشته باشید که برخلاف پرونده‌های گنجانده‌شده با @include، ابزار visudo پرونده‌های درون یک دایرکتوری @includedir را ویرایش نخواهد کرد مگر آنکه یکی از آنها حاوی خطای نحوی باشد. هنوز امکان اجرای visudo با پرچم -f برای ویرایش مستقیم پرونده‌ها وجود دارد، اما این کار تعریف دوباره یک نام مستعار را که در پرونده دیگری نیز وجود دارد آشکار نخواهد کرد.

هنگام مدیریت قواعد گسترده سازمانی sudoers، گاهی ترجیح داده می‌شود آنها در یک مخزن متمرکز ذخیره شوند. رهنمود @socket می‌تواند برای گنجاندن محتوای ارائه‌شده توسط یک برنامه سرور روی یک سوکت دامنه یونیکس به کار رود. برای نمونه، ارائه:

@socket (sssd:sssd) /var/run/providers/sudoers.socket

باعث می‌شود sudo آن سوکت را باز کند، قواعد را بخواند و آن را ببندد، درست مانند یک پرونده شامل‌شده. قواعد باید از همان نحوی پیروی کنند که در پرونده‌های sudoers استفاده می‌شود. با این حال یک استثنا وجود دارد: هنگام خواندن از یک سوکت، رهنمودهای @include، @includedir، و @socket پذیرفته نمی‌شوند.

به دلایل امنیتی، یک کاربر و به صورت اختیاری یک گروه باید ارائه شود که درون پرانتز محصور شده و با دونقطه از هم جدا شده باشند. کاربران و گروه‌ها می‌توانند با نام خود یا با شناسه عددی خود با پیشوند علامت هش (#) مشخص شوند. هنگامی که سوکت باز می‌شود، و پیش از هرگونه تعامل با آن، sudo بررسی می‌کند که فرایند همتا در طرف دیگر سوکت به عنوان کاربر و گروه اعلام‌شده (در صورت ارائه دومی) اجرا می‌شود. اگر هریک از این شرایط نقض شود، سوکت فوراً بسته شده و دور انداخته می‌شود. تنها گروه‌های POSIX می‌توانند استفاده شوند.

لطفاً توجه داشته باشید که visudo نمی‌تواند از یک سوکت بخواند. افزون بر این، محتوای بازیابی‌شده از یک سوکت توسط sudo تغییرناپذیر در نظر گرفته می‌شود.

علامت هش (`#') برای نشان دادن توضیح به کار می‌رود (مگر آنکه بخشی از یک رهنمود #include باشد یا در زمینه نام کاربری رخ دهد و به دنبال آن یک یا چند رقم بیاید، که در این صورت به عنوان شناسه کاربری تلقی می‌شود). هم نویسه توضیح و هم هر متنی پس از آن تا پایان سطر، نادیده گرفته می‌شوند.

واژه کلیدی رزروشده ALL یک نام مستعار توکار است که همیشه باعث تطابق موفق می‌شود. این واژه می‌تواند هر جا که معمولاً از یک Cmnd_Alias، User_Alias، Runas_Alias، یا Host_Alias استفاده می‌شود، به کار رود. تلاش برای تعریف یک نام مستعار با نام ALL منجر به خطای نحوی خواهد شد. لطفاً توجه داشته باشید که استفاده از ALL می‌تواند خطرناک باشد زیرا در زمینه دستور، به کاربر اجازه می‌دهد هر دستوری را روی سیستم اجرا کند.

یک علامت تعجب (`!') می‌تواند به عنوان یک عملگر نقیض منطقی (NOT) در یک فهرست یا نام مستعار و همچنین در جلوی یک Cmnd به کار رود. این امکان نفی مقادیر معینی را فراهم می‌کند. برای اینکه عملگر `!' مؤثر واقع شود، باید چیزی برای حذف کردن وجود داشته باشد. برای نمونه، برای تطابق همه کاربران به جز root باید چنین نوشت:

ALL,!root

اگر ALL, حذف شود، همانند:

!root

صریحاً root را نفی می‌کند اما با هیچ کاربر دیگری تطابق نخواهد یافت. این با یک عملگر “نفی” واقعی تفاوت دارد.

با این حال توجه داشته باشید که استفاده از یک `!' همراه با نام مستعار توکار ALL جهت اجازه دادن به یک کاربر برای اجرای “همه به جز چند دستور معدود” به ندرت مطابق انتظار عمل می‌کند (بخش نکات امنیتی را در زیر ببینید).

فاصله خالی میان عناصر در یک فهرست و همچنین نویسه‌های نحوی ویژه در مشخصات کاربر (`=', `:', `(', `)') اختیاری است.

نویسه‌های زیر در صورت استفاده به عنوان بخشی از یک کلمه (برای نمونه، یک نام کاربری یا نام میزبان) باید با ممیز وارونه (`\') فرار داده شوند: `!', `=', `:', `,', `(', `)', `\'.

رفتار sudo می‌تواند با سطرهای Default_Entry تغییر یابد، همان‌طور که پیش‌تر توضیح داده شد. فهرستی از تمام پارامترهای پشتیبانی‌شده Defaults، گروه‌بندی‌شده بر پایه نوع، در زیر آورده شده است.

•
log_allowed

در صورت تنظیم، sudoers دستورهای مجازشده توسط خط‌مشی را در گزارش سیستم (syslog) ثبت می‌کند. این پرچم به طور پیش‌فرض روشن است.

•
noexec

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

•
noninteractive_auth

در صورت تنظیم، احراز هویت حتی در حالت غیرتعاملی (هنگامی که گزینه -n در sudo مشخص شده باشد) تلاش خواهد شد. این امر به روش‌های احراز هویتی که نیازی به تعامل کاربر ندارند امکان موفقیت می‌دهد. روش‌های احراز هویتی که به ورودی از پایانه کاربر نیاز دارند همچنان با شکست روبرو می‌شوند. در صورت غیرفعال بودن، تلاشی برای احراز هویت در حالت غیرتعاملی صورت نخواهد گرفت. این پرچم به طور پیش‌فرض خاموش است.

•
env_editor

در صورت تنظیم، visudo پیش از بازگشت به فهرست پیش‌فرض ویرایشگرها، از مقدار متغیرهای محیطی SUDO_EDITOR، VISUAL یا EDITOR استفاده خواهد کرد. توجه داشته باشید که visudo معمولاً به عنوان root اجرا می‌شود، بنابراین این پرچم ممکن است به کاربری با امتیازات visudo اجازه دهد دستورهای دلخواه را به عنوان root بدون ثبت گزارش اجرا کند. یک راه‌حل جایگزین، قرار دادن فهرستی از ویرایشگرهای “امن” جداشده با دونقطه در تنظیم editor است. در این صورت visudo تنها زمانی از SUDO_EDITOR، VISUAL یا EDITOR استفاده خواهد کرد که با مقداری مشخص‌شده در editor مطابقت داشته باشند. اگر پرچم env_reset فعال باشد، متغیرهای محیطی SUDO_EDITOR، VISUAL و/یا EDITOR باید در فهرست env_keep حاضر باشند تا پرچم env_editor هنگام فراخوانی visudo از طریق sudo عمل کند. این پرچم به طور پیش‌فرض روشن است.

•
pwfeedback

به‌طور پیش‌فرض، sudo مانند بیشتر برنامه‌های دیگر یونیکس، با خاموش کردن بازتاب کلیدها تا زمان فشردن کلید return (یا enter) گذرواژه را می‌خواند. برخی کاربران از این موضوع سردرگم می‌شوند زیرا به نظرشان می‌رسد که sudo در این نقطه متوقف شده است. هنگامی که pwfeedback تنظیم شود، sudo با فشردن هر کلید توسط کاربر بازخورد دیداری ارائه می‌دهد. بازخورد همیشه می‌تواند با استفاده از کلید TAB خاموش شود. این پرچم به طور پیش‌فرض روشن است.

•
rootpw

در صورت تنظیم، sudo هنگام اجرای یک دستور یا ویرایش یک پرونده، به جای گذرواژه کاربر فراخواننده، گذرواژه root را درخواست خواهد کرد. این پرچم به طور پیش‌فرض خاموش است.

•
setenv

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

•
targetpw

در صورت تنظیم، sudo هنگام اجرای یک دستور یا ویرایش یک پرونده، به جای گذرواژه کاربر فراخواننده، گذرواژه کاربر مشخص‌شده با گزینه -u (پیش‌فرض root) را درخواست خواهد کرد. توجه داشته باشید که این پرچم مانع از استفاده از شناسه کاربری (user-ID) فهرست‌نشده در پایگاه داده passwd به عنوان آرگومان گزینه -u می‌شود. این پرچم به طور پیش‌فرض خاموش است.

•
umask_override

در صورت تنظیم، sudo ماسک umask را دقیقاً مطابق با آنچه در پرونده sudoers مشخص شده بدون تغییر تنظیم می‌کند. این امر تعیین umaskای در پرونده sudoers را که مجازتر از umask خود کاربر باشد ممکن می‌سازد. اگر umask_override تنظیم نشود، sudo ماسک umask را به عنوان اجتماع umask کاربر و آنچه در sudoers مشخص شده تنظیم خواهد کرد. این پرچم به طور پیش‌فرض خاموش است.

•
use_pty

در صورت تنظیم، و اگر sudo در یک پایانه در حال اجرا باشد، دستور در یک پایانه مجازی (pseudo-terminal) اجرا خواهد شد (حتی اگر هیچ ثبت ورودی/خروجی انجام نشود). اگر فرایند sudo به پایانه‌ای متصل نباشد، use_pty هیچ اثری ندارد.

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

•
passwd_tries

تعداد دفعاتی که به کاربر برای وارد کردن گذرواژه‌اش فرصت داده می‌شود پیش از آنکه sudo شکست را ثبت کرده و خارج شود. پیش‌فرض ۳ است.

•
timestamp_timeout

تعداد دقایقی که می‌تواند سپری شود پیش از آنکه sudo دوباره درخواست گذرواژه کند. اگر دقت دقیقه‌ای کافی نباشد، مهلت می‌تواند شامل یک بخش اعشاری باشد، برای نمونه ۲.۵. پیش‌فرض ۱۵ است. این مقدار را روی ۰ قرار دهید تا همیشه درخواست گذرواژه شود.

•
umask

ماسک ایجاد حالت پرونده برای استفاده هنگام اجرای دستور. این گزینه را نفی کنید یا آن را روی 0777 بگذارید تا از تغییر umask توسط sudo جلوگیری شود. مگر اینکه پرچم umask_override تنظیم شده باشد، مقدار واقعی umask اجتماع umask کاربر و مقدار تنظیم umask خواهد بود که پیش‌فرض آن 0022 است. این تضمین می‌کند که sudo هنگام اجرای یک دستور هرگز umask را پایین‌تر نمی‌آورد.

اگر umask صریحاً تنظیم شود، هرگونه تنظیم umask در PAM را بازنویسی خواهد کرد. اگر umask تنظیم نشود، umask مشخص‌شده توسط PAM اولویت خواهد داشت. تنظیم umask در PAM برای sudoedit که نشست جدید PAM ایجاد نمی‌کند، استفاده نمی‌شود.

•
editor

فهرستی از مسیرهای ویرایشگرها جداشده با دونقطه (`:') که توسط sudoedit و visudo به کار می‌رود. برای sudoedit، این فهرست برای یافتن ویرایشگری استفاده می‌شود که هیچ‌یک از متغیرهای محیطی SUDO_EDITOR، VISUAL یا EDITOR به ویرایشگری که موجود و قابل اجرا باشد تنظیم نشده باشند. برای visudo، به عنوان فهرست مجاز ویرایشگرها به کار می‌رود؛ visudo در صورت امکان ویرایشگری را انتخاب می‌کند که با متغیرهای محیطی SUDO_EDITOR، VISUAL یا EDITOR کاربر مطابقت داشته باشد، یا در غیر این صورت نخستین ویرایشگر موجود و قابل اجرا در فهرست را برمی‌گزیند. مگر اینکه به صورت sudoedit فراخوانی شود، sudo متغیرهای محیطی SUDO_EDITOR، VISUAL یا EDITOR را حفظ نمی‌کند مگر اینکه در فهرست env_keep حاضر باشند. پیش‌فرض در لینوکس /usr/bin/editor:/usr/bin/nano:/usr/bin/vi است. روی FreeBSD پیش‌فرض /usr/bin/vi است.

•
timestamp_type

برنامه sudo-rs از پرونده‌های مهرزمانی به‌ازای هر کاربر برای ذخیره موقت اعتبارنامه‌ها استفاده می‌کند. گزینه timestamp_type می‌تواند برای تعیین نوع رکورد مهرزمانی استفاده شود. این گزینه دو مقدار ممکن دارد: tty و ppid. هیچ پشتیبانی از تنظیمات global یا kernel وجود ندارد.

•
ppid: یک رکورد مهرزمانی واحد برای همه فرایندهایی با شناسه فرایند والد (معمولاً پوسته) یکسان استفاده می‌شود. دستورهای اجراشده از همان پوسته (یا فرایند والد مشترک دیگر) تا زمانی که مهرزمانی معتبر است نیازی به گذرواژه نخواهند داشت (به timestamp_timeout مراجعه کنید). دستورهای اجراشده از طریق sudo با شناسه فرایند والد متفاوت، مثلاً از یک اسکریپت پوسته، باید جداگانه احراز هویت شوند.
•
tty: یک رکورد مهرزمانی برای هر پایانه استفاده می‌شود، به این معنی که نشست‌های ورود یک کاربر به طور جداگانه احراز هویت می‌شوند. اگر پایانه‌ای وجود نداشته باشد، رفتار مانند ppid است. دستورهای اجراشده از همان پایانه تا زمانی که مهرزمانی معتبر است نیازی به گذرواژه نخواهند داشت.

مقدار پیش‌فرض tty است.

•
apparmor_profile

نمایه پیش‌فرض AppArmor برای گذار به آن هنگام اجرای یک دستور. مقدار پیش‌فرض apparmor_profile می‌تواند برای هریک از مدخل‌های منفرد sudoers با مشخص کردن گزینه APPARMOR_PROFILE بازنویسی شود. این گزینه تنها زمانی در دسترس است که sudo-rs با پشتیبانی AppArmor ساخته شده باشد. این گزینه به طور پیش‌فرض تنظیم نشده است.

•
runcwd

در صورت تنظیم، sudo از این مقدار برای دایرکتوری کاری هنگام اجرای یک دستور استفاده خواهد کرد. مقدار ویژه “*” به کاربر اجازه می‌دهد تا دایرکتوری کاری را از طریق گزینه -D در sudo مشخص کند. برای جزئیات بیشتر بخش Chdir_Spec را ببینید.

•
secure_path

در صورت تنظیم، sudo از این مقدار به جای متغیر محیطی PATH کاربر استفاده خواهد کرد. این گزینه می‌تواند برای بازنشانی PATH به یک مقدار مطمئن و شناخته‌شده به کار رود که شامل دایرکتوری‌های دستورهای مدیر سیستم مانند /usr/sbin است. این گزینه به طور پیش‌فرض تنظیم نشده است.

•
env_check

متغیرهای محیطی که باید از محیط کاربر حذف شوند مگر اینکه “امن” در نظر گرفته شوند. برای همه متغیرها به جز TZ، “امن” بدین معناست که مقدار متغیر شامل هیچ نویسه `%' یا `/' نباشد. این می‌تواند برای محافظت در برابر آسیب‌پذیری‌های قالب‌بندی سبک printf در برنامه‌های بد نوشته‌شده به کار رود. متغیر TZ در صورت برقراری هریک از شرایط زیر ناامن در نظر گرفته می‌شود:

•  It consists of a fully-qualified path name, optionally prefixed with a colon (‘:’), that does not match the location of the zoneinfo directory.
•  It contains a .. path element.
•  It contains white space or non-printable characters.
•  It is longer than the value of PATH_MAX.

آرگومان می‌تواند یک فهرست جداشده با فاصله درون گیومه دوتایی، یا یک مقدار منفرد بدون گیومه دوتایی باشد. این فهرست می‌تواند به ترتیب با استفاده از عملگرهای =، +=، -=، و ! جایگزین شود، به آن افزوده شود، از آن حذف گردد، یا غیرفعال شود. صرف‌نظر از اینکه گزینه env_reset فعال یا غیرفعال باشد، متغیرهای مشخص‌شده با env_check در صورت قبولی در بررسی پیش‌گفته در محیط حفظ خواهند شد. فهرست سراسری متغیرهای محیطی برای بررسی، هنگامی که sudo توسط root با گزینه -V اجرا شود، نمایش داده می‌شود.

•
env_keep

متغیرهای محیطی که در صورت فعال بودن گزینه env_reset باید در محیط کاربر حفظ شوند. این امکان کنترل دقیق بر محیطی را که فرایندهای ایجادشده توسط sudo دریافت می‌کنند، فراهم می‌سازد. آرگومان می‌تواند یک فهرست جداشده با فاصله درون گیومه دوتایی، یا یک مقدار منفرد بدون گیومه دوتایی باشد. این فهرست می‌تواند به ترتیب با استفاده از عملگرهای =، +=، -=، و ! جایگزین شود، به آن افزوده شود، از آن حذف گردد، یا غیرفعال شود. فهرست سراسری متغیرهای نگه‌داشتنی، هنگامی که sudo توسط root با گزینه -V اجرا شود، نمایش داده می‌شود.

حفظ متغیر محیطی HOME دارای پیامدهای امنیتی است زیرا بسیاری از برنامه‌ها هنگام جستجو برای پرونده‌های پیکربندی یا داده از آن استفاده می‌کنند. افزودن HOME به env_keep ممکن است کاربر را قادر سازد دستورهای بدون محدودیت را از طریق sudo اجرا کند و اکیداً منع می‌شود. کاربرانی که مایل به ویرایش پرونده‌ها با sudo هستند باید به جای فراخوانی مستقیم ویرایشگر، sudoedit (یا sudo -e) را اجرا کنند تا پیکربندی معمول ویرایشگر خود را به دست آورند.

برنامه sudo-rs رویدادها را از طریق syslog(3) گزارش می‌کند.

/etc/sudoers-rs           فهرست این‌که چه کسی مجاز به اجرای چه چیزی است (برای هم‌زیستی sudo-rs و sudo تاد میلر)
/etc/sudoers              فهرست این‌که چه کسی مجاز به اجرای چه چیزی است (سازگار با sudo)
/run/sudo/ts              دایرکتوری شامل مهرهای زمانی برای خط‌مشی امنیتی sudoers

به طور کلی “تفریق” یا کسر دستورها از ALL با استفاده از عملگر `!' مؤثر نیست. یک کاربر می‌تواند به سادگی با کپی کردن دستور مورد نظر به نامی دیگر و سپس اجرای آن، این محدودیت را دور بزند. برای نمونه:

bill    ALL = ALL, !SU, !SHELLS

واقعاً مانع از اجرای دستورهای فهرست‌شده در SU یا SHELLS توسط bill نمی‌شود، چرا که او می‌تواند به سادگی آن دستورها را به نامی دیگر کپی کند، یا از فرار پوسته از یک ویرایشگر یا برنامه دیگر استفاده کند. بنابراین، این دست محدودیت‌ها در بهترین حالت باید توصیه‌ای تلقی شوند (و توسط خط‌مشی تقویت گردند).

به طور کلی، اگر کاربری sudo ALL داشته باشد، صرف‌نظر از هرگونه عنصر `!' در مشخصات کاربر، هیچ چیز نمی‌تواند مانع از ساخت برنامه‌ای توسط او شود که یک پوسته root به او بدهد (یا ساخت کپی خودش از یک پوسته).

برنامه sudo-rs از fast_glob استفاده می‌کند، که علاوه بر این بدان معناست که نفی مطمئن دستورهایی که در آنها نام مسیر شامل نویسه‌های globbing (معروف به عام یا وایلدکارت) است، امکان‌پذیر نیست. دلیل این امر آن است که تابع fnmatch در کتابخانه Rust نمی‌تواند مسیرهای نسبی را حل کند. در حالی که این موضوع معمولاً تنها برای قواعدی که امتیازاتی را اعطا می‌کنند یک ناراحتی ساده است، می‌تواند برای قواعدی که امتیازات را کسر یا لغو می‌کنند منجر به یک مشکل امنیتی شود.

برای نمونه، با فرض مدخل زیر در پرونده sudoers:

john    ALL = /usr/bin/passwd [a-zA-Z0-9]*, /usr/bin/chsh [a-zA-Z0-9]*,\
              /usr/bin/chfn [a-zA-Z0-9]*, !/usr/bin/* root

کاربر john همچنان می‌تواند در صورت فعال بودن fast_glob، با رفتن به دایرکتوری /usr/bin و اجرای ./passwd root به جای آن، دستور /usr/bin/passwd root را اجرا کند.

هنگامی که sudo برنامه‌ای را اجرا می‌کند، آن برنامه آزاد است هر کاری را که می‌خواهد انجام دهد، از جمله اجرای برنامه‌های دیگر. این می‌تواند یک مشکل امنیتی باشد زیرا غیرمعمول نیست که برنامه‌ای فرار پوسته (shell escapes) را مجاز بداند، که به کاربر اجازه می‌دهد کنترل دسترسی و ثبت گزارش sudo را دور بزند. برنامه‌های متداولی که فرار پوسته را مجاز می‌دانند شامل پوسته‌ها (بدیهی است)، ویرایشگرها، صفحه‌بندها (مانند less)، ایمیل و برنامه‌های پایانه هستند.

روی لینوکس، sudo-rs دارای قابلیت noexec برنامه sudo بر پایه پالایه seccomp() است. برنامه‌هایی که در حالت noexec اجرا می‌شوند نمی‌توانند برنامه‌های دیگر را اجرا کنند. پیاده‌سازی در sudo-rs با sudo تاد میلر متفاوت است و روی باینری‌های پیوند ایستا نیز باید کار کند.

توجه داشته باشید که محدود کردن فرارهای پوسته درمانی قطعی برای همه دردها نیست. برنامه‌هایی که به عنوان root اجرا می‌شوند همچنان قادر به انجام عملیات بسیار پرخطر (مانند تغییر یا بازنویسی پرونده‌ها) هستند که می‌تواند به ارتقای ناخواسته امتیاز بیانجامد. همچنین NOEXEC محافظتی در برابر برنامه‌های مخرب نیست. این ویژگی مانع از نگاشت حافظه به عنوان قابل اجرا نمی‌شود و در برابر فراخوان‌های سیستمی آینده که می‌توانند مانند ویژگی پیشنهادی exec در io_uring لینوکس یک exec() انجام دهند، محافظت نمی‌کند. و همچنین به همان دلایلی که در برابر برنامه‌های مخرب محافظت نمی‌کند، در برابر برنامه‌های درستی که دانسته یا ندانسته به کاربر اجازه نوشتن در /proc/self/mem را می‌دهند نیز محافظت به عمل نمی‌آورد. شما همواره باید بیازمایید که آیا noexec واقعاً مانع از فرارهای پوسته برای برنامه‌هایی که قرار است با آن به کار روند می‌شود یا خیر.

برنامه sudo-rs مالکیت دایرکتوری مهرزمانی خود (پیش‌فرض /run/sudo/ts) را بررسی خواهد کرد و در صورتی که تحت مالکیت root نباشد یا توسط کاربری غیر از root قابل نوشتن باشد، محتوای دایرکتوری را نادیده خواهد گرفت.

در حالی که دایرکتوری مهرزمانی باید در زمان راه‌اندازی مجدد پاک شود، برای جلوگیری از مشکلات احتمالی، sudo-rs در سیستم‌هایی که زمان راه‌اندازی در دسترس است، پرونده‌های مهرزمانی تاریخ‌خورده پیش از راه‌اندازی ماشین را نادیده خواهد گرفت.

برخی سیستم‌های دارای محیط میزکار گرافیکی به کاربران بدون امتیاز اجازه می‌دهند ساعت سیستم را تغییر دهند. از آنجا که sudo-rs برای اعتبارسنجی مهرزمانی به ساعت سیستم متکی است، ممکن است در چنین سیستم‌هایی کاربری با عقب کشیدن ساعت بتواند sudo را به مدت طولانی‌تر از timestamp_timeout اجرا کند. برای مقابله با این مسئله، sudo-rs در صورتی که سیستم پشتیبانی کند، از یک ساعت یکنواخت (که هرگز به عقب برنمی‌گردد) برای مهرهای زمانی خود استفاده می‌کند. برنامه sudo-rs مهرهای زمانی تنظیم‌شده در آینده دور را نخواهد پذیرفت.

su(1), fnmatch(3), glob(3), sudo(8), visudo(8)

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

اگر احساس می‌کنید اشکالی در sudo-rs یافته‌اید، لطفاً گزارش اشکال را در نشانی زیر ارسال کنید: https://github.com/trifectatechfoundation/sudo-rs/issues/

این صفحه راهنما نگارش اصلاح‌شده‌ای از مستندات sudoers(5) نوشته‌شده توسط تاد میلر (Todd Miller) است؛ برای نسخه اصلی https://www.sudo.ws/ را ببینید.

برنامه sudo-rs به صورت “همان‌گونه که هست” ارائه می‌شود و هرگونه ضمانت صریح یا ضمنی، از جمله، اما نه محدود به، ضمانت‌های ضمنی خریدوفروش و مناسب بودن برای یک هدف معین سلب می‌شود.

sudo-rs 0.2.15