.\" -*- mode: troff; coding: utf-8 -*- .\" Automatically generated by Pod::Man v6.0.2 (Pod::Simple 3.45) .\" .\" Standard preamble: .\" ======================================================================== .de Sp \" Vertical space (when we can't use .PP) .if t .sp .5v .if n .sp .. .de Vb \" Begin verbatim text .ft CW .nf .ne \\$1 .. .de Ve \" End verbatim text .ft R .fi .. .\" \*(C` and \*(C' are quotes in nroff, nothing in troff, for use with C<>. .ie n \{\ . ds C` "" . ds C' "" 'br\} .el\{\ . ds C` . ds C' 'br\} .\" .\" Escape single quotes in literal strings from groff's Unicode transform. .ie \n(.g .ds Aq \(aq .el .ds Aq ' .\" .\" If the F register is >0, we'll generate index entries on stderr for .\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index .\" entries marked with X<> in POD. Of course, you'll have to process the .\" output yourself in some meaningful fashion. .\" .\" Avoid warning from groff about undefined register 'F'. .de IX .. .nr rF 0 .if \n(.g .if rF .nr rF 1 .if (\n(rF:(\n(.g==0)) \{\ . if \nF \{\ . de IX . tm Index:\\$1\t\\n%\t"\\$2" .. . if !\nF==2 \{\ . nr % 0 . nr F 2 . \} . \} .\} .rr rF .\" .\" Required to disable full justification in groff 1.23.0. .if n .ds AD l .\" ======================================================================== .\" .IX Title "APPARMOR.D 5" .TH APPARMOR.D 5 2026-03-10 "AppArmor 4.1.7" AppArmor .\" For nroff, turn off justification. Always turn off hyphenation; it makes .\" way too many mistakes in technical documents. .if n .ad l .nh .SH "نام (NAME)" apparmor.d \- نحو پروفایل‌های امنیتی برای AppArmor .SH "توضیحات (DESCRIPTION)" .IX Header "DESCRIPTION" پروفایل‌های AppArmor حقوق دسترسی اجباری اعطاشده به برنامه‌های مشخص را شرح می‌دهند و با استفاده از \&\fBapparmor_parser\fR\|(8) به ماژول اعمال خط‌مشی AppArmor تغذیه می‌شوند. این صفحه راهنما ساختار و قالب فایل‌های پیکربندی AppArmor را شرح می‌دهد؛ برای مروری کلی بر AppArmor، \fBapparmor\fR\|(7) را ببینید. .SH "قالب (FORMAT)" .IX Header "FORMAT" خط‌مشی AppArmor به یک زبان توصیفی نوشته می‌شود که در آن ترتیب قواعد درون یک بخش یا بلوک مشخص اهمیتی ندارد. طبق عرف، خط‌مشی‌ها به گونه‌ای نوشته می‌شوند که در چندین فایل گنجانده شوند، اما این یک الزام نیست و به همان آسانی می‌تواند در یک فایل منفرد نوشته شود. زبان خط‌مشی به یک قالب باینری مستقل از معماری کامپایل می‌شود که برای اعمال شدن در هسته بارگذاری می‌گردد. .PP واحد پایه محدودسازی در AppArmor پروفایل است. این واحد شامل مجموعه‌ای از قواعد است که هنگام پیوند پروفایل با یک برنامه در حال اجرا اعمال می‌شوند. قواعد درون پروفایل یک فهرست مجاز (whitelist) از دسترسی‌های مختلف به همراه چند قاعده خاص دیگر را فراهم می‌کنند. .PP متن موجود در خط‌مشی AppArmor به دو بخش مقدمه (preamble) و تعاریف پروفایل تقسیم می‌شود. بخش مقدمه باید در ابتدای فایل قرار گیرد و با شروع تعاریف پروفایل، دیگر هیچ قاعده مقدماتی مجاز نخواهد بود (حتی در فایل‌هایی که درون پروفایل گنجانده/include می‌شوند). هنگامی که خط‌مشی AppArmor (مجموعه پروفایل‌ها) در چندین فایل تقسیم شده باشد، هر فایل می‌تواند بخش مقدمه اختصاصی خود را داشته باشد که ممکن است با مقدمه سایر فایل‌ها یکسان یا متفاوت باشد. فایل‌هایی که در داخل یک بخش پروفایل include می‌شوند نمی‌توانند بخش مقدمه داشته باشند. .PP در ادامه شرحی به سبک BNF از فایل‌های پیکربندی خط‌مشی AppArmor آمده است؛ برای مشاهده نمونه فایل خط‌مشی AppArmor به بخش‌های پایین‌تر مراجعه کنید. فایل‌های پیکربندی AppArmor خط‌محور هستند؛ نماد \fB#\fR مشابه زبان‌های اسکریپت‌نویسی شل، یک توضیح (کامنت) را معرفی می‌کند. استثنای این قاعده عبارت \fB#include\fR است که محتوای یک فایل را به صورت درون‌خطی به خط‌مشی اضافه (include) می‌کند؛ این رفتار از \fBcpp\fR\|(1) الگوبرداری شده است. .Sp .RS 4 \&\fBPROFILE FILE\fR = ( [ \fIPREAMBLE\fR ] [ \fIPROFILE\fR ] )* .Sp \&\fBPREAMBLE\fR = ( \fICOMMENT\fR | \fIVARIABLE ASSIGNMENT\fR | \fIALIAS RULE\fR | \fIINCLUDE\fR | \fIABI\fR )* قواعد مقداردهی متغیرها و نام‌های مستعار باید پیش از پروفایل قرار گیرند. .Sp \&\fBVARIABLE ASSIGNMENT\fR = \fIVARIABLE\fR (\*(Aq=\*(Aq | \*(Aq+=\*(Aq) (مقادیر جداشده با فاصله) .Sp \&\fBVARIABLE\fR = \*(Aq@{\*(Aq \fIALPHA\fR [ ( \fIALPHANUMERIC\fR | \*(Aq_\*(Aq ) ... ] \*(Aq}\*(Aq .Sp \&\fBALIAS RULE\fR = \*(Aqalias\*(Aq \fIABS PATH\fR \*(Aq\->\*(Aq \fIREWRITTEN ABS PATH\fR \*(Aq,\*(Aq .Sp \&\fBINCLUDE\fR = ( \*(Aq#include\*(Aq | \*(Aqinclude\*(Aq ) [ \*(Aqif exists\*(Aq ] ( \fIABS PATH\fR | \fIMAGIC PATH\fR ) .Sp \&\fBABI\fR = ( \*(Aqabi\*(Aq ) ( \fIABS PATH\fR | \fIMAGIC PATH\fR ) \*(Aq,\*(Aq .Sp \&\fBABS PATH\fR = \*(Aq"\*(Aq path \*(Aq"\*(Aq (مسیر به \fBopen\fR\|(2) ارسال می‌شود) .Sp \&\fBMAGIC PATH\fR = \*(Aq<\*(Aq relative path \*(Aq>\*(Aq مسیر نسبت به \fI/etc/apparmor.d/\fR سنجیده می‌شود. .Sp \&\fBCOMMENT\fR = \*(Aq#\*(Aq \fITEXT\fR [ \*(Aq\er\*(Aq ] \*(Aq\en\*(Aq .Sp \&\fBTEXT\fR = هر نویسه‌ای .Sp \&\fBPROFILE\fR = ( \fIPROFILE HEAD\fR ) [ \fIATTACHMENT SPECIFICATION\fR ] [ \fIPROFILE FLAG CONDS\fR ] \*(Aq{\*(Aq ( \fIRULES\fR )* \*(Aq}\*(Aq .Sp \&\fBPROFILE HEAD\fR = [ \*(Aqprofile\*(Aq ] \fIFILEGLOB\fR | \*(Aqprofile\*(Aq \fIPROFILE NAME\fR .Sp \&\fBPROFILE NAME\fR ( \fIUNQUOTED PROFILE NAME\fR | \fIQUOTED PROFILE NAME\fR ) .Sp \&\fBQUOTED PROFILE NAME\fR = \*(Aq"\*(Aq \fIUNQUOTED PROFILE NAME\fR \*(Aq"\*(Aq .Sp \&\fBUNQUOTED PROFILE NAME\fR = (باید پس از بسط متغیر با نویسه الفبانومریک آغاز شود، یا \*(Aq/\*(Aq؛ \fBAARE\fRها دارای معانی خاص هستند؛ پایین‌تر را ببینید. می‌تواند شامل \fIVARIABLE\fR باشد. قواعد دارای فاصله یا تب تعبیه‌شده باید داخل کوتیشن باشند.) .Sp \&\fBATTACHMENT SPECIFICATION\fR = [ \fIPROFILE_EXEC_COND\fR ] [ \fIPROFILE XATTR CONDS\fR ] .Sp \&\fBPROFILE_EXEC_COND\fR = \fIFILEGLOB\fR .Sp \&\fBPROFILE XATTR CONDS\fR = [ \*(Aqxattrs=\*(Aq ] \*(Aq(\*(Aq فهرست جداشده با کاما یا فاصله خالی از \fIPROFILE XATTR\fR \*(Aq)\*(Aq .Sp \&\fBPROFILE XATTR\fR = نام صفت گسترده \*(Aq=\*(Aq \fIXATTR VALUE FILEGLOB\fR .Sp \&\fBXATTR VALUE FILEGLOB\fR = \fIFILEGLOB\fR .Sp \&\fBPROFILE FLAG CONDS\fR = [ \*(Aqflags=\*(Aq ] \*(Aq(\*(Aq فهرست جداشده با کاما یا فاصله خالی از \fIPROFILE FLAGS\fR \*(Aq)\*(Aq .Sp \&\fBPROFILE FLAGS\fR = \fIPROFILE MODE\fR | \fIAUDIT_MODE\fR | \*(Aqmediate_deleted\*(Aq | \*(Aqattach_disconnected\*(Aq | \*(Aqattach_disconnected.path=\*(Aq\fIABS PATH\fR | \*(Aqchroot_relative\*(Aq | \*(Aqdebug\*(Aq | \*(Aqinterruptible\*(Aq | \*(Aqkill.signal=\*(Aq\fISIGNAL\fR | \*(Aqerror=\*(Aq\fIERROR CODE\fR .Sp \&\fBERROR CODE\fR = (نام کد خطای غیرحساس به حروف بزرگ و کوچک که با \*(AqE\*(Aq آغاز می‌شود؛ \fBerrno\fR\|(3) را ببینید) .Sp \&\fBPROFILE MODE\fR = \*(Aqenforce\*(Aq | \*(Aqcomplain\*(Aq | \*(Aqkill\*(Aq | \*(Aqdefault_allow\*(Aq | \*(Aqunconfined\*(Aq | \*(Aqprompt\*(Aq .Sp \&\fBAUDIT MODE\fR = \*(Aqaudit\*(Aq .Sp \&\fBRULES\fR = [ ( \fILINE RULES\fR | \fICOMMA RULES\fR \*(Aq,\*(Aq | \fIBLOCK RULES\fR ) .Sp \&\fBLINE RULES\fR = ( \fICOMMENT\fR | \fIINCLUDE\fR ) [ \*(Aq\er\*(Aq ] \*(Aq\en\*(Aq .Sp \&\fBCOMMA RULES\fR = ( \fICAPABILITY RULE\fR | \fINETWORK RULE\fR | \fIMOUNT RULE\fR | \fIPIVOT ROOT RULE\fR | \fIUNIX RULE\fR | \fIFILE RULE\fR | \fILINK RULE\fR | \fICHANGE_PROFILE RULE\fR | \fIRLIMIT RULE\fR | \fIDBUS RULE\fR | \fIMQUEUE RULE\fR | \fIIO_URING RULE\fR | \fIUSERNS RULE\fR | \fIALL RULE\fR) .Sp \&\fBBLOCK RULES\fR = ( \fISUBPROFILE\fR | \fIHAT\fR | \fIQUALIFIER BLOCK\fR ) .Sp \&\fBSUBPROFILE\fR = \*(Aqprofile\*(Aq \fIPROFILE NAME\fR [ \fIATTACHMENT SPECIFICATION\fR ] [ \fIPROFILE FLAG CONDS\fR ] \*(Aq{\*(Aq ( \fIRULES\fR )* \*(Aq}\*(Aq .Sp \&\fBHAT\fR = (\*(Aqhat\*(Aq | \*(Aq^\*(Aq) \fIHATNAME\fR [ \fIPROFILE FLAG CONDS\fR ] \*(Aq{\*(Aq ( \fIRULES\fR )* \*(Aq}\*(Aq .Sp \&\fBHATNAME\fR = (باید با نویسه الفبانومریک آغاز شود. برای شرح نحوه استفاده از این "hat"، \fBaa_change_hat\fR\|(2) را ببینید. اگر از \*(Aq^\*(Aq برای شروع یک کلاه (hat) استفاده شود، نباید فاصله‌ای میان \*(Aq^\*(Aq و \fIHATNAME\fR وجود داشته باشد) .Sp \&\fBQUALIFIER BLOCK\fR = \fIQUALIFIERS\fR \fIBLOCK\fR .Sp \&\fBINTEGER\fR = (+ | \-)? [[:digit:]]+ .Sp \&\fBACCESS TYPE\fR = ( \*(Aqallow\*(Aq | \*(Aqdeny\*(Aq ) .Sp \&\fBQUALIFIERS\fR = [ \*(Aqpriority\*(Aq \*(Aq=\*(Aq ] [ \*(Aqaudit\*(Aq ] [ \fIACCESS TYPE\fR ] .Sp \&\fBCAPABILITY RULE\fR = [ \fIQUALIFIERS\fR ] \*(Aqcapability\*(Aq [ \fICAPABILITY LIST\fR ] .Sp \&\fBCAPABILITY LIST\fR = ( \fICAPABILITY\fR )+ .Sp \&\fBCAPABILITY\fR = (نام قابلیت با حروف کوچک بدون پیشوند \*(AqCAP_\*(Aq؛ \&\fBcapabilities\fR\|(7) را ببینید) .Sp \&\fBNETWORK RULE\fR = [ \fIQUALIFIERS\fR ] \*(Aqnetwork\*(Aq [ \fINETWORK ACCESS EXPR\fR ] [ \fIDOMAIN\fR ] [ \fITYPE\fR | \fIPROTOCOL\fR ] [ \fINETWORK LOCAL EXPR\fR ] [ \fINETWORK PEER EXPR\fR ] .Sp \&\fBNETWORK ACCESS EXPR\fR = ( \fINETWORK ACCESS\fR | \fINETWORK ACCESS LIST\fR ) .Sp \&\fBNETWORK ACCESS\fR = ( \*(Aqcreate\*(Aq | \*(Aqbind\*(Aq | \*(Aqlisten\*(Aq | \*(Aqaccept\*(Aq | \*(Aqconnect\*(Aq | \*(Aqshutdown\*(Aq | \*(Aqgetattr\*(Aq | \*(Aqsetattr\*(Aq | \*(Aqgetopt\*(Aq | \*(Aqsetopt\*(Aq | \*(Aqsend\*(Aq | \*(Aqreceive\*(Aq | \*(Aqr\*(Aq | \*(Aqw\*(Aq | \*(Aqrw\*(Aq ) برخی حالت‌های دسترسی با بعضی قواعد ناسازگارند. .Sp \&\fBNETWORK ACCESS LIST\fR = \*(Aq(\*(Aq \fINETWORK ACCESS\fR ( [\*(Aq,\*(Aq] \fINETWORK ACCESS\fR )* \*(Aq)\*(Aq .Sp \&\fBDOMAIN\fR = ( \*(Aqunix\*(Aq | \*(Aqinet\*(Aq | \*(Aqax25\*(Aq | \*(Aqipx\*(Aq | \*(Aqappletalk\*(Aq | \*(Aqnetrom\*(Aq | \*(Aqbridge\*(Aq | \*(Aqatmpvc\*(Aq | \*(Aqx25\*(Aq | \*(Aqinet6\*(Aq | \*(Aqrose\*(Aq | \*(Aqnetbeui\*(Aq | \*(Aqsecurity\*(Aq | \*(Aqkey\*(Aq | \*(Aqnetlink\*(Aq | \*(Aqpacket\*(Aq | \*(Aqash\*(Aq | \*(Aqeconet\*(Aq | \*(Aqatmsvc\*(Aq | \*(Aqrds\*(Aq | \*(Aqsna\*(Aq | \*(Aqirda\*(Aq | \*(Aqpppox\*(Aq | \*(Aqwanpipe\*(Aq | \*(Aqllc\*(Aq | \*(Aqib\*(Aq | \*(Aqmpls\*(Aq | \*(Aqcan\*(Aq | \*(Aqtipc\*(Aq | \*(Aqbluetooth\*(Aq | \*(Aqiucv\*(Aq | \*(Aqrxrpc\*(Aq | \*(Aqisdn\*(Aq | \*(Aqphonet\*(Aq | \*(Aqieee802154\*(Aq | \*(Aqcaif\*(Aq | \*(Aqalg\*(Aq | \*(Aqnfc\*(Aq | \*(Aqvsock\*(Aq | \*(Aqkcm\*(Aq | \*(Aqqipcrtr\*(Aq | \*(Aqsmc\*(Aq | \*(Aqxdp\*(Aq | \*(Aqmctp\*(Aq ) \*(Aq,\*(Aq .Sp \&\fBTYPE\fR = ( \*(Aqstream\*(Aq | \*(Aqdgram\*(Aq | \*(Aqseqpacket\*(Aq | \*(Aqrdm\*(Aq | \*(Aqraw\*(Aq | \*(Aqpacket\*(Aq ) .Sp \&\fBPROTOCOL\fR = ( \*(Aqtcp\*(Aq | \*(Aqudp\*(Aq | \*(Aqicmp\*(Aq ) .Sp \&\fBNETWORK LOCAL EXPR\fR = ( \fINETWORK IP COND\fR | \fINETWORK PORT COND\fR )* هر شرط حداکثر می‌تواند یک بار ظاهر شود. .Sp \&\fBNETWORK PEER EXPR\fR = \*(Aqpeer\*(Aq \*(Aq=\*(Aq \*(Aq(\*(Aq ( \fINETWORK IP COND\fR | \fINETWORK PORT COND\fR )+ \*(Aq)\*(Aq هر شرط حداکثر می‌تواند یک بار ظاهر شود. .Sp \&\fBNETWORK IP COND\fR = \*(Aqip\*(Aq \*(Aq=\*(Aq ( \*(Aqnone\*(Aq | \fINETWORK IPV4\fR | \fINETWORK IPV6\fR ) .Sp \&\fBNETWORK PORT COND\fR = \*(Aqport\*(Aq \*(Aq=\*(Aq ( \fINETWORK PORT\fR | \fINETWORK PORT\fR \*(Aq\-\*(Aq \fINETWORK PORT\fR ) .Sp \&\fBNETWORK IPV4\fR = IPv4، نمایش‌یافته با چهار عدد ده‌دهی ۸ بیتی که با \*(Aq.\*(Aq از هم جدا شده‌اند .Sp \&\fBNETWORK IPV6\fR = IPv6، نمایش‌یافته با هشت گروه چهار رقمی از اعداد شانزده‌شانزدهی که با \*(Aq:\*(Aq جدا شده‌اند. نمایش کوتاه‌شده صفرهای متوالی با استفاده از \*(Aq::\*(Aq مجاز است .Sp \&\fBNETWORK PORT\fR = عدد ۱۶ بیتی در بازه ۰ تا ۶۵۵۳۵ .Sp \&\fBMOUNT RULE\fR = ( \fIMOUNT\fR | \fIREMOUNT\fR | \fIUMOUNT\fR ) .Sp \&\fBMOUNT\fR = [ \fIQUALIFIERS\fR ] \*(Aqmount\*(Aq [ \fIMOUNT CONDITIONS\fR ] [ \fISOURCE FILEGLOB\fR ] [ \*(Aq\->\*(Aq [ \fIMOUNTPOINT FILEGLOB\fR ] .Sp \&\fBREMOUNT\fR = [ \fIQUALIFIERS\fR ] \*(Aqremount\*(Aq [ \fIMOUNT CONDITIONS\fR ] \fIMOUNTPOINT FILEGLOB\fR .Sp \&\fBUMOUNT\fR = [ \fIQUALIFIERS\fR ] \*(Aqumount\*(Aq [ \fIMOUNT CONDITIONS\fR ] \fIMOUNTPOINT FILEGLOB\fR .Sp \&\fBMOUNT CONDITIONS\fR = [ ( \*(Aqfstype\*(Aq | \*(Aqvfstype\*(Aq ) ( \*(Aq=\*(Aq | \*(Aqin\*(Aq ) \fIMOUNT FSTYPE EXPRESSION\fR ] [ \*(Aqoptions\*(Aq ( \*(Aq=\*(Aq | \*(Aqin\*(Aq ) \fIMOUNT FLAGS EXPRESSION\fR ] .Sp \&\fBMOUNT FSTYPE EXPRESSION\fR = ( \fIMOUNT FSTYPE LIST\fR | \fIMOUNT EXPRESSION\fR ) .Sp \&\fBMOUNT FSTYPE LIST\fR = فهرست جداشده با کاما از انواع معتبر سیستم‌فایل و سیستم‌فایل مجازی (مانند ext4، debugfs، devfs و...) .Sp \&\fBMOUNT FLAGS EXPRESSION\fR = ( \fIMOUNT FLAGS LIST\fR | \fIMOUNT EXPRESSION\fR ) .Sp \&\fBMOUNT FLAGS LIST\fR = فهرست جداشده با کاما از \fIMOUNT FLAGS\fR. .Sp \&\fBMOUNT FLAGS\fR = ( \*(Aqro\*(Aq | \*(Aqrw\*(Aq | \*(Aqnosuid\*(Aq | \*(Aqsuid\*(Aq | \*(Aqnodev\*(Aq | \*(Aqdev\*(Aq | \*(Aqnoexec\*(Aq | \*(Aqexec\*(Aq | \*(Aqsync\*(Aq | \*(Aqasync\*(Aq | \*(Aqremount\*(Aq | \*(Aqmand\*(Aq | \*(Aqnomand\*(Aq | \*(Aqdirsync\*(Aq | \*(Aqnoatime\*(Aq | \*(Aqatime\*(Aq | \*(Aqnodiratime\*(Aq | \*(Aqdiratime\*(Aq | \*(Aqbind\*(Aq | \*(Aqrbind\*(Aq | \*(Aqmove\*(Aq | \*(Aqverbose\*(Aq | \*(Aqsilent\*(Aq | \*(Aqloud\*(Aq | \*(Aqacl\*(Aq | \*(Aqnoacl\*(Aq | \*(Aqunbindable\*(Aq | \*(Aqrunbindable\*(Aq | \*(Aqprivate\*(Aq | \*(Aqrprivate\*(Aq | \*(Aqslave\*(Aq | \*(Aqrslave\*(Aq | \*(Aqshared\*(Aq | \*(Aqrshared\*(Aq | \*(Aqrelatime\*(Aq | \*(Aqnorelatime\*(Aq | \*(Aqiversion\*(Aq | \*(Aqnoiversion\*(Aq | \*(Aqstrictatime\*(Aq | \*(Aqnostrictatime\*(Aq | \*(Aqlazytime\*(Aq | \*(Aqnolazytime\*(Aq | \*(Aqnouser\*(Aq | \*(Aquser\*(Aq | \*(Aqsymfollow\*(Aq | \*(Aqnosymfollow\*(Aq ) .Sp \&\fBMOUNT EXPRESSION\fR = ( \fIALPHANUMERIC\fR | \fIAARE\fR ) ... .Sp \&\fBMQUEUE_RULE\fR = [ \fIQUALIFIERS\fR ] \*(Aqmqueue\*(Aq [ \fIMQUEUE ACCESS PERMISSIONS\fR ] [ \fIMQUEUE TYPE\fR ] [ \fIMQUEUE LABEL\fR ] [ \fIMQUEUE NAME\fR ] .Sp \&\fBMQUEUE ACCESS PERMISSIONS\fR = \fIMQUEUE ACCESS\fR | \fIMQUEUE ACCESS LIST\fR .Sp \&\fBMQUEUE ACCESS LIST\fR = \*(Aq(\*(Aq فهرست جداشده با کاما یا فاصله از \fIMQUEUE ACCESS\fR \*(Aq)\*(Aq .Sp \&\fBMQUEUE ACCESS\fR = ( \*(Aqr\*(Aq | \*(Aqw\*(Aq | \*(Aqrw\*(Aq | \*(Aqread\*(Aq | \*(Aqwrite\*(Aq | \*(Aqcreate\*(Aq | \*(Aqopen\*(Aq | \*(Aqdelete\*(Aq | \*(Aqgetattr\*(Aq | \*(Aqsetattr\*(Aq ) .Sp \&\fBMQUEUE TYPE\fR = \*(Aqtype\*(Aq \*(Aq=\*(Aq ( \*(Aqposix\*(Aq | \*(Aqsysv\*(Aq ) .Sp \&\fBMQUEUE LABEL\fR = \*(Aqlabel\*(Aq \*(Aq=\*(Aq \*(Aq(\*(Aq \*(Aq"\*(Aq \fIAARE\fR \*(Aq"\*(Aq | \fIAARE\fR \*(Aq)\*(Aq .Sp \&\fBMQUEUE NAME\fR = \fIAARE\fR .Sp \&\fBUSERNS RULE\fR = [ \fIQUALIFIERS\fR ] \*(Aquserns\*(Aq [ \fIUSERNS ACCESS PERMISSIONS\fR ] .Sp \&\fBUSERNS ACCESS PERMISSIONS\fR = ( \*(Aqcreate\*(Aq ) .Sp \&\fBIO_URING RULE\fR = [ \fIQUALIFIERS\fR ] \*(Aqio_uring\*(Aq [ \fIIO_URING ACCESS PERMISSIONS\fR [ \fIIO_URING LABEL\fR ] .Sp \&\fBIO_URING ACCESS PERMISSIONS\fR = ( \*(Aqsqpoll\*(Aq | \*(Aqoverride_creds\*(Aq ) .Sp \&\fBIO_URING LABEL\fR = \*(Aqlabel\*(Aq \*(Aq=\*(Aq \*(Aq(\*(Aq \*(Aq"\*(Aq \fIAARE\fR \*(Aq"\*(Aq | \fIAARE\fR \*(Aq)\*(Aq .Sp \&\fBPIVOT ROOT RULE\fR = [ \fIQUALIFIERS\fR ] pivot_root [ oldroot=\fIOLD PUT FILEGLOB\fR ] [ \fINEW ROOT FILEGLOB\fR ] [ \*(Aq\->\*(Aq \fIPROFILE NAME\fR ] .Sp \&\fBSOURCE FILEGLOB\fR = \fIFILEGLOB\fR .Sp \&\fBMOUNTPOINT FILEGLOB\fR = \fIFILEGLOB\fR .Sp \&\fBOLD PUT FILEGLOB\fR = \fIFILEGLOB\fR .Sp \&\fBPTRACE_RULE\fR = [ \fIQUALIFIERS\fR ] \*(Aqptrace\*(Aq [ \fIPTRACE ACCESS PERMISSIONS\fR ] [ \fIPTRACE PEER\fR ] .Sp \&\fBPTRACE ACCESS PERMISSIONS\fR = \fIPTRACE ACCESS\fR | \fIPTRACE ACCESS LIST\fR .Sp \&\fBPTRACE ACCESS LIST\fR = \*(Aq(\*(Aq فهرست جداشده با کاما یا فاصله از \fIPTRACE ACCESS\fR \*(Aq)\*(Aq .Sp \&\fBPTRACE ACCESS\fR = ( \*(Aqr\*(Aq | \*(Aqw\*(Aq | \*(Aqrw\*(Aq | \*(Aqread\*(Aq | \*(Aqreadby\*(Aq | \*(Aqtrace\*(Aq | \*(Aqtracedby\*(Aq ) .Sp \&\fBPTRACE PEER\fR = \*(Aqpeer\*(Aq \*(Aq=\*(Aq \fIAARE\fR .Sp \&\fBSIGNAL_RULE\fR = [ \fIQUALIFIERS\fR ] \*(Aqsignal\*(Aq [ \fISIGNAL ACCESS PERMISSIONS\fR ] [ \fISIGNAL SET\fR ] [ \fISIGNAL PEER\fR ] .Sp \&\fBSIGNAL ACCESS PERMISSIONS\fR = \fISIGNAL ACCESS\fR | \fISIGNAL ACCESS LIST\fR .Sp \&\fBSIGNAL ACCESS LIST\fR = \*(Aq(\*(Aq فهرست جداشده با کاما یا فاصله از \fISIGNAL ACCESS\fR \*(Aq)\*(Aq .Sp \&\fBSIGNAL ACCESS\fR = ( \*(Aqr\*(Aq | \*(Aqw\*(Aq | \*(Aqrw\*(Aq | \*(Aqread\*(Aq | \*(Aqwrite\*(Aq | \*(Aqsend\*(Aq | \*(Aqreceive\*(Aq ) .Sp \&\fBSIGNAL SET\fR = \*(Aqset\*(Aq \*(Aq=\*(Aq \*(Aq(\*(Aq \fISIGNAL LIST\fR \*(Aq)\*(Aq .Sp \&\fBSIGNAL LIST\fR = فهرست جداشده با کاما یا فاصله از \fISIGNAL\fRها .Sp \&\fBSIGNAL\fR = ( \*(Aqhup\*(Aq | \*(Aqint\*(Aq | \*(Aqquit\*(Aq | \*(Aqill\*(Aq | \*(Aqtrap\*(Aq | \*(Aqabrt\*(Aq | \*(Aqbus\*(Aq | \*(Aqfpe\*(Aq | \*(Aqkill\*(Aq | \*(Aqusr1\*(Aq | \*(Aqsegv\*(Aq | \*(Aqusr2\*(Aq | \*(Aqpipe\*(Aq | \*(Aqalrm\*(Aq | \*(Aqterm\*(Aq | \*(Aqstkflt\*(Aq | \*(Aqchld\*(Aq | \*(Aqcont\*(Aq | \*(Aqstop\*(Aq | \*(Aqstp\*(Aq | \*(Aqttin\*(Aq | \*(Aqttou\*(Aq | \*(Aqurg\*(Aq | \*(Aqxcpu\*(Aq | \*(Aqxfsz\*(Aq | \*(Aqvtalrm\*(Aq | \*(Aqprof\*(Aq | \*(Aqwinch\*(Aq | \*(Aqio\*(Aq | \*(Aqpwr\*(Aq | \*(Aqsys\*(Aq | \*(Aqemt\*(Aq | \*(Aqexists\*(Aq | \*(Aqrtmin+0\*(Aq ... \*(Aqrtmin+32\*(Aq ) .Sp \&\fBSIGNAL PEER\fR = \*(Aqpeer\*(Aq \*(Aq=\*(Aq \fIAARE\fR .Sp \&\fBDBUS RULE\fR = ( \fIDBUS MESSAGE RULE\fR | \fIDBUS SERVICE RULE\fR | \fIDBUS EAVESDROP RULE\fR | \fIDBUS COMBINED RULE\fR ) .Sp \&\fBDBUS MESSAGE RULE\fR = [ \fIQUALIFIERS\fR ] \*(Aqdbus\*(Aq [ \fIDBUS ACCESS EXPRESSION\fR ] [ \fIDBUS BUS\fR ] [ \fIDBUS PATH\fR ] [ \fIDBUS INTERFACE\fR ] [ \fIDBUS MEMBER\fR ] [ \fIDBUS PEER\fR ] .Sp \&\fBDBUS SERVICE RULE\fR = [ \fIQUALIFIERS\fR ] \*(Aqdbus\*(Aq [ \fIDBUS ACCESS EXPRESSION\fR ] [ \fIDBUS BUS\fR ] [ \fIDBUS NAME\fR ] .Sp \&\fBDBUS EAVESDROP RULE\fR = [ \fIQUALIFIERS\fR ] \*(Aqdbus\*(Aq [ \fIDBUS ACCESS EXPRESSION\fR ] [ \fIDBUS BUS\fR ] .Sp \&\fBDBUS COMBINED RULE\fR = [ \fIQUALIFIERS\fR ] \*(Aqdbus\*(Aq [ \fIDBUS ACCESS EXPRESSION\fR ] [ \fIDBUS BUS\fR ] .Sp \&\fBDBUS ACCESS EXPRESSION\fR = ( \fIDBUS ACCESS\fR | \*(Aq(\*(Aq \fIDBUS ACCESS LIST\fR \*(Aq)\*(Aq ) .Sp \&\fBDBUS BUS\fR = \*(Aqbus\*(Aq \*(Aq=\*(Aq \*(Aq(\*(Aq \*(Aqsystem\*(Aq | \*(Aqsession\*(Aq | \*(Aq"\*(Aq \fIAARE\fR \*(Aq"\*(Aq | \fIAARE\fR \*(Aq)\*(Aq .Sp \&\fBDBUS PATH\fR = \*(Aqpath\*(Aq \*(Aq=\*(Aq \*(Aq(\*(Aq \*(Aq"\*(Aq \fIAARE\fR \*(Aq"\*(Aq | \fIAARE\fR \*(Aq)\*(Aq .Sp \&\fBDBUS INTERFACE\fR = \*(Aqinterface\*(Aq \*(Aq=\*(Aq \*(Aq(\*(Aq \*(Aq"\*(Aq \fIAARE\fR \*(Aq"\*(Aq | \fIAARE\fR \*(Aq)\*(Aq .Sp \&\fBDBUS MEMBER\fR = \*(Aqmember\*(Aq \*(Aq=\*(Aq \*(Aq(\*(Aq \*(Aq"\*(Aq \fIAARE\fR \*(Aq"\*(Aq | \fIAARE\fR \*(Aq)\*(Aq .Sp \&\fBDBUS PEER\fR = \*(Aqpeer\*(Aq \*(Aq=\*(Aq \*(Aq(\*(Aq [ \fIDBUS NAME\fR ] [ \fIDBUS LABEL\fR ] \*(Aq)\*(Aq .Sp \&\fBDBUS NAME\fR = \*(Aqname\*(Aq \*(Aq=\*(Aq \*(Aq(\*(Aq \*(Aq"\*(Aq \fIAARE\fR \*(Aq"\*(Aq | \fIAARE\fR \*(Aq)\*(Aq .Sp \&\fBDBUS LABEL\fR = \*(Aqlabel\*(Aq \*(Aq=\*(Aq \*(Aq(\*(Aq \*(Aq"\*(Aq \fIAARE\fR \*(Aq"\*(Aq | \fIAARE\fR \*(Aq)\*(Aq .Sp \&\fBDBUS ACCESS LIST\fR = فهرست جداشده با کاما از \fIDBUS ACCESS\fR .Sp \&\fBDBUS ACCESS\fR = ( \*(Aqsend\*(Aq | \*(Aqreceive\*(Aq | \*(Aqbind\*(Aq | \*(Aqeavesdrop\*(Aq | \*(Aqr\*(Aq | \*(Aqread\*(Aq | \*(Aqw\*(Aq | \*(Aqwrite\*(Aq | \*(Aqrw\*(Aq ) برخی دسترسی‌ها با بعضی قواعد ناسازگارند؛ پایین‌تر را ببینید. .Sp \&\fBUNIX RULE\fR = [ \fIQUALIFIERS\fR ] \*(Aqunix\*(Aq [ \fIUNIX ACCESS EXPR\fR ] [ \fIUNIX RULE CONDS\fR ] [ \fIUNIX LOCAL EXPR\fR ] [ \fIUNIX PEER EXPR\fR ] .Sp \&\fBUNIX ACCESS EXPR\fR = ( \fIUNIX ACCESS\fR | \fIUNIX ACCESS LIST\fR ) .Sp \&\fBUNIX ACCESS\fR = ( \*(Aqcreate\*(Aq | \*(Aqbind\*(Aq | \*(Aqlisten\*(Aq | \*(Aqaccept\*(Aq | \*(Aqconnect\*(Aq | \*(Aqshutdown\*(Aq | \*(Aqgetattr\*(Aq | \*(Aqsetattr\*(Aq | \*(Aqgetopt\*(Aq | \*(Aqsetopt\*(Aq | \*(Aqsend\*(Aq | \*(Aqreceive\*(Aq | \*(Aqr\*(Aq | \*(Aqw\*(Aq | \*(Aqrw\*(Aq ) برخی حالت‌های دسترسی با بعضی قواعد ناسازگارند یا به پارامترهای اضافی نیاز دارند. .Sp \&\fBUNIX ACCESS LIST\fR = \*(Aq(\*(Aq \fIUNIX ACCESS\fR ( [\*(Aq,\*(Aq] \fIUNIX ACCESS\fR )* \*(Aq)\*(Aq .Sp \&\fBUNIX RULE CONDS\fR = ( \fITYPE COND\fR | \fIPROTO COND\fR ) هر شرط حداکثر می‌تواند یک بار ظاهر شود. .Sp \&\fBTYPE COND\fR = \*(Aqtype\*(Aq \*(Aq=\*(Aq ( \fIAARE\fR | \*(Aq(\*(Aq ( \*(Aq"\*(Aq \fIAARE\fR \*(Aq"\*(Aq | \fIAARE\fR )+ \*(Aq)\*(Aq ) .Sp \&\fBPROTO COND\fR = \*(Aqprotocol\*(Aq \*(Aq=\*(Aq ( \fIAARE\fR | \*(Aq(\*(Aq ( \*(Aq"\*(Aq \fIAARE\fR \*(Aq"\*(Aq | \fIAARE\fR )+ \*(Aq)\*(Aq ) .Sp \&\fBUNIX LOCAL EXPR\fR = ( \fIUNIX ADDRESS COND\fR | \fIUNIX LABEL COND\fR | \fIUNIX ATTR COND\fR | \fIUNIX OPT COND\fR )* هر شرط حداکثر می‌تواند یک بار ظاهر شود. .Sp \&\fBUNIX PEER EXPR\fR = \*(Aqpeer\*(Aq \*(Aq=\*(Aq ( \fIUNIX ADDRESS COND\fR | \fIUNIX LABEL COND\fR )+ هر شرط حداکثر می‌تواند یک بار ظاهر شود. .Sp \&\fBUNIX ADDRESS COND\fR \*(Aqaddr\*(Aq \*(Aq=\*(Aq ( \fIAARE\fR | \*(Aq(\*(Aq \*(Aq"\*(Aq \fIAARE\fR \*(Aq"\*(Aq | \fIAARE\fR \*(Aq)\*(Aq ) .Sp \&\fBUNIX LABEL COND\fR \*(Aqlabel\*(Aq \*(Aq=\*(Aq ( \fIAARE\fR | \*(Aq(\*(Aq \*(Aq"\*(Aq \fIAARE\fR \*(Aq"\*(Aq | \fIAARE\fR \*(Aq)\*(Aq ) .Sp \&\fBUNIX ATTR COND\fR \*(Aqattr\*(Aq \*(Aq=\*(Aq ( \fIAARE\fR | \*(Aq(\*(Aq \*(Aq"\*(Aq \fIAARE\fR \*(Aq"\*(Aq | \fIAARE\fR \*(Aq)\*(Aq ) .Sp \&\fBUNIX OPT COND\fR \*(Aqopt\*(Aq \*(Aq=\*(Aq ( \fIAARE\fR | \*(Aq(\*(Aq \*(Aq"\*(Aq \fIAARE\fR \*(Aq"\*(Aq | \fIAARE\fR \*(Aq)\*(Aq ) .Sp \&\fBRLIMIT RULE\fR = \*(Aqset\*(Aq \*(Aqrlimit\*(Aq [\fIRLIMIT\fR \*(Aq<=\*(Aq \fIRLIMIT VALUE\fR ] .Sp \&\fBRLIMIT\fR = ( \*(Aqcpu\*(Aq | \*(Aqfsize\*(Aq | \*(Aqdata\*(Aq | \*(Aqstack\*(Aq | \*(Aqcore\*(Aq | \*(Aqrss\*(Aq | \*(Aqnofile\*(Aq | \*(Aqofile\*(Aq | \*(Aqas\*(Aq | \*(Aqnproc\*(Aq | \*(Aqmemlock\*(Aq | \*(Aqlocks\*(Aq | \*(Aqsigpending\*(Aq | \*(Aqmsgqueue\*(Aq | \*(Aqnice\*(Aq | \*(Aqrtprio\*(Aq | \*(Aqrttime\*(Aq ) .Sp \&\fBRLIMIT VALUE\fR = ( \fIRLIMIT SIZE\fR | \fIRLIMIT NUMBER\fR | \fIRLIMIT TIME\fR | \fIRLIMIT NICE\fR ) .Sp \&\fBRLIMIT SIZE\fR = \fINUMBER\fR ( \*(AqK\*(Aq | \*(AqM\*(Aq | \*(AqG\*(Aq ) تنها برای RLIMITهای \*(Aqfsize\*(Aq، \*(Aqdata\*(Aq، \*(Aqstack\*(Aq، \*(Aqcore\*(Aq، \*(Aqrss\*(Aq، \*(Aqas\*(Aq، \*(Aqmemlock\*(Aq و \*(Aqmsgqueue\*(Aq اعمال می‌شود. .Sp \&\fBRLIMIT NUMBER\fR = عددی از 0 تا حداکثر مقدار rlimit. تنها برای RLIMITهای \*(Aqofile\*(Aq، \*(Aqnofile\*(Aq، \*(Aqlocks\*(Aq، \*(Aqsigpending\*(Aq، \*(Aqnproc\*(Aq و \*(Aqrtprio\*(Aq اعمال می‌شود. .Sp \&\fBRLIMIT TIME\fR = \fINUMBER\fR ( \*(Aqus\*(Aq | \*(Aqmicrosecond\*(Aq | \*(Aqmicroseconds\*(Aq | \*(Aqms\*(Aq | \*(Aqmillisecond\*(Aq | \*(Aqmilliseconds\*(Aq | \*(Aqs\*(Aq | \*(Aqsec\*(Aq | \*(Aqsecond\*(Aq | \*(Aqseconds\*(Aq | \*(Aqmin\*(Aq | \*(Aqminute\*(Aq | \*(Aqminutes\*(Aq | \*(Aqh\*(Aq | \*(Aqhour\*(Aq | \*(Aqhours\*(Aq | \*(Aqd\*(Aq | \*(Aqday\*(Aq | \*(Aqdays\*(Aq | \*(Aqweek\*(Aq | \*(Aqweeks\*(Aq ) تنها برای RLIMITهای \*(Aqcpu\*(Aq و \*(Aqrttime\*(Aq اعمال می‌شود. برای RLIMIT \*(Aqcpu\*(Aq تنها واحدهای >= \*(Aqseconds\*(Aq مجاز هستند. .Sp \&\fBRLIMIT NICE\fR = عددی بین \-20 و 19. تنها برای RLIMIT \*(Aqnice\*(Aq اعمال می‌شود. .Sp \&\fBFILE RULE\fR = [ \fIQUALIFIERS\fR ] [ \*(Aqowner\*(Aq ] ( \*(Aqfile\*(Aq | [ \*(Aqfile\*(Aq ] ( \fIFILEGLOB\fR \fIACCESS\fR | \fIACCESS\fR \fIFILEGLOB\fR ) [ \*(Aq\->\*(Aq \fIEXEC TARGET\fR ] ) .Sp \&\fBFILEGLOB\fR = ( \fIQUOTED FILEGLOB\fR | \fIUNQUOTED FILEGLOB\fR ) .Sp \&\fBQUOTED FILEGLOB\fR = \*(Aq"\*(Aq \fIUNQUOTED FILEGLOB\fR \*(Aq"\*(Aq .Sp \&\fBUNQUOTED FILEGLOB\fR = (باید پس از بسط متغیر با \*(Aq/\*(Aq آغاز شود؛ \fBAARE\fRها دارای معانی خاص هستند؛ پایین‌تر را ببینید. می‌تواند شامل \fIVARIABLE\fR باشد. قواعد دارای فاصله یا تب تعبیه‌شده باید داخل کوتیشن باشند. قواعد برای اعمال بر دایرکتوری‌ها باید به \*(Aq/\*(Aq ختم شوند.) .Sp \&\fBAARE\fR = \fB?*[]{}^\fR برای معانی، بخش "Globbing (AARE)" در زیر را ببینید. .Sp \&\fBACCESS\fR = ( \*(Aqr\*(Aq | \*(Aqw\*(Aq | \*(Aqa\*(Aq | \*(Aql\*(Aq | \*(Aqk\*(Aq | \*(Aqm\*(Aq | \fIEXEC TRANSITION\fR )+ (همه ترکیبات مجاز نیستند؛ پایین‌تر را ببینید.) .Sp \&\fBEXEC TRANSITION\fR = ( \*(Aqix\*(Aq | \*(Aqux\*(Aq | \*(AqUx\*(Aq | \*(Aqpx\*(Aq | \*(AqPx\*(Aq | \*(Aqcx\*(Aq | \*(AqCx\*(Aq | \*(Aqpix\*(Aq | \*(AqPix\*(Aq | \*(Aqcix\*(Aq | \*(AqCix\*(Aq | \*(Aqpux\*(Aq | \*(AqPUx\*(Aq | \*(Aqcux\*(Aq | \*(AqCUx\*(Aq | \*(Aqx\*(Aq ) یک \*(Aqx\*(Aq تنها در قواعد دارای توصیف‌کننده deny مجاز است، بقیه موارد تنها بدون توصیف‌کننده deny مجاز هستند. .Sp \&\fBEXEC TARGET\fR = name نیازمند تعیین \fIEXEC TRANSITION\fR است. .Sp \&\fBLINK RULE\fR = \fIQUALIFIERS\fR [ \*(Aqowner\*(Aq ] \*(Aqlink\*(Aq [ \*(Aqsubset\*(Aq ] \fIFILEGLOB\fR \*(Aq\->\*(Aq \fIFILEGLOB\fR .Sp \&\fBALPHA\fR = (\*(Aqa\*(Aq, \*(Aqb\*(Aq, \*(Aqc\*(Aq, ... \*(Aqz\*(Aq, \*(AqA\*(Aq, \*(AqB\*(Aq, ... \*(AqZ\*(Aq) .Sp \&\fBALPHANUMERIC\fR = (\*(Aq0\*(Aq, \*(Aq1\*(Aq, \*(Aq2\*(Aq, ... \*(Aq9\*(Aq, \*(Aqa\*(Aq, \*(Aqb\*(Aq, \*(Aqc\*(Aq, ... \*(Aqz\*(Aq, \*(AqA\*(Aq, \*(AqB\*(Aq, ... \*(AqZ\*(Aq) .Sp \&\fBCHANGE_PROFILE RULE\fR = \*(Aqchange_profile\*(Aq [ [ \fIEXEC MODE\fR ] \fIEXEC COND\fR ] [ \*(Aq\->\*(Aq \fIPROFILE NAME\fR ] .Sp \&\fBEXEC_MODE\fR = ( \*(Aqsafe\*(Aq | \*(Aqunsafe\*(Aq ) .Sp \&\fBEXEC COND\fR = \fIFILEGLOB\fR .Sp \&\fBALL RULE\fR = \*(Aqall\*(Aq .RE .PP تمام منابع و برنامه‌ها به یک مسیر کامل (full path) نیاز دارند. ممکن است هر تعداد زیرپروفایل (پروفایل‌های فرزند یا child profiles) در یک پروفایل وجود داشته باشد، که تنها توسط حافظه هسته محدود می‌شود. نام زیرپروفایل‌ها به ۹۷۴ نویسه محدود است. پروفایل‌های فرزند می‌توانند برای محدودسازی یک برنامه به روشی ویژه استفاده شوند، یا زمانی که می‌خواهید فرزند روی سیستم بدون محدودیت (\fIunconfined\fR) باشد، اما هنگام فراخوانی از والد محدود گردد. کلاه‌ها (Hats) یک پروفایل فرزند ویژه هستند که می‌توانند با فراخوانی \fBaa_change_hat\fR\|(2) API استفاده شوند. برنامه‌هایی که برای استفاده از \fBaa_change_hat\fR\|(2) نوشته یا اصلاح شده‌اند، می‌توانند از زیرپروفایل‌ها بهره ببرند تا بسته به منطق برنامه تحت محدودیت‌های متفاوتی اجرا شوند. چندین برنامه آگاه از \fBaa_change_hat\fR\|(2) وجود دارد، از جمله یک ماژول آپاچی به نام \fBmod_apparmor\fR\|(5)؛ یک ماژول PAM به نام pam_apparmor؛ و یک Tomcat valve به نام tomcat_apparmor. برنامه‌هایی که برای استفاده از \fBchange_profile\fR\|(2) نوشته یا اصلاح شده‌اند، به طور دائمی به پروفایل مشخص‌شده منتقل می‌شوند. libvirt یکی از این برنامه‌ها است. .SS "سرآیند پروفایل (Profile Head)" .IX Subsection "Profile Head" سرآیند پروفایل از یک نام الزامی که یکتا است و شروط اتصال اختیاری و پرچم‌های کنترلی تشکیل شده است. .PP \fIName (نام)\fR .IX Subsection "Name" .PP نام پروفایل شناسه آن است. این همان چیزی است که در طول درون‌نگری (مانند ps \-Z) نمایش داده می‌شود، و نحوه ارجاع به پروفایل توسط قوانین خط‌مشی را برای هرگونه تعامل خط‌مشی از طریق ipc یا تغییرات دامنه تعیین می‌کند. توصیه می‌شود نام کوتاه نگه داشته شود و برای برنامه‌ای که روی آن اعمال می‌شود معنی‌دار باشد، مانند \fIfirefox\fR برای مرورگر وب firefox یا نقش عملکردی آن مانند log_admin. .PP اگر نام یک مسیر مطلق و کامل برنامه باشد، مانند \fI/usr/bin/firefox\fR و یک شرط اتصال اجرایی (exec attachment conditional) مشخص نشده باشد، این نام به عنوان شرط اتصال اجرایی پروفایل نیز استفاده می‌شود. با این حال، این کاربرد منسوخ شده و توصیه نمی‌شود زیرا باعث ایجاد نام‌های طولانی می‌شود که می‌تواند درک قوانین پروفایل را دشوار سازد، و ممکن است توسط برخی از ابزارهای درون‌نگری به‌طور کامل نمایش داده نشود. .PP \fIAttachment Conditionals (شروط اتصال)\fR .IX Subsection "Attachment Conditionals" .PP شروط اتصال در طول تغییرات پروفایل برای تعیین اینکه آیا یک پروفایل با انتقال پروفایل پیشنهادی مطابقت دارد یا خیر استفاده می‌شوند. شروط اتصال اختیاری هستند، نحوه و زمان اعمال آن‌ها توسط شرط (یا شروط) خاص استفاده‌شده تعیین می‌شود. .PP هنگامی که از شروط اتصال استفاده می‌شود، شروط اتصال برای تمام پروفایل‌های موجود در فضای نام ارزیابی خواهند شد. پروفایلی که مجموعه‌ای از اتصالات با بهترین تطابق را داشته باشد، پس از عملیات انتقال به پروفایل جدید تبدیل خواهد شد. اتصالاتی که مطابقت ندارند باعث می‌شوند پروفایل برای انتقال در دسترس نباشد. .PP اگر هیچ شرطی مشخص نشود، پروفایل تنها در صورتی استفاده خواهد شد که یک انتقال به‌طور صریح نام پروفایل را مشخص کند. .PP شرط اتصال اجرایی (Exec Attachment Conditional) .IX Subsection "Exec Attachment Conditional" .PP شرط اتصال اجرایی مشخص می‌کند که پروفایل تا چه حد با یک برنامه اجرایی مطابقت دارد. این شرط تنها در طول یک عملیات exec استفاده می‌شود که قانون exec منطبق، نوع انتقال \fBpx\fR یا \fBcx\fR (یا مشتقات آن‌ها) را مشخص کرده باشد. شرط اتصال اجرایی همچنین توسط وظایفی که \fIunconfined\fR هستند استفاده خواهد شد زیرا آن‌ها از قانون انتقال \fBpix\fR استفاده می‌کنند. .PP اگر هیچ تطابق اتصالی وجود نداشته باشد، تعیین آنچه رخ می‌دهد (شکست یا یک گزینه جایگزین) بر عهده قانون exec است. .PP نکته: برای اطلاعات پیرامون استفاده از نام پروفایل به عنوان شرط اتصال، بخش \fIName\fR پروفایل را ببینید. .PP شروط اتصال اجرایی می‌توانند شامل نام‌های متغیر و تطبیق الگو باشند. آن‌ها از روش ابتکاری طولانی‌ترین تطابق از چپ (longest left match heuristic) برای تعیین برنده در صورت تطابق‌های چندگانه در زمان اجرا استفاده می‌کنند. پیاده‌سازی دقیق این تفکیک مختص هسته است و با گذشت زمان بهبود یافته است، در حالی که سازگاری با گذشته حفظ شده است. اگر روش ابتکاری نتواند برنده را از میان تطابق‌های چندگانه تعیین کند، عملیات exec رد خواهد شد. .PP شرط اتصال صفات گسترش‌یافته (Extended Attributes Attachment Conditional) .IX Subsection "Extended Attributes Attachment Conditional" .PP پروفایل‌های AppArmor علاوه بر مسیر فایل‌ها، توانایی هدف قرار دادن آن‌ها را بر اساس مقادیر \fBxattr\fR\|(7) دارند. به عنوان مثال، پروفایل زیر با فایل‌های موجود در /usr/bin با صفت "security.apparmor" و مقدار "trusted" مطابقت دارد: .PP .Vb 3 \& /usr/bin/* xattrs(security.apparmor="trusted") { \& # ... \& } .Ve .PP برای جزئیات بیشتر به \fBapparmor_xattrs\fR\|(7) مراجعه کنید. .PP \fIFlags (پرچم‌ها)\fR .IX Subsection "Flags" .PP پرچم‌های پروفایل اجازه می‌دهند رفتار پروفایل تغییر داده شود. اگر یک پرچم پروفایل مشخص شود، بر هر پرچم متناقضی که توسط قوانین در بدنه پروفایل مشخص شده است اولویت دارد. .PP حالت پروفایل (Profile Mode) .IX Subsection "Profile Mode" .PP حالت پروفایل امکان کنترل رفتار اعمال قوانین پروفایل را فراهم می‌کند. .PP اگر هیچ حالتی مشخص نشود، پروفایل به صورت پیش‌فرض در حالت \fIenforce\fR قرار می‌گیرد. .IP "\fBenforce\fR برای یک عمل معین، اگر قوانین پروفایل مجوز را اعطا نکنند، عمل رد خواهد شد، کد خطای \fIEACCES\fR یا \fIEPERM\fR به فضای کاربری برگردانده می‌شود، و تخلف با برچسب دسترسی \fBDENIED\fR ثبت خواهد شد." 8 .IX Item "enforce For a given action, if the profile rules do not grant permission the action will be denied, with an EACCES or EPERM error code returned to userspace, and the violation will be logged with a tag of the access being DENIED." .PD 0 .IP "\fBkill\fR این یک نوع از حالت enforce است که علاوه بر بازگرداندن \fIEACCES\fR یا \fIEPERM\fR برای یک تخلف، سیگنالی نیز برای کشتن وظیفه ارسال می‌شود." 8 .IX Item "kill This is a variant of enforce mode where in addition to returning EACCES or EPERM for a violation, the task is also sent a signal to kill it." .IP "\fBcomplain\fR برای یک عمل معین، اگر قوانین پروفایل مجوز را اعطا نکنند، عمل مجاز خواهد بود، اما تخلف با برچسب دسترسی \fBALLOWED\fR ثبت خواهد شد." 8 .IX Item "complain For a given action, if the profile rules do not grant permission the action will be allowed, but the violation will be logged with a tag of the access being ALLOWED." .IP "\fBdefault_allow\fR این حالت رفتار پیش‌فرض apparmor را از رد پیش‌فرض به مجاز پیش‌فرض تغییر می‌دهد. هنگامی که default_allow مشخص شود، پروفایل حاصل عملیاتی را که قانونی برای آن ندارد مجاز می‌داند. این حالت مشابه \fIunconfined\fR است اما امکان استفاده از قوانین allow و deny، مشخص کردن audit، و انتقال‌های دامنه را فراهم می‌کند. پروفایل‌ها در این حالت ممکن است هنگام درون‌نگری از هسته، به عنوان حالت \fIenforce\fR یا حالت \fIallow\fR گزارش شوند." 8 .IX Item "default_allow This mode changes the default behavior of apparmor from default deny to default allow. When default_allow is specified the resulting profile will allow operations that the profile does not have a rule for. This mode is similar to unconfined but allows for allow and deny rules, specifying audit, and domain transitions. Profiles in this mode may be be reported as being in enforce mode or allow mode when introspected from the kernel." .PD نکته: default_allow مشابه است و برای بسیاری از پروفایل‌ها معادل مشخص کردن یک قانون \fIallow all,\fR در پروفایل خواهد بود. پرچم default_allow تمام گزینه‌هایی را که قانون \fIallow all,\fR ارائه می‌دهد، فراهم نمی‌کند. .IP "\fBunconfined\fR این حالت به وظیفه‌ای که توسط پروفایل محدود شده اجازه می‌دهد به گونه‌ای رفتار کند که گویی \fIunconfined\fR است. رفتار نامحدود را می‌توان بعداً با استفاده از جایگزینی پروفایل به محدودیت تغییر داد. این حالت نباید در استقرار عادی استفاده شود اما می‌تواند در طول اشکال‌زدایی و برخی سناریوهای مقداردهی اولیه سیستم مفید باشد." 8 .IX Item "unconfined This mode allows a task confined by the profile to behave as though it is unconfined. The unconfined behavior can be later changed to confinement by using profile replacement. This mode should not be used under regular deployment but can be useful during debugging and some system initialization scenarios." این حالت شبیه default_allow است و ممکن است توسط default_allow در هسته‌هایی که دیگر از حالت unconfined واقعی پشتیبانی نمی‌کنند شبیه‌سازی شود. این حالت عموماً اجازه تعیین قوانین deny، یا قوانین allow که رفتار پیش‌فرض را لغو می‌کنند نمی‌دهد، مگر در چند هسته سفارشی که unconfined چند عملیات را محدود می‌کند. این حالت به رفتار سفارشی ویژه پروفایل unconfined در هسته متکی است و بنابراین فقط باید برای اشکال‌زدایی استفاده شود. .Sp نکته: حالت unconfined واقعی در حال کنار گذاشته شدن است و unconfined به یک پروفایل قابل جایگزینی تبدیل می‌شود. به این ترتیب، حالت unconfined توسط یک پروفایل ویژه که با پرچم default_allow کامپایل شده است در هسته‌های جدیدتر شبیه‌سازی خواهد شد. .IP "\fBprompt\fR این حالت به میانجی‌گری وظیفه اجازه می‌دهد تا در صورت عدم وجود قانونی که درخواست مجوز را پوشش دهد، یک فراخوانی رو به بالا (up call) به فضای کاربری بفرستد تا تصمیم‌گیری شود. اگر فضای کاربری پاسخ ندهد، دسترسی رد خواهد شد." 8 .IX Item "prompt This mode allows task mediation to send an up call to userspace to ask for a decision when there isn't a rule covering the permission request. If userspace does not respond then the access will be denied." .PP حالت بازرسی (Audit Mode) .IX Subsection "Audit Mode" .PP حالت بازرسی امکان کنترل نحوه ثبت پیام‌های AppArmor در سیستم بازرسی (audit) را فراهم می‌کند. .IP "\fBaudit\fR این پرچم باعث می‌شود تمام اقدامات اعم از مجاز یا رد شده ثبت (log) شوند." 8 .IX Item "audit This flag causes all actions whether allowed or denied to be logged." .PP حالت‌های متفرقه (Misc modes) .IX Subsection "Misc modes" .IP "\fBmediate_deleted\fR این گزینه AppArmor را مجبور می‌کند فایل‌های حذف‌شده را طوری میانجی‌گری کند که گویی هنوز در سیستم‌فایل وجود دارند." 8 .IX Item "mediate_deleted This forces AppArmor to mediate deleted files as if they still exist in the file system." .PD 0 .IP "\fBattach_disconnected\fR این گزینه AppArmor را مجبور می‌کند اشیاء قطع‌شده را به فضای نام وظیفه متصل کرده و آن‌ها را طوری میانجی‌گری کند که گویی بخشی از فضای نام هستند. هشدار: این حالت ناامن است و می‌تواند منجر به نام مستعار (aliasing) و دسترسی به اشیایی شود که نباید مجاز باشند. هدف آن ابزاری برای اشکال‌زدایی و توسعه خط‌مشی است." 8 .IX Item "attach_disconnected This forces AppArmor to attach disconnected objects to the task's namespace and mediate them as though they are part of the namespace. WARNING this mode is unsafe and can result in aliasing and access to objects that should not be allowed. Its intent is a debug and policy development tool." .IP "\fBattach_disconnected.path\fR=\fIABS PATH\fR مانند attach_disconnected است، اما اشیاء قطع‌شده را به جای ریشه فضای نام، به مسیر ارائه‌شده متصل می‌کند." 8 .IX Item "attach_disconnected.path=ABS PATH Like attach_disconnected, but attach disconnected objects to the supplied path instead of the root of the namespace." .IP "\fBchroot_relative\fR این گزینه نام فایل‌ها را نسبت به یک chroot اجبار می‌کند و طوری رفتار می‌کند که گویی chroot یک فضای نام اتصال (mount namespace) است." 8 .IX Item "chroot_relative This forces file names to be relative to a chroot and behave as if the chroot is a mount namespace." .IP "\fBdebug\fR این پرچم امکان فعال کردن پیام‌های اشکال‌زدایی هسته را بر اساس هر پروفایل فراهم می‌کند. این گزینه در ارتباط با سایر پرچم‌های اشکال‌زدایی هسته برای کنترل پیام‌های خروجی کار می‌کند. تأثیر آن وابسته به هسته است و هرگز نباید در خط‌مشی ظاهر شود مگر هنگام تلاش برای اشکال‌زدایی مشکلات هسته یا خط‌مشی." 8 .IX Item "debug This flag allows turning on kernel debug messages on a per profile basis. It works in conjunction with other kernel debug flags to control what messages will be output. Its effect is kernel dependent, and it should never appear in policy except when trying to debug kernel or policy problems." .IP "\fBinterruptible\fR وقفه‌ها را برای درخواست prompt به فضای کاربری فعال می‌کند." 8 .IX Item "interruptible Enables interrupts for prompt upcall to userspace." .IP "\fBkill.signal\fR=\fISIGNAL\fR سیگنالی را تغییر می‌دهد که توسط AppArmor در حالت kill یا در صورت نقض یک قانون kill ارسال خواهد شد." 8 .IX Item "kill.signal=SIGNAL This changes the signal that will be sent by AppArmor when in kill mode or a kill rule has been violated." .IP "\fBerror\fR=\fIERROR CODE\fR کد خطای بازگردانده شده توسط AppArmor را هنگام نقض یک قانون تغییر می‌دهد." 8 .IX Item "error=ERROR CODE This changes the error code returned by AppArmor when a rule has been violated." .PD .SS "حالت‌های دسترسی (Access Modes)" .IX Subsection "Access Modes" حالت‌های دسترسی مجوز فایل از ترکیبی از حالت‌های زیر تشکیل شده‌اند: .IP \fBr\fR 8 .IX Item "r" \&\- خواندن (read) .IP \fBw\fR 8 .IX Item "w" \&\- نوشتن (write) \-\- با append تداخل دارد .IP \fBa\fR 8 .IX Item "a" \&\- الحاق (append) \-\- با write تداخل دارد .IP \fBux\fR 8 .IX Item "ux" \&\- اجرای نامحدود (unconfined execute) .IP \fBUx\fR 8 .IX Item "Ux" \&\- اجرای نامحدود \-\- پاکسازی محیط (scrub the environment) .IP \fBpx\fR 8 .IX Item "px" \&\- اجرای پروفایل گسسته (discrete profile execute) .IP \fBPx\fR 8 .IX Item "Px" \&\- اجرای پروفایل گسسته \-\- پاکسازی محیط .IP \fBcx\fR 8 .IX Item "cx" \&\- انتقال به زیرپروفایل هنگام اجرا .IP \fBCx\fR 8 .IX Item "Cx" \&\- انتقال به زیرپروفایل هنگام اجرا \-\- پاکسازی محیط .IP \fBix\fR 8 .IX Item "ix" \&\- اجرای موروثی (inherit execute) .IP \fBpix\fR 8 .IX Item "pix" \&\- اجرای پروفایل گسسته با جایگزین موروثی .IP \fBPix\fR 8 .IX Item "Pix" \&\- اجرای پروفایل گسسته با جایگزین موروثی \-\- پاکسازی محیط .IP \fBcix\fR 8 .IX Item "cix" \&\- انتقال به زیرپروفایل هنگام اجرا با جایگزین موروثی .IP \fBCix\fR 8 .IX Item "Cix" \&\- انتقال به زیرپروفایل هنگام اجرا با جایگزین موروثی \-\- پاکسازی محیط .IP \fBpux\fR 8 .IX Item "pux" \&\- اجرای پروفایل گسسته با جایگزین نامحدود (unconfined) .IP \fBPUx\fR 8 .IX Item "PUx" \&\- اجرای پروفایل گسسته با جایگزین نامحدود \-\- پاکسازی محیط .IP \fBcux\fR 8 .IX Item "cux" \&\- انتقال به زیرپروفایل هنگام اجرا با جایگزین نامحدود .IP \fBCUx\fR 8 .IX Item "CUx" \&\- انتقال به زیرپروفایل هنگام اجرا با جایگزین نامحدود \-\- پاکسازی محیط .IP "\fBdeny x\fR" 8 .IX Item "deny x" \&\- عدم اجازه اجرا (در قوانینی با توصیف‌کننده deny) .IP \fBm\fR 8 .IX Item "m" \&\- مجاز شمردن PROT_EXEC با فراخوانی‌های \fBmmap\fR\|(2) .IP \fBl\fR 8 .IX Item "l" \&\- پیوند (link) .IP \fBk\fR 8 .IX Item "k" \&\- قفل (lock) .SS "جزئیات حالت‌های دسترسی (Access Modes Details)" .IX Subsection "Access Modes Details" .IP "\fBr \- حالت خواندن (Read mode)\fR" 4 .IX Item "r - Read mode" به برنامه امکان دسترسی خواندن به فایل یا فهرست دایرکتوری را می‌دهد. دسترسی خواندن برای اسکریپت‌های شل و سایر محتواهای تفسیرشده لازم است. .IP "\fBw \- حالت نوشتن (Write mode)\fR" 4 .IX Item "w - Write mode" به برنامه امکان دسترسی نوشتن به فایل را می‌دهد. فایل‌ها و دایرکتوری‌ها باید این مجوز را داشته باشند تا بتوان آن‌ها را حذف (unlink) کرد. حالت نوشتن روی یک دایرکتوری برای تغییر نام یا ایجاد فایل‌ها در داخل آن دایرکتوری لازم نیست. .Sp این حالت با حالت الحاق (append) تداخل دارد. .IP "\fBa \- حالت الحاق (Append mode)\fR" 4 .IX Item "a - Append mode" به برنامه دسترسی محدود نوشتن فقط از نوع الحاق به فایل را می‌دهد. حالت الحاق از باز کردن فایل برای نوشتن توسط برنامه جلوگیری می‌کند مگر اینکه هنگام باز کردن، پرچم پارامتر O_APPEND ارسال شود. .Sp این حالت با حالت نوشتن تداخل دارد. .IP "\fBux \- حالت اجرای نامحدود (Unconfined execute mode)\fR" 4 .IX Item "ux - Unconfined execute mode" به برنامه اجازه می‌دهد برنامه را بدون اعمال هیچ‌گونه پروفایل AppArmor روی آن اجرا کند. .Sp این حالت زمانی مفید است که یک برنامه محدودشده نیاز به انجام یک عملیات ممتاز (مانند راه‌اندازی مجدد دستگاه) داشته باشد. با قرار دادن بخش ممتاز در یک فایل اجرایی دیگر و اعطای حقوق اجرای نامحدود، امکان دور زدن محدودیت‌های اجباری اعمال‌شده بر تمام فرآیندهای محدودشده وجود دارد. برای اطلاعات بیشتر در مورد آنچه محدود شده است، به صفحه راهنمای \fBapparmor\fR\|(7) مراجعه کنید. .Sp \&\fBهشدار\fR: \*(Aqux\*(Aq فقط باید در موارد بسیار خاص استفاده شود. این گزینه امکان اجرای فرآیندهای فرزند تعیین‌شده را بدون هیچ‌گونه محافظت AppArmor فراهم می‌کند. \*(Aqux\*(Aq متغیرهایی مانند LD_PRELOAD را از محیط پاکسازی نمی‌کند؛ در نتیجه، دامنه فراخوان ممکن است نفوذ ناروایی بر فراخوانده‌شده داشته باشد. از این حالت تنها در صورتی استفاده کنید که فرزند حتماً باید به صورت نامحدود اجرا شود و LD_PRELOAD باید استفاده شود. هر پروفایلی که از این حالت استفاده کند امنیت بسیار ناچیزی ارائه می‌دهد. استفاده با مسئولیت خودتان است. .Sp ناسازگار با سایر حالت‌های انتقال exec و توصیف‌کننده deny. .IP "\fBUx \- اجرای نامحدود \-\- پاکسازی محیط (unconfined execute \-\- scrub the environment)\fR" 4 .IX Item "Ux - unconfined execute -- scrub the environment" \&\*(AqUx\*(Aq به برنامه نام‌برده اجازه می‌دهد در حالت \*(Aqux\*(Aq اجرا شود، اما AppArmor روال‌های \fBunsafe_exec\fR هسته لینوکس را برای پاکسازی محیط فراخوانی می‌کند، مشابه برنامه‌های setuid. (برای برخی اطلاعات درباره پاکسازی محیط setuid/setgid به \fBld.so\fR\|(8) مراجعه کنید.) .Sp \&\fBهشدار\fR: \*(AqUx\*(Aq فقط باید در موارد بسیار خاص استفاده شود. این گزینه امکان اجرای فرآیندهای فرزند تعیین‌شده را بدون هیچ‌گونه محافظت AppArmor فراهم می‌کند. از این حالت تنها در صورتی استفاده کنید که فرزند حتماً باید به صورت نامحدود اجرا شود. استفاده با مسئولیت خودتان است. .Sp ناسازگار با سایر حالت‌های انتقال exec و توصیف‌کننده deny. .IP "\fBpx \- حالت اجرای پروفایل گسسته (Discrete Profile execute mode)\fR" 4 .IX Item "px - Discrete Profile execute mode" این حالت مستلزم آن است که یک پروفایل امنیتی گسسته برای برنامه اجراشده تعریف شده باشد و انتقال دامنه AppArmor را اجبار می‌کند. اگر هیچ پروفایلی تعریف نشده باشد، دسترسی رد خواهد شد. .Sp \&\fBهشدار\fR: \*(Aqpx\*(Aq متغیرهایی مانند LD_PRELOAD را از محیط پاکسازی نمی‌کند؛ در نتیجه، دامنه فراخوان ممکن است نفوذ ناروایی بر فراخوانده‌شده داشته باشد. .Sp ناسازگار با سایر حالت‌های انتقال exec و توصیف‌کننده deny. .IP "\fBPx \- حالت اجرای پروفایل گسسته \-\- پاکسازی محیط (Discrete Profile execute mode \-\- scrub the environment)\fR" 4 .IX Item "Px - Discrete Profile execute mode -- scrub the environment" \&\*(AqPx\*(Aq به برنامه نام‌برده اجازه می‌دهد در حالت \*(Aqpx\*(Aq اجرا شود، اما AppArmor روال‌های \fBunsafe_exec\fR هسته لینوکس را برای پاکسازی محیط فراخوانی می‌کند، مشابه برنامه‌های setuid. (برای برخی اطلاعات درباره پاکسازی محیط setuid/setgid به \fBld.so\fR\|(8) مراجعه کنید.) .Sp ناسازگار با سایر حالت‌های انتقال exec و توصیف‌کننده deny. .IP "\fBcx \- حالت اجرای انتقال به زیرپروفایل (Transition to Subprofile execute mode)\fR" 4 .IX Item "cx - Transition to Subprofile execute mode" این حالت مستلزم آن است که یک پروفایل امنیتی محلی تعریف شده باشد و انتقال دامنه AppArmor به پروفایل نام‌برده را اجبار می‌کند. اگر هیچ پروفایلی تعریف نشده باشد، دسترسی رد خواهد شد. .Sp \&\fBهشدار\fR: \*(Aqcx\*(Aq متغیرهایی مانند LD_PRELOAD را از محیط پاکسازی نمی‌کند؛ در نتیجه، دامنه فراخوان ممکن است نفوذ ناروایی بر فراخوانده‌شده داشته باشد. .Sp ناسازگار با سایر حالت‌های انتقال exec و توصیف‌کننده deny. .IP "\fBCx \- حالت اجرای انتقال به زیرپروفایل \-\- پاکسازی محیط (Transition to Subprofile execute mode \-\- scrub the environment)\fR" 4 .IX Item "Cx - Transition to Subprofile execute mode -- scrub the environment" \&\*(AqCx\*(Aq به برنامه نام‌برده اجازه می‌دهد در حالت \*(Aqcx\*(Aq اجرا شود، اما AppArmor روال‌های \fBunsafe_exec\fR هسته لینوکس را برای پاکسازی محیط فراخوانی می‌کند، مشابه برنامه‌های setuid. (برای برخی اطلاعات درباره پاکسازی محیط setuid/setgid به \fBld.so\fR\|(8) مراجعه کنید.) .Sp ناسازگار با سایر حالت‌های انتقال exec و توصیف‌کننده deny. .IP "\fBix \- حالت اجرای موروثی (Inherit execute mode)\fR" 4 .IX Item "ix - Inherit execute mode" هنگامی که برنامه تحت پروفایل، برنامه نام‌برده را اجرا می‌کند، از انتقال عادی دامنه AppArmor در \fBexecve\fR\|(2) جلوگیری می‌کند. در عوض، منبع اجراشده پروفایل فعلی را به ارث خواهد برد. .Sp این حالت زمانی مفید است که یک برنامه محدودشده نیاز به فراخوانی یک برنامه محدودشده دیگر بدون کسب مجوزهای پروفایل مقصد یا از دست دادن مجوزهای پروفایل فعلی داشته باشد. هیچ نسخه‌ای برای پاکسازی محیط وجود ندارد زیرا اجراهای \*(Aqix\*(Aq امتیازات را تغییر نمی‌دهند. .Sp ناسازگار با سایر حالت‌های انتقال exec و توصیف‌کننده deny. .IP "\fBحالت اجرای انتقال پروفایل با جایگزین موروثی (Profile transition with inheritance fallback execute mode)\fR" 4 .IX Item "Profile transition with inheritance fallback execute mode" این حالت‌ها تلاش می‌کنند یک انتقال دامنه را طبق مجوز منطبق (که در زیر نشان داده شده است) انجام دهند و اگر آن انتقال موفق به یافتن پروفایل منطبق نشود، انتقال دامنه با استفاده از حالت انتقال \*(Aqix\*(Aq ادامه می‌یابد. .Sp .Vb 4 \& \*(AqPix\*(Aq == \*(AqPx\*(Aq with fallback to \*(Aqix\*(Aq \& \*(Aqpix\*(Aq == \*(Aqpx\*(Aq with fallback to \*(Aqix\*(Aq \& \*(AqCix\*(Aq == \*(AqCx\*(Aq with fallback to \*(Aqix\*(Aq \& \*(Aqcix\*(Aq == \*(Aqcx\*(Aq with fallback to \*(Aqix\*(Aq .Ve .Sp ناسازگار با سایر حالت‌های انتقال exec و توصیف‌کننده deny. .IP "\fBگذار نمایه با حالت اجرای بازگشت به نامحدود (unconfined fallback)\fR" 4 .IX Item "گذار نمایه با حالت اجرای بازگشت به نامحدود (unconfined fallback)" این حالت‌ها تلاش می‌کنند تا یک گذار دامنه (domain transition) را طبق مجوز منطبق (مشخص‌شده در زیر) انجام دهند، و در صورتی که این گذار موفق به یافتن نمایه منطبق نشود، گذار دامنه با استفاده از حالت گذار \*(Aqux\*(Aq (اگر \*(Aqpux\*(Aq یا \*(Aqcux\*(Aq استفاده شده باشد) یا حالت گذار \*(AqUx\*(Aq (اگر \*(AqPUx\*(Aq یا \*(AqCUx\*(Aq استفاده شده باشد) ادامه می‌یابد. .Sp .Vb 4 \& \*(AqPUx\*(Aq == \*(AqPx\*(Aq with fallback to \*(AqUx\*(Aq \& \*(Aqpux\*(Aq == \*(Aqpx\*(Aq with fallback to \*(Aqux\*(Aq \& \*(AqCUx\*(Aq == \*(AqCx\*(Aq with fallback to \*(AqUx\*(Aq \& \*(Aqcux\*(Aq == \*(Aqcx\*(Aq with fallback to \*(Aqux\*(Aq .Ve .Sp با سایر حالت‌های گذار exec و توصیف‌کننده deny ناسازگار است. .IP "\fBdeny x \- رد اجرای برنامه (Deny execute)\fR" 4 .IX Item "deny x - رد اجرای برنامه (Deny execute)" برای قواعدی که شامل اصلاح‌کننده deny هستند، فقط \*(Aqx\*(Aq برای رد اجرا مجاز است. .Sp حالت‌های \*(Aqix\*(Aq، \*(AqPx\*(Aq، \*(Aqpx\*(Aq، \*(AqCx\*(Aq، \*(Aqcx\*(Aq و حالت‌های بازگشتی (fallback) با اصلاح‌کننده deny تداخل دارند. .IP "\fBگذارهای مستقیم نمایه (Directed profile transitions)\fR" 4 .IX Item "گذارهای مستقیم نمایه (Directed profile transitions)" گذارهای مستقیم نمایه (\*(Aqpx\*(Aq، \*(AqPx\*(Aq، \*(Aqpix\*(Aq، \*(AqPix\*(Aq، \*(Aqpux\*(Aq، \*(AqPUx\*(Aq) و زیرنمایه (\*(Aqcx\*(Aq، \*(AqCx\*(Aq، \*(Aqcix\*(Aq، \*(AqCix\*(Aq، \*(Aqcux\*(Aq، \*(AqCUx\*(Aq) معمولاً نمایه مقصد برای گذار را بر اساس نام فایل اجرایی تعیین می‌کنند. با این حال امکان تعیین مستقیم نام نمایه‌ای که گذار باید از آن استفاده کند وجود دارد. .Sp نام نمایه‌ای که باید به آن گذار انجام شود، با استفاده از \*(Aq\->\*(Aq به همراه نام نمایه مقصد مشخص می‌شود؛ برای مثال: .Sp .Vb 1 \& /bin/** px \-> profile, .Ve .Sp با سایر حالت‌های گذار exec ناسازگار است. .IP "\fBm \- اجازه نگاشت اجرایی (Allow executable mapping)\fR" 4 .IX Item "m - اجازه نگاشت اجرایی (Allow executable mapping)" این حالت به فایل اجازه می‌دهد تا با استفاده از فلگ PROT_EXEC فراخوان سیستمی \fBmmap\fR\|(2) در حافظه نگاشت شود. این فلگ صفحات حافظه را به عنوان قابل اجرا علامت‌گذاری می‌کند؛ این ویژگی در برخی معماری‌ها برای فراهم کردن صفحات داده غیرقابل‌اجرا استفاده می‌شود که می‌تواند تلاش‌های بهره‌برداری امنیتی (exploit) را دشوارتر سازد. AppArmor از این حالت برای محدود کردن فایل‌هایی که یک برنامه خوش‌رفتار (یا تمام برنامه‌ها در معماری‌هایی که کنترل دسترسی به حافظه غیرقابل‌اجرا را اعمال می‌کنند) مجاز است به عنوان کتابخانه استفاده کند بهره می‌برد، تا اثر فلگ‌های نامعتبر \fB\-L\fR داده‌شده به \fBld\fR\|(1) و متغیرهای \fBLD_PRELOAD\fR و \fBLD_LIBRARY_PATH\fR داده‌شده به \fBld.so\fR\|(8) را محدود کند. .IP "\fBl \- حالت پیوند (Link mode)\fR" 4 .IX Item "l - حالت پیوند (Link mode)" به برنامه اجازه می‌دهد تا پیوندی با این نام ایجاد کند. هنگام ایجاد پیوند، پیوند جدید \fBباید\fR زیرمجموعه‌ای از مجوزهای فایل اصلی را داشته باشد (با این استثنا که مقصد نیازی به داشتن دسترسی پیوند ندارد). اگر یک قاعده \*(Aqx\*(Aq روی پیوند جدید وجود داشته باشد، باید دقیقاً با فایل اصلی مطابقت داشته باشد. .IP "\fBk \- حالت قفل کردن (Lock mode)\fR" 4 .IX Item "k - حالت قفل کردن (Lock mode)" به برنامه اجازه می‌دهد تا فایلی با این نام را قفل کند. این مجوز شامل هر دو نوع قفل‌گذاری مشورتی (advisory) و اجباری (mandatory) می‌شود. .IP "\fBمجوزهای دسترسی ابتدایی یا انتهایی (leading OR trailing access permissions)\fR" 4 .IX Item "مجوزهای دسترسی ابتدایی یا انتهایی (leading OR trailing access permissions)" قواعد فایل می‌توانند همراه با مجوز دسترسی در ابتدا یا انتهای الگوی فایل (glob) مشخص شوند؛ برای مثال: .Sp .Vb 1 \& rw /**, # leading permissions \& \& /** rw, # trailing permissions .Ve .Sp هنگامی که از مجوزهای ابتدایی استفاده می‌شود، گزینه‌ها و زمینه‌های بیشتری برای قاعده مجاز خواهد بود؛ برای مثال: .Sp .Vb 1 \& l /foo \-> /bar, # lead \*(Aql\*(Aq link permission is equivalent to link rules .Ve .SS "قواعد پیوند (Link rules)" .IX Subsection "Link rules" قواعد پیوند امکان مشخص کردن مجوز برای ایجاد پیوند سخت (hard link) به صورت یک جفت پیوند\-مقصد را فراهم می‌کنند. اگر شرط subset مشخص شده باشد، در این صورت مجوزهای دسترسی به فایل پیوند باید زیرمجموعه‌ای از مجوزهای نمایه برای دسترسی به فایل مقصد باشد. اگر قاعده \*(Aqx\*(Aq روی پیوند جدید وجود داشته باشد، باید دقیقاً با فایل اصلی مطابقت داشته باشد. .PP برای مثال: .PP .Vb 4 \& /file1 r, \& /file2 rwk, \& /link* rw, \& link subset /link* \-> /**, .Ve .PP قاعده link اجازه ایجاد پیوند از /link به هر دو فایل /file1 یا /file2 را بر اساس نام می‌دهد؛ با این حال از آنجا که فایل /link دارای مجوزهای \*(Aqrw\*(Aq است، ایجاد پیوند به /file1 مجاز نیست زیرا مسیری برای دسترسی به /file1 با مجوزهایی بیشتر از مجوز \*(Aqr\*(Aq تعیین‌شده در نمایه ایجاد خواهد کرد. .PP ایجاد پیوند از /link به /file2 مجاز خواهد بود زیرا مجوزهای \*(Aqrw\*(Aq مربوط به /link زیرمجموعه‌ای از مجوزهای \*(Aqrwk\*(Aq برای /file2 هستند. .PP قاعده link معادل تعیین مجوز پیوند \*(Aql\*(Aq به عنوان یک مجوز ابتدایی بدون هیچ مجوز دسترسی فایل دیگری است. در این حالت می‌توان گزینه‌های قاعده link را مشخص کرد. .PP قاعده link زیر معادل قاعده فایل با مجوز \*(Aql\*(Aq است: .PP .Vb 2 \& link /foo \-> bar, \& l /foo \-> /bar, .Ve .PP قواعد فایلی که مجوز \*(Aql\*(Aq را مشخص کرده و مجوزهای پیوند گسترش‌یافته را تعیین نمی‌کنند، به صورت زیر به قواعد link نگاشت می‌شوند: .PP .Vb 3 \& /foo l, \& l /foo, \& link subset /foo \-> /**, .Ve .SS "توضیحات (Comments)" .IX Subsection "Comments" توضیحات با # شروع می‌شوند و می‌توانند در هر کجای یک خط آغاز شوند. توضیح با پایان خط خاتمه می‌یابد. این شیوه نگارش توضیحات مشابه اسکریپت‌های پوسته (shell scripts) است. .SS "قابلیت‌ها (Capabilities)" .IX Subsection "Capabilities" تنها قابلیت‌هایی (capabilities) که یک فرآیند محدودشده مجاز به استفاده از آن‌هاست می‌توانند فهرست شوند؛ برای مشاهده فهرست کامل، لطفاً به \fBcapabilities\fR\|(7) مراجعه کنید. توجه داشته باشید که اعطای برخی قابلیت‌ها، محدودسازی AppArmor را برای آن دامنه به حالت مشورتی (advisory) درمی‌آورد؛ در حالی که فراخوان‌های \fBopen\fR\|(2)، \fBread\fR\|(2)، \fBwrite\fR\|(2) و غیره در صورت عدم اعطای دسترسی همچنان خطا برمی‌گردانند، برخی قابلیت‌ها اجازه بارگذاری ماژول‌های هسته، دسترسی دلخواه به IPC، توانایی دور زدن کنترل‌های دسترسی اختیاری و سایر عملیاتی را می‌دهند که معمولاً مخصوص کاربر ریشه (root) است. .SS "قواعد شبکه (Network Rules)" .IX Subsection "Network Rules" برنامه AppArmor از میانجی‌گری ساده و کلی (coarse-grained) شبکه پشتیبانی می‌کند. قاعده شبکه تمامی عملیات مبتنی بر \fBsocket\fR\|(2) را محدود می‌سازد. میانجی‌گری انجام‌شده یک بررسی کلی است مبنی بر اینکه آیا سوکتی از یک نوع و خانواده مشخص می‌تواند ایجاد شود، خوانده شود یا نوشته شود. قواعد شبکه \fBnetlink\fR\|(7) فقط می‌توانند نوع \*(Aqdgram\*(Aq و \*(Aqraw\*(Aq را مشخص کنند. .PP قواعد شبکه AppArmor تجمیع می‌شوند، به‌طوری که مجوزهای اعطاشده شبکه اجتماع تمامی مجوزهای قواعد شبکه فهرست‌شده خواهند بود. .PP قواعد شبکه AppArmor گسترده و کلی هستند و با مشخص شدن اطلاعات بیشتر، محدودکننده‌تر می‌شوند. .PP برای مثال: .PP .Vb 5 \& network, #allow access to all networking \& network tcp, #allow access to tcp \& network inet tcp, #allow access to tcp only for inet4 addresses \& network inet6 tcp, #allow access to tcp only for inet6 addresses \& network netlink raw, #allow access to AF_NETLINK SOCK_RAW .Ve .PP \fIمجوزهای شبکه (Network permissions)\fR .IX Subsection "Network permissions" .PP هنگامی که یک قاعده صراحتاً فهرست دسترسی را ذکر نکند، مجوزهای قاعده شبکه به صورت ضمنی در نظر گرفته می‌شوند. به طور پیش‌فرض اگر قاعده‌ای فهرست دسترسی نداشته باشد، تمام مجوزهایی که با مجموعه شرایط محلی و همتا (peer) مشخص‌شده سازگار باشند به صورت ضمنی اعمال می‌شوند. .PP مجوزهای create، bind، listen، shutdown، getattr، setattr، getopt و setopt مجوزهای سوکت محلی هستند. این مجوزها فقط روی سوکت محلی اعمال می‌شوند و نمی‌توان آن‌ها را در قواعدی که دارای شرط همتا هستند مشخص کرد. مجوز accept بر ترکیب سوکت محلی و همتا اعمال می‌شود. مجوزهای connect، send و receive مجوزهای سوکت همتا هستند. .PP \fIمیانجی‌گری خانواده inet/inet6 (Mediation of inet/inet6 family)\fR .IX Subsection "Mediation of inet/inet6 family" .PP برنامه AppArmor با استفاده از شروط ip و port از میانجی‌گری دقیق و جزئی (fine-grained) خانواده‌های inet و inet6 پشتیبانی می‌کند. شرط ip هر دو نوع IPv4 و IPv6 را می‌پذیرد؛ با استفاده از نمایش استاندارد چهار بخش هشت‌بیتی جداشده با \*(Aq.\*(Aq برای IPv4 و هشت گروه از اعداد چهاررقمی هگزادسیمال جداشده با \*(Aq:\*(Aq برای IPv6. صفرهای پیشرو متوالی را می‌توان یک‌بار با \*(Aq::\*(Aq جایگزین کرد. روی یک سوکت متصل، نیازی به مشخص کردن فرستنده و گیرنده در فراخوان‌های سیستمی recvfrom و sendto نیست. در آن حالت و با سوکت‌های متصل‌نشده (unbound)، آدرس IP برابر با none یا نامشخص است. آدرس‌های IP نامشخص یا متصل‌نشده در خط‌مشی با کلمه کلیدی \*(Aqnone\*(Aq نمایش داده می‌شوند. هنگامی که شرط ip حذف شود، تمام آدرس‌های IP مجاز خواهند بود: IPv4، IPv6 و none. اگر از INADDR_ANY یا in6addr_any استفاده شود، می‌توان شرط ip را حذف کرد یا آن‌ها را به صورت زیر نمایش داد: .PP .Vb 2 \& network ip=::, #allow in6addr_any \& network ip=0.0.0.0; #allow INADDR_ANY .Ve .PP قواعد شبکه از تعیین آدرس‌های IP محلی و راه دور، درگاه‌ها و محدوده‌های درگاه پشتیبانی می‌کنند. .PP .Vb 6 \& network ip=127.0.0.1 port=8080, \& network peer=(ip=10.139.15.23 port=8081), \& network ip=fd74:1820:b03a:b361::cf32 peer=(ip=fd74:1820:b03a:b361::a0f9), \& network port=8080 peer=(port=8081), \& network ip=127.0.0.1 port=8080 peer=(ip=10.139.15.23 port=8081), \& network ip=127.0.0.1 port=8080\-8084, .Ve .SS "قواعد اتصال سیستم‌فایل (Mount Rules)" .IX Subsection "Mount Rules" برنامه AppArmor از میانجی‌گری اتصال سیستم‌فایل (mount) پشتیبانی کرده و امکان مشخص کردن انواع سیستم‌فایل و فلگ‌های mount را فراهم می‌سازد. نحو قواعد mount در AppArmor بر اساس نحو دستور \fBmount\fR\|(8) است. قواعد mount باید شامل یکی از کلمات کلیدی mount، remount یا umount باشند، اما تمام شرایط mount اختیاری هستند. شروط اختیاری مشخص‌نشده منطبق بر تمام ورودی‌ها فرض می‌شوند (برای مثال، عدم تعیین fstype به معنای تطابق با تمام انواع سیستم‌فایل است). با توجه به پیچیدگی دستور mount و نحوه مشخص کردن گزینه‌ها، AppArmor امکان تعیین شروط را به سه روش مختلف فراهم می‌کند: .IP 1. 4 اگر شرطی با استفاده از \*(Aq=\*(Aq مشخص شود، قاعده تنها برای اتصال‌هایی که دقیقاً با گزینه‌های مشخص‌شده مطابقت دارند مجوز صادر می‌کند. برای مثال، یک خط‌مشی AppArmor با قاعده زیر: .Sp .Vb 1 \& mount options=ro /dev/foo \-> /mnt/, .Ve .Sp با این دستور منطبق خواهد بود: .Sp .Vb 1 \& $ mount \-o ro /dev/foo /mnt .Ve .Sp اما با هیچ‌یک از این دستورها منطبق نخواهد بود: .Sp .Vb 1 \& $ mount \-o ro,atime /dev/foo /mnt \& \& $ mount \-o rw /dev/foo /mnt .Ve .IP 2. 4 اگر شرطی با استفاده از \*(Aqin\*(Aq مشخص شود، قاعده برای اتصال‌هایی که با هر ترکیبی از گزینه‌های مشخص‌شده مطابقت داشته باشند مجوز صادر می‌کند. برای مثال، اگر یک خط‌مشی AppArmor دارای قاعده زیر باشد: .Sp .Vb 1 \& mount options in (ro,atime) /dev/foo \-> /mnt/, .Ve .Sp تمامی این دستورهای mount منطبق خواهند بود: .Sp .Vb 1 \& $ mount \-o ro /dev/foo /mnt \& \& $ mount \-o ro,atime /dev/foo /mnt \& \& $ mount \-o atime /dev/foo /mnt .Ve .Sp اما هیچ‌کدام از موارد زیر منطبق نخواهند بود: .Sp .Vb 1 \& $ mount \-o ro,sync /dev/foo /mnt \& \& $ mount \-o ro,atime,sync /dev/foo /mnt \& \& $ mount \-o rw /dev/foo /mnt \& \& $ mount \-o rw,noatime /dev/foo /mnt \& \& $ mount /dev/foo /mnt .Ve .IP 3. 4 اگر چندین شرط در یک قاعده واحد mount مشخص شوند، قاعده برای هر مجموعه از گزینه‌ها مجوز صادر می‌کند. این امر روشی کوتاه برای نوشتن قواعد mount فراهم می‌کند که می‌تواند به تفکیک منطقی یک شرط کمک کند. برای مثال، اگر یک خط‌مشی AppArmor دارای قاعده زیر باشد: .Sp .Vb 1 \& mount options=ro options=atime, .Ve .Sp هر دوی این دستورهای mount منطبق خواهند بود: .Sp .Vb 1 \& $ mount \-o ro /dev/foo /mnt \& \& $ mount \-o atime /dev/foo /mnt .Ve .Sp اما این مورد منطبق نخواهد بود: .Sp .Vb 1 \& $ mount \-o ro,atime /dev/foo /mnt .Ve .PP توجه داشته باشید که قواعد مجزای mount از یکدیگر متمایز هستند و گزینه‌ها تجمیع نمی‌شوند. برای مثال، این قواعد mount در AppArmor: .PP .Vb 1 \& mount options=ro, \& \& mount options=atime, .Ve .PP معادل هیچ‌یک از این قواعد mount نیستند: .PP .Vb 1 \& mount options=(ro,atime), \& \& mount options in (ro,atime), .Ve .PP برای شفاف‌سازی بیشتر انعطاف‌پذیری و پیچیدگی قواعد mount، چند قاعده نمونه همراه با دستورهای منطبق متناظر آورده شده است: .IP \fBmount,\fR 4 .IX Item "mount," قاعده \*(Aqmount\*(Aq بدون هیچ شرطی عمومی‌ترین حالت است و هرگونه اتصال را مجاز می‌داند. معادل با \*(Aqmount fstype=** options=** ** \-> /**\*(Aq است. .IP "\fBmount /dev/foo,\fR" 4 .IX Item "mount /dev/foo," اتصال /dev/foo را در هر مکانی با هر گزینه‌ای مجاز می‌کند. برخی از دستورهای mount منطبق: .Sp .Vb 1 \& $ mount /dev/foo /mnt \& \& $ mount \-t ext3 /dev/foo /mnt \& \& $ mount \-t vfat /dev/foo /mnt \& \& $ mount \-o ro,atime,noexec,nodiratime /dev/foo /srv/some/mountpoint .Ve .IP "\fBmount options=ro /dev/foo,\fR" 4 .IX Item "mount options=ro /dev/foo," اتصال /dev/foo را در هر مکانی، تنها به صورت فقط‌خواندنی مجاز می‌کند. برخی از دستورهای mount منطبق: .Sp .Vb 1 \& $ mount \-o ro /dev/foo /mnt \& \& $ mount \-o ro /dev/foo /some/where/else .Ve .IP "\fBmount options=(ro,atime) /dev/foo,\fR" 4 .IX Item "mount options=(ro,atime) /dev/foo," اتصال /dev/foo را در هر مکانی، به صورت فقط‌خواندنی و با استفاده از زمان‌های دسترسی inode مجاز می‌کند. برخی از دستورهای mount منطبق: .Sp .Vb 1 \& $ mount \-o ro,atime /dev/foo /mnt \& \& $ mount \-o ro,atime /dev/foo /some/where/else .Ve .IP "\fBmount options in (ro,atime) /dev/foo,\fR" 4 .IX Item "mount options in (ro,atime) /dev/foo," اجازه سوار کردن (mount) مسیر /dev/foo در هر مکانی با استفاده از ترکیبی از \*(Aqro\*(Aq و \*(Aqatime\*(Aq (به بالا مراجعه کنید). برخی از دستورات تطبیق‌یافته mount: .Sp .Vb 1 \& $ mount \-o ro /dev/foo /mnt \& \& $ mount \-o atime /dev/foo /some/where/else \& \& $ mount \-o ro,atime /dev/foo /some/other/place .Ve .IP "\fBmount options=ro /dev/foo, mount options=atime /dev/foo,\fR" 4 .IX Item "mount options=ro /dev/foo, mount options=atime /dev/foo," اجازه سوار کردن /dev/foo در هر مکانی به‌صورت فقط‌خواندنی، و اجازه سوار کردن /dev/foo در هر مکانی با استفاده از زمان‌های دسترسی اینود. توجه داشته باشید که این مورد به‌صورت دو قاعده مجزا بیان شده است. تطابق‌ها: .Sp .Vb 1 \& $ mount \-o ro /dev/foo /mnt/1 \& \& $ mount \-o atime /dev/foo /mnt/2 .Ve .IP "\fBmount \-> /mnt/**,\fR" 4 .IX Item "mount -> /mnt/**," اجازه سوار کردن هر چیزی زیر یک دایرکتوری در /mnt/**. برخی دستورات تطبیق‌یافته mount: .Sp .Vb 1 \& $ mount /dev/foo1 /mnt/1 \& \& $ mount \-o ro,atime,noexec,nodiratime /dev/foo2 /mnt/deep/path/foo2 .Ve .IP "\fBmount options=ro \-> /mnt/**,\fR" 4 .IX Item "mount options=ro -> /mnt/**," اجازه سوار کردن هر چیزی زیر /mnt/**، به‌صورت فقط‌خواندنی. برخی دستورات تطبیق‌یافته mount: .Sp .Vb 1 \& $ mount \-o ro /dev/foo1 /mnt/1 \& \& $ mount \-o ro /dev/foo2 /mnt/deep/path/foo2 .Ve .IP "\fBmount fstype=ext3 options=(rw,atime) /dev/sdb1 \-> /mnt/stick/,\fR" 4 .IX Item "mount fstype=ext3 options=(rw,atime) /dev/sdb1 -> /mnt/stick/," اجازه سوار کردن یک سیستم فایل ext3 در /dev/sdb1 روی /mnt/stick به‌صورت خواندن/نوشتن و با استفاده از زمان‌های دسترسی اینود. تنها با موارد زیر تطابق دارد: .Sp .Vb 1 \& $ mount \-o rw,atime /dev/sdb1 /mnt/stick .Ve .IP "\fBmount options=(ro, atime) options in (nodev, user) /dev/foo \-> /mnt/,\fR" 4 .IX Item "mount options=(ro, atime) options in (nodev, user) /dev/foo -> /mnt/," اجازه سوار کردن /dev/foo روی /mnt/ به‌صورت فقط‌خواندنی و با استفاده از زمان‌های دسترسی اینود یا اجازه سوار کردن /dev/foo روی /mnt/ با ترکیبی از \*(Aqnodev\*(Aq و \*(Aquser\*(Aq. تنها با موارد زیر تطابق دارد: .Sp .Vb 1 \& $ mount \-o ro,atime /dev/foo /mnt \& \& $ mount \-o nodev /dev/foo /mnt \& \& $ mount \-o user /dev/foo /mnt \& \& $ mount \-o nodev,user /dev/foo /mnt .Ve .SS "قواعد صف پیام (Message Queue)" .IX Subsection "Message Queue rules" آپ‌آرمور (AppArmor) از میانجی‌گری صف‌های پیام POSIX و SYSV پشتیبانی می‌کند. .PP مجوزهای صف پیام AppArmor زمانی که یک قاعده به‌طور صریح فهرست دسترسی را مشخص نکند، به‌طور ضمنی در نظر گرفته می‌شوند. به‌طور پیش‌فرض، تمامی مجوزهای صف پیام ضمنی هستند. .PP مجوزهای صف پیام AppArmor با مشخص شدن اطلاعات بیشتر، محدودتر می‌شوند. سیاست را می‌توان با تعیین حالت دسترسی، نوع (type)، برچسب (label) و نام صف پیام مشخص کرد. .PP در رابطه با حالت‌های دسترسی، \*(Aqr\*(Aq و \*(Aqread\*(Aq برای خواندن پیام‌ها از صف استفاده می‌شوند. \&\*(Aqw\*(Aq و \*(Aqwrite\*(Aq برای نوشتن در صف پیام به‌کار می‌روند. \*(Aqcreate\*(Aq برای ایجاد صف پیام استفاده می‌شود، و \*(Aqopen\*(Aq برای دریافت شناسه صف پیام در زمانی که صف از قبل ایجاد شده باشد به‌کار می‌رود. \&\*(Aqdelete\*(Aq برای حذف صف پیام استفاده می‌شود. حالت‌های دسترسی برای دریافت و تنظیم ویژگی‌های صف پیام \&\*(Aqgetattr\*(Aq و \*(Aqsetattr\*(Aq هستند. .PP نوع سیاست می‌تواند \*(Aqposix\*(Aq یا \*(Aqsysv\*(Aq باشد. این اطلاعات زمانی مرتبط است که نام صف پیام مشخص نشده باشد، و در صورت مشخص شدن می‌تواند از روی نام صف استنتاج شود، زیرا نام صف‌های پیام برای posix باید با \*(Aq/\*(Aq شروع شود، و کلید صف‌های پیام برای SYSV باید یک عدد صحیح مثبت باشد. .PP برچسب سیاست (policy label)، برچسبی است که در زمان ایجاد به صف پیام اختصاص داده می‌شود. .PP نام صف پیام در صورتی که نوع آن POSIX باشد می‌تواند یک رشته با شروع از \*(Aq/\*(Aq باشد، یا در صورتی که نوع آن SYSV باشد یک عدد صحیح مثبت باشد. اگر نوع مشخص نشده باشد، از روی نام صف استنتاج خواهد شد. .PP مثال‌هایی از قواعد صف پیام AppArmor: .PP .Vb 2 \& # Allow all Message Queue access \& mqueue, \& \& # Explicitly allow all Message Queue access, \& mqueue (create, open, delete, read, write, getattr, setattr), \& \& # Explicitly deny use of Message Queue \& deny mqueue, \& \& # Allow all access for POSIX queue of name /bar \& mqueue type=posix /bar, \& \& # Allow create permission for a SYSV queue of label foo \& mqueue create label=foo 123, .Ve .SS "قواعد فضای نام کاربری (User Namespace)" .IX Subsection "User Namespace Rules" فضاهای نام کاربری (User namespaces) بخشی از بسیاری از راهکارهای ایزوله‌سازی (sandboxing) و کانتینرسازی هستند. آن‌ها روشی را فراهم می‌کنند تا یک فرایند غیرریشه در سیستم اصلی، درون کانتینر دسترسی ریشه (root) داشته باشد. متأسفانه این امر سطح حمله را در هسته باز می‌کند و بخشی از زنجیره‌های اکسپلویت متعددی بوده است. به همین دلیل می‌توان از AppArmor برای محدود کردن ایجاد فضاهای نام کاربری به فرایندهای منتخب استفاده کرد. .PP مجوزهای فضای نام کاربری زمانی که یک قاعده صراحتاً فهرست دسترسی را بیان نکند، به‌صورت ضمنی لحاظ می‌شوند. قاعده با مشخص شدن اطلاعات بیشتر، محدودتر می‌شود. .PP نکته: ایجاد فضای نام کاربری ممکن است به گونه‌ای محدود شود که برای فرایندهای نامحدود (unconfined) غیرمجاز در دسترس نباشد. در این صورت، هر فرایندی که برای ایجاد فضاهای نام کاربری تلاش کند، نیازمند پروفایلی خواهد بود که مجوزهای لازم را فراهم کند. .IP \fBcreate\fR 4 .IX Item "create" اجازه ایجاد فضاهای نام کاربری. .PP مثال‌هایی از قواعد userns: .Sp .Vb 2 \& # Allow all userns perms \& userns, \& \& # Allow creation of a userns \& userns create, .Ve .SS "قواعد IO_URing" .IX Subsection "IO_URing Rules" آپ‌آرمور از میانجی‌گری رابط ورودی/خروجی پرسرعت جدید لینوکس پشتیبانی می‌کند. در حال حاضر میانجی‌گری محدودی به چند مجوز خاص وجود دارد. .PP مجوزهای IO Uring زمانی که یک قاعده صراحتاً فهرست دسترسی را بیان نکند، به‌صورت ضمنی در نظر گرفته می‌شوند. قاعده با مشخص شدن اطلاعات بیشتر، محدودتر می‌شود. .PP نکته: دسترسی به io_uring ممکن است محدود شود به‌طوری‌که برای فرایندهای غیرممتاز و نامحدود (unconfined) در دسترس نباشد. در این صورت هر فرایندی که تلاش کند از io_uring استفاده کند، نیازمند پروفایلی خواهد بود که مجوزهای لازم io_uring را اجازه دهد. .IP \fBsqpoll\fR 4 .IX Item "sqpoll" به تسک محدودشده توسط پروفایل اجازه می‌دهد یک ریسه نظرسنجی (polling thread) در io_uring ایجاد کند. .IP \fBoverride_creds\fR 4 .IX Item "override_creds" به تسک محدودشده توسط پروفایل این امکان را می‌دهد که هنگام اجرای یک عملیات io_uring، اعتبارنامه‌های (credentials) خود را به برچسب مشخص‌شده بازنویسی (تغییر) دهد. .PP مثال‌هایی از قواعد IO_URING: .Sp .Vb 2 \& # Allow io_uring operations \& io_uring, \& \& # Allow creation of a polling thread \& io_uring sqpoll, \& \& # Allow task to override credentials during io_uring operation \& io_uring override_creds label=new_creds, .Ve .SS "قواعد Pivot Root" .IX Subsection "Pivot Root Rules" آپ‌آرمور تغییر سیستم فایل ریشه را از طریق فراخوان سیستمی \fBpivot_root\fR\|(2) میانجی‌گری می‌کند. نحو قواعد \*(Aqpivot_root\*(Aq در AppArmor بر اساس پارامترهای فراخوان سیستمی \fBpivot_root\fR\|(2) است، با این استثنای قابل توجه که ترتیب آن‌ها معکوس است. مسیری که با پارامتر put_old در \fBpivot_root\fR\|(2) مطابقت دارد، به صورت اختیاری در قاعده \&\*(Aqpivot_root\*(Aq با استفاده از پیشوند \*(Aqoldroot=\*(Aq مشخص می‌شود. .PP قواعد \*(Aqpivot_root\*(Aq در AppArmor می‌توانند گذار پروفایل (profile transition) را برای وقوع در طول فراخوان سیستمی \fBpivot_root\fR\|(2) مشخص کنند. توجه داشته باشید که در حال حاضر، این ویژگی توسط هیچ هسته‌ای پشتیبانی نمی‌شود. زمانی که این قابلیت پشتیبانی شود، AppArmor فقط فرایند فراخواننده \fBpivot_root\fR\|(2) را به پروفایل جدید منتقل خواهد کرد. .PP مسیرهای مشخص‌شده در قواعد \*(Aqpivot_root\*(Aq باید با \*(Aq/\*(Aq خاتمه یابند زیرا دایرکتوری هستند. .PP در اینجا چند نمونه از قواعد \*(Aqpivot_root\*(Aq آورده شده است: .PP .Vb 2 \& # Allow any pivot \& pivot_root, \& \& # Allow pivoting to any new root directory and putting the old root \& # directory at /mnt/root/old/ \& pivot_root oldroot=/mnt/root/old/, \& \& # Allow pivoting the root directory to /mnt/root/ \& pivot_root /mnt/root/, \& \& # Allow pivoting to /mnt/root/ and putting the old root directory at \& # /mnt/root/old/ \& pivot_root oldroot=/mnt/root/old/ /mnt/root/, \& \& # Allow pivoting to /mnt/root/, putting the old root directory at \& # /mnt/root/old/ and transition to the /mnt/root/sbin/init profile \& pivot_root oldroot=/mnt/root/old/ /mnt/root/ \-> /mnt/root/sbin/init, .Ve .SS "قواعد PTrace" .IX Subsection "PTrace rules" آپ‌آرمور از میانجی‌گری \fBptrace\fR\|(2) پشتیبانی می‌کند. قواعد PTrace در AppArmor تجمیع می‌شوند، به‌طوری که مجوزهای اعطا شده PTrace حاصل اجتماع تمام مجوزهای قواعد PTrace فهرست‌شده است. .PP مجوزهای PTrace در AppArmor هنگامی که یک قاعده به‌طور صریح فهرست دسترسی را مشخص نکند، به‌صورت ضمنی در نظر گرفته می‌شوند. به‌طور پیش‌فرض، تمامی مجوزهای PTrace ضمنی هستند. .PP مجوزهای trace و tracedby بر \fBptrace\fR\|(2) نظارت می‌کنند، در حالی که read و readby بر دسترسی‌های مشخصی به سیستم فایل \fBproc\fR\|(5)، فراخوان \fBkcmp\fR\|(2)، فیوتکس‌ها (\fBget_robust_list\fR\|(2)) و رویدادهای ردیابی perf نظارت دارند. .PP برای مجاز بودن عملیات ptrace، هم پروفایل فرایند ردیاب (tracing) و هم پروفایل تسک هدف باید مجوزهای صحیحی داشته باشند. برای مثال، پروفایل فرایندی که به تسک دیگر متصل می‌شود باید دارای مجوز trace برای پروفایل تسک هدف باشد، و تسک تحت ردیابی باید مجوز tracedby را برای پروفایل فرایند ردیاب داشته باشد. .PP مثال‌هایی از قواعد PTrace در AppArmor: .PP .Vb 2 \& # Allow all PTrace access \& ptrace, \& \& # Explicitly allow all PTrace access, \& ptrace (read, readby, trace, tracedby), \& \& # Explicitly deny use of ptrace(2) \& deny ptrace (trace), \& \& # Allow unconfined processes (eg, a debugger) to ptrace us \& ptrace (readby, tracedby) peer=unconfined, \& \& # Allow ptrace of a process running under the /usr/bin/foo profile \& ptrace (trace) peer=/usr/bin/foo, .Ve .SS "قواعد Signal" .IX Subsection "Signal rules" آپ‌آرمور از میانجی‌گری \fBsignal\fR\|(7) پشتیبانی می‌کند. قواعد سیگنال در AppArmor تجمیع می‌شوند، به‌گونه‌ای که مجوزهای سیگنال اعطا شده حاصل اجتماع تمام مجوزهای قواعد سیگنال فهرست‌شده است. .PP مجوزهای سیگنال AppArmor هنگامی که یک قاعده به‌طور صریح فهرست دسترسی را مشخص نکند، به‌صورت ضمنی لحاظ می‌شوند. به‌طور پیش‌فرض، تمامی مجوزهای سیگنال ضمنی هستند. .PP برای مجاز بودن ارسال یک سیگنال، هم پروفایل فرایند فرستنده و هم پروفایل تسک هدف باید دارای مجوزهای صحیح باشند. برای نمونه، پروفایل فرایند ارسال‌کننده سیگنال به تسک دیگر باید دارای مجوز send برای پروفایل تسک هدف باشد، و تسک دریافت‌کننده سیگنال باید دارای مجوز receive برای پروفایل فرایند فرستنده باشد. .PP مثال‌هایی از قواعد سیگنال AppArmor: .PP .Vb 2 \& # Allow all signal access \& signal, \& \& # Explicitly deny sending the HUP and INT signals \& deny signal (send) set=(hup, int), \& \& # Allow unconfined processes to send us signals \& signal (receive) peer=unconfined, \& \& # Allow sending of signals to a process running under the /usr/bin/foo \& # profile \& signal (send) peer=/usr/bin/foo, \& \& # Allow checking for PID existence \& signal (receive, send) set=("exists"), \& \& # Allow us to signal ourselves using the built\-in @{profile_name} variable \& signal peer=@{profile_name}, \& \& # Allow two real\-time signals \& signal set=(rtmin+0 rtmin+32), .Ve .SS "قواعد DBus" .IX Subsection "DBus rules" آپ‌آرمور از میانجی‌گری DBus پشتیبانی می‌کند. این میانجی‌گری در هماهنگی با دیمن DBus انجام می‌شود. دیمن DBus بررسی می‌کند که ارتباطات روی گذرگاه (bus) توسط سیاست AppArmor مجاز باشند. .PP قواعد DBus در AppArmor تجمیع می‌شوند، به‌گونه‌ای که مجوزهای DBus اعطا شده حاصل اجتماع تمام مجوزهای قواعد DBus فهرست‌شده است. .PP قواعد DBus در AppArmor گسترده و کلی هستند و با تعیین اطلاعات بیشتر، محدودتر می‌شوند. سیاست را می‌توان تا سطح عضو رابط کاربری (نام متد یا سیگنال) تعیین کرد، با این حال محتوای پیام‌ها بررسی نمی‌شود. .PP برخی از مجوزهای DBus در AppArmor با همه قواعد DBus سازگار نیستند. مجوز \*(Aqbind\*(Aq نمی‌تواند در قواعد پیام (message rules) استفاده شود. مجوزهای \*(Aqsend\*(Aq و \*(Aqreceive\*(Aq نمی‌توانند در قواعد سرویس (service rules) به‌کار روند. مجوز \*(Aqeavesdrop\*(Aq نمی‌تواند در قواعدی استفاده شود که شامل هرگونه شرطی خارج از شرط \*(Aqbus\*(Aq هستند. .PP \&\*(Aqr\*(Aq و \*(Aqread\*(Aq مترادف \*(Aqreceive\*(Aq هستند. \*(Aqw\*(Aq و \*(Aqwrite\*(Aq مترادف \&\*(Aqsend\*(Aq هستند. \*(Aqrw\*(Aq مترادفی برای هر دو مجوز \*(Aqsend\*(Aq و \*(Aqreceive\*(Aq است. .PP مجوزهای DBus در AppArmor زمانی که یک قاعده به‌طور صریح فهرست دسترسی را مشخص نکند، به‌صورت ضمنی در نظر گرفته می‌شوند. به‌طور پیش‌فرض، تمامی مجوزهای DBus ضمنی هستند. فقط مجوزهای پیام برای قواعد پیام، و فقط مجوزهای سرویس برای قواعد سرویس به‌صورت ضمنی در نظر گرفته می‌شوند. .PP مثال‌هایی از قواعد DBus در AppArmor: .PP .Vb 2 \& # Allow all DBus access \& dbus, \& \& # Explicitly allow all DBus access, \& dbus (send, receive, bind), \& \& # Deny send/receive/bind access to the session bus \& deny dbus bus=session, \& \& # Allow bind access for a particular name on any bus \& dbus bind name=com.example.ExampleName, \& \& # Allow receive access for a particular path and interface \& dbus receive path=/com/example/path interface=com.example.Interface, \& \& # Deny send/receive access to the system bus for a particular interface \& deny dbus bus=system interface=com.example.ExampleInterface, \& \& # Allow send access for a particular path, interface, member, and pair of \& # peer names: \& dbus send \& bus=session \& path=/com/example/path \& interface=com.example.Interface \& member=ExampleMethod \& peer=(name=(com.example.ExampleName1|com.example.ExampleName2)), \& \& # Allow receive access for all unconfined peers \& dbus receive peer=(label=unconfined), \& \& # Allow eavesdropping on the system bus \& dbus eavesdrop bus=system, \& \& # Allow and audit all eavesdropping \& audit dbus eavesdrop, .Ve .SS "قوانین سوکت یونیکس (Unix socket rules)" .IX Subsection "Unix socket rules" نرم‌افزار AppArmor از میانجی‌گری دقیق سوکت‌های انتزاعی (abstract) و ناشناس (anonymous) دامنه یونیکس پشتیبانی می‌کند. سوکت‌های دامنه یونیکس دارای مسیرهای فایل‌سیستم، از طریق قوانین دسترسی فایل میانجی‌گری می‌شوند. .PP سوکت‌های انتزاعی دامنه یونیکس یک افزونه غیرقابل‌حمل (nonportable) لینوکس برای سوکت‌های دامنه یونیکس هستند؛ برای اطلاعات بیشتر \fBunix\fR\|(7) را ببینید. .PP \fIمسیرهای آدرس سوکت یونیکس (Unix socket address paths)\fR .IX Subsection "Unix socket address paths" .PP مؤلفه sun_path (یا همان آدرس سوکت) یک سوکت دامنه یونیکس با شرط .PP .Vb 1 \& addr= .Ve .PP مشخص می‌شود. اگر شرط آدرس به عنوان بخشی از یک قانون مشخص نشده باشد، آن قانون با هر دو نوع سوکت انتزاعی و ناشناس مطابقت می‌یابد. .PP در AppArmor آدرس یک سوکت انتزاعی دامنه یونیکس با نویسه \fI@\fR آغاز می‌شود، مشابه نحوه گزارش آن‌ها (به عنوان مسیر) توسط .BR "netstat \-x" . سپس آدرس می‌آید و می‌تواند شامل تطبیق الگو و هر نویسه‌ای از جمله نویسه تهی (null character) باشد. در AppArmor نویسه‌های null باید با استفاده از توالی فرار \fI\e000\fR یا \fI\ex00\fR مشخص شوند. تطبیق الگو همانند تطبیق مسیر فایل است، بنابراین * با \fI/\fR مطابقت نخواهد داشت حتی اگر در نام یک سوکت انتزاعی معنای خاصی نداشته باشد. برای مثال: .PP .Vb 1 \& unix addr=@*, .Ve .PP سوکت‌های خودپیوند (Autobound) دامنه یونیکس یک sun_path یونیکس دارند که توسط هسته به آن‌ها اختصاص داده شده است، به همین دلیل مشخص کردن آدرس مبتنی بر پالیسی امکان‌پذیر نیست. خودپیوندی سوکت‌ها را می‌توان با مشخص کردن کلمه کلیدی ویژه \fIauto\fR کنترل کرد. برای مثال: .PP .Vb 1 \& unix addr=auto, .Ve .PP برای مشخص کردن اینکه قانون فقط برای پیوند خودکار سوکت‌های دامنه یونیکس اعمال می‌شود. توجه به این نکته مهم است که این مورد فقط برای مجوز \fIbind\fR اعمال می‌شود، زیرا به محض اینکه سوکت به یک آدرس متصل شد، از سوکتی که آدرس آن با یک نام مشخص پیوند خورده غیرقابل تشخیص است. هنگامی که کلمه کلیدی \fIauto\fR با سایر مجوزها یا به عنوان بخشی از یک آدرس همتا (peer addr) استفاده می‌شود، با الگویی جایگزین می‌شود که می‌تواند با یک سوکت خودپیوند مطابقت داشته باشد. برای مثال در برخی هسته‌ها: .PP .Vb 1 \& unix rw addr=auto, .Ve .PP تبدیل می‌شود به: .PP .Vb 1 \& unix rw addr=@[a\-f0\-9][a\-f0\-9][a\-f0\-9][a\-f0\-9][a\-f0\-9], .Ve .PP توجه به این نکته مهم است که این الگو ممکن است با سوکت‌های انتزاعی که خودپیوند نبوده‌اند اما آدرسی مطابق با آنچه هسته هنگام خودپیوند سوکت تولید می‌کند دارند نیز مطابقت پیدا کند. .PP سوکت‌های ناشناس دامنه یونیکس هیچ sun_path مرتبط با آدرس سوکت ندارند، با این حال می‌توان آن را با کلمه کلیدی ویژه \fInone\fR مشخص کرد تا نشان دهد قانون فقط بر سوکت‌های ناشناس دامنه یونیکس اعمال می‌شود. برای مثال: .PP .Vb 1 \& unix addr=none, .Ve .PP اگر مؤلفه آدرس یک قانون مشخص نشده باشد، قانون بر سوکت‌های خودپیوند (autobind)، انتزاعی (abstract) و ناشناس (anonymous) اعمال می‌شود. .PP \fIمجوزهای سوکت یونیکس (Unix socket permissions)\fR .IX Subsection "Unix socket permissions" .PP قوانین سوکت دامنه یونیکس انباشته می‌شوند، به طوری که مجوزهای سوکت یونیکس اعطا شده، اجتماع تمام مجوزهای قوانین یونیکس فهرست‌شده است. .PP قوانین سوکت دامنه یونیکس وسیع و عمومی هستند و با مشخص شدن اطلاعات بیشتر، محدودکننده‌تر می‌شوند. پالیسی را می‌توان تا سطح آدرس سوکت (یا همان sun_path) و برچسب (label) تعیین کرد. محتوای ارتباطات بررسی نمی‌شود. .PP مجوزهای قوانین سوکت یونیکس هنگامی که یک قانون صراحتاً لیست دسترسی را بیان نکند، ضمنی تلقی می‌شوند. به طور پیش‌فرض اگر قانونی فاقد لیست دسترسی باشد، تمام مجوزهایی که با مجموعه شرایط محلی (local) و همتا (peer) مشخص‌شده سازگار هستند، به طور ضمنی در نظر گرفته می‌شوند. .PP مجوزهای create، bind، listen، shutdown، getattr، setattr، getopt و setopt مجوزهای سوکت محلی هستند. آن‌ها فقط بر سوکت محلی اعمال می‌شوند و نمی‌توان آن‌ها را در قوانینی که دارای مؤلفه peer هستند مشخص کرد. مجوز accept برای ترکیب یک سوکت محلی و همتا اعمال می‌شود. مجوزهای connect، send و receive مجوزهای سوکت همتا هستند. .PP فقط مجوزهای سوکت همتا برای قوانینی اعمال می‌شوند که مجوزی مشخص نکرده و حاوی مؤلفه peer باشند. .PP \fIمثال‌های قوانین سوکت دامنه یونیکس:\fR .IX Subsection "Example Unix domain socket rules:" .PP .Vb 2 \& # مجاز کردن تمام مجوزها برای سوکت‌های یونیکس \& unix, \& \& # مجاز کردن صریح تمام مجوزهای یونیکس \& unix (create, listen, accept, connect, send, receive, getattr, setattr, setopt, getopt), \& \& # رد کردن صریح دسترسی به سوکت یونیکس \& deny unix, \& \& # مجاز کردن ایجاد و استفاده از سوکت‌های انتزاعی و ناشناس برای profile_name \& unix peer=(label=@{profile_name}), \& \& # مجاز کردن دریافت از طریق سوکت‌های یونیکس از unconfined \& unix (receive) peer=(label=unconfined), \& \& # مجاز کردن getattr و shutdown روی سوکت‌های ناشناس \& unix (getattr, shutdown) addr=none, \& \& # مجاز کردن اتصال SOCK_STREAM، دریافت و ارسال روی سوکت انتزاعی @bar \& # با همتایی که تحت نمایه \*(Aq/foo\*(Aq اجرا می‌شود \& unix (connect, receive, send) type=stream peer=(label=/foo,addr="@bar"), \& \& # مجاز کردن پذیرش اتصالات و دریافت از همتایی که تحت \& # نمایه \*(Aq/bar\*(Aq روی سوکت انتزاعی \*(Aq@foo\*(Aq اجرا می‌شود \& unix (accept, receive) addr=@foo peer=(label=/bar), .Ve .PP \fIپیوند خودکار سوکت‌های انتزاعی دامنه یونیکس (Abstract unix domain sockets autobind)\fR .IX Subsection "Abstract unix domain sockets autobind" .PP سوکت‌های انتزاعی دامنه یونیکس می‌توانند به صورت خودکار به یک آدرس متصل (autobind) شوند. آدرس پیوند خودکار یک رشته منحصر‌به‌فرد ۵ رقمی از اعداد ده‌دهی است، مانند \f(CW@00001\fR. هیچ عاملی وجود ندارد که مانع از اتصال دستی یک تسک به آدرس‌هایی با الگوی مشابه شود، بنابراین شناسایی مطمئن آدرس‌های پیوند خودکار از یک آدرس معمولی غیرممکن است. .PP \fIتعامل قوانین شبکه و قوانین دقیق سوکت دامنه یونیکس\fR .IX Subsection "Interaction of network rules and fine grained unix domain socket rules" .PP قوانین کلی و درشت‌دانه (coarse grained) شبکه را می‌توان برای کنترل سوکت‌های دامنه یونیکس نیز استفاده کرد. هنگامی که میانجی‌گری دقیق (fine grained) سوکت دامنه یونیکس در دسترس باشد، قانون درشت‌دانه شبکه به قانون معادل سوکت یونیکس نگاشت می‌شود. .PP برای مثال: .PP .Vb 1 \& network unix, => unix, \& \& network unix stream, => unix stream, .Ve .PP با این حال، قوانین میانجی‌گری دقیق را نمی‌توان بدون از دست رفتن اطلاعات به قانون درشت‌دانه شبکه بازگرداند؛ برای مثال: .PP .Vb 1 \& unix bind addr=@example, .Ve .PP هیچ تطابق دقیقی تحت قوانین درشت‌دانه شبکه ندارد، نزدیک‌ترین تطابق، قانون مجوز بسیار گسترده‌تر زیر است: .PP .Vb 1 \& network unix, .Ve .SS "قوانین change_profile" .IX Subsection "change_profile rules" نرم‌افزار AppArmor از انتقال‌های خودگردان نمایه از طریق API تغییر نمایه (change_profile api) پشتیبانی می‌کند. قوانین change_profile کنترل می‌کنند که یک تسک محدودشده (confined) به کدام نمایه‌ها و با چه مجوزهایی می‌تواند انتقال یابد. نام نمایه می‌تواند شامل تطبیق الگوی AppArmor برای تعیین نمایه‌های مختلف باشد. .PP .Vb 1 \& change_profile \-> **, .Ve .PP این API اجازه می‌دهد که انتقال تا زمانی که تسک برنامه دیگری را اجرا می‌کند به تعویق بیفتد. اگر یک انتقال قانون exec برای برنامه تعیین شده باشد و از change_profile api برای ایجاد انتقال در زمان اجرا (exec time) استفاده شود، انتقال تعیین‌شده توسط change_profile api اولویت دارد. .PP مجوز Change_profile می‌تواند با مشخص کردن شرط exec، نمایه‌های قابل انتقال را بر اساس نام فایل اجرایی محدود کند. .PP .Vb 1 \& change_profile /bin/bash \-> new_profile, .Ve .PP محدود کردن نمایه انتقال به یک فایل اجرایی مشخص در زمان اجرا فقط زمانی مفید است که تسک فعلی مجاز به تصمیم‌گیری‌های پویا در مورد وضعیت محدودسازی باشد، اما مجموعه تصمیم‌گیری‌ها باید کنترل شوند. از یک لیست از نمایه‌ها یا چندین قانون می‌توان برای مشخص کردن نمایه‌ها در این مجموعه استفاده کرد. برای مثال: .PP .Vb 1 \& change_profile /bin/bash \-> {new_profile1,new_profile2,new_profile3}, .Ve .PP اگر بخواهید انتقال برای فایل اجرایی مجاز باشد حتی زمانی که change_profile api برای انتخاب یک انتقال از میان موارد موجود در مجموعه قوانین change_profile استفاده نشده باشد، می‌توان از یک قانون exec برای تعیین انتقال استفاده کرد. برای مثال: .PP .Vb 2 \& /bin/bash Px \-> new_profile1, \& change_profile /bin/bash \-> {new_profile1,new_profile2,new_profile3}, .Ve .PP حالت exec تعیین می‌کند که آیا روتین‌های \fBunsafe_exec\fR هسته لینوکس باید برای پاکسازی محیط (scrub the environment)، مشابه برنامه‌های setuid استفاده شوند یا خیر. (برای اطلاعاتی در مورد پاکسازی محیط در setuid/setgid به \fBld.so\fR\|(8) مراجعه کنید.) حالت \fBsafe\fR پاکسازی محیط را طوری تنظیم می‌کند که هنگام اجرای برنامه جدید انجام شود، و حالت \fBunsafe\fR الزام AppArmor برای پاکسازی محیط را غیرفعال می‌کند (هسته یا libc ممکن است همچنان نیازمند پاکسازی محیط باشند). حالت exec فقط زمانی می‌تواند مشخص شود که شرط exec وجود داشته باشد. .PP .Vb 1 \& change_profile safe /bin/bash \-> new_profile, .Ve .PP همه هسته‌ها از حالت \fBsafe\fR پشتیبانی نمی‌کنند و در این شرایط تجزیه‌کننده (parser) قوانین را به حالت \fBunsafe\fR تنزل می‌دهد. اگر هیچ حالت exec مشخص نشده باشد، در هسته‌هایی که از آن پشتیبانی می‌کنند حالت پیش‌فرض \fBsafe\fR است. .SS "قانون all" .IX Subsection "all rule" قانون all برای افزودن یک قانون عمومی برای تمامی انواع قوانین پشتیبانی‌شده استفاده می‌شود. این قابلیت زمانی مفید است که پالیسی بخواهد به جای لیست سفید، یک لیست سیاه تعریف کند، اما می‌تواند برای افزودن یک توصیف‌کننده دسترسی (access qualifier) به تمام قوانین نیز مفید باشد. .PP برای مثال: لیست سیاه .PP .Vb 4 \& allow all, \& # شروع لیست سیاه \& deny file, \& deny unix, .Ve .PP برای مثال: افزودن توصیف‌کننده بازرسی (audit) .PP .Vb 1 \& audit access all, .Ve .SS "قوانین rlimit" .IX Subsection "rlimit rules" همان‌طور که در صفحه راهنمای \fBsetrlimit\fR\|(2) شرح داده شده است، AppArmor می‌تواند محدودیت‌های منابع مرتبط با یک نمایه را تنظیم و کنترل کند. .PP کنترل‌های rlimit در AppArmor اجازه تعیین محدودیت‌ها و جلوگیری از تغییر آن‌ها را می‌دهند و این اقدامات می‌توانند مورد بازرسی (audit) قرار گیرند. اعمال محدودیت‌های تعیین‌شده توسط سازوکار استاندارد هسته برای rlimitها مدیریت می‌شود و در صورت اعمال محدودیت، پیامی مبنی بر بازرسی AppArmor ایجاد نخواهد شد. .PP اگر نمایه‌ای قانون rlimit مرتبط با یک rlimit خاص نداشته باشد، آن rlimit دست‌نخورده باقی مانده و دسترسی عادی از جمله تغییر حد مجاز است. با این حال اگر نمایه یک rlimit را تعیین کند، حد فعلی بررسی می‌شود و در صورتی که بیشتر از حد تعیین‌شده در قانون باشد، به حد مشخص‌شده تغییر خواهد یافت. .PP قوانین rlimit در AppArmor محدودیت سخت (hard limit) یک برنامه را کنترل می‌کنند و اطمینان می‌دهند که اگر محدودیت سخت کاهش یابد، محدودیت نرم (soft limit) از مقدار محدودیت سخت فراتر نرود. .PP برای مثال: .PP .Vb 3 \& set rlimit data <= 100M, \& set rlimit nproc <= 10, \& set rlimit nice <= 5, .Ve .SS "متغیرها (Variables)" .IX Subsection "Variables" زبان پالیسی AppArmor اجازه تعبیه متغیرها در قوانین فایل را می‌دهد تا پیکربندی آسان‌تر برخی تنظیمات رایج (و فراگیر) امکان‌پذیر شود. متغیرها می‌توانند مقادیر متعددی داشته باشند، اما هرگونه مقداردهی متغیر باید پیش از شروع نمایه انجام شود. .PP تجزیه‌کننده (parser) به طور خودکار متغیرها را باز می‌کند (expand) تا شامل تمام مقادیری شوند که به آن‌ها اختصاص یافته است؛ ارجاع به یک متغیر بدون تعیین حداقل یک مقدار خطا محسوب می‌شود. برای افزودن صریح یک مقدار خالی می‌توانید از گیومه خالی ("") استفاده کنید. .PP در زمان نگارش این متن، متغیرهای زیر در پالیسی ارائه‌شده AppArmor تعریف شده‌اند: .PP .Vb 10 \& @{HOME} \& @{HOMEDIRS} \& @{multiarch} \& @{pid} \& @{pids} \& @{PROC} \& @{securityfs} \& @{apparmorfs} \& @{sys} \& @{tid} \& @{run} \& @{XDG_DESKTOP_DIR} \& @{XDG_DOWNLOAD_DIR} \& @{XDG_TEMPLATES_DIR} \& @{XDG_PUBLICSHARE_DIR} \& @{XDG_DOCUMENTS_DIR} \& @{XDG_MUSIC_DIR} \& @{XDG_PICTURES_DIR} \& @{XDG_VIDEOS_DIR} .Ve .PP این متغیرها در فایل‌هایی در \fI/etc/apparmor.d/tunables\fR تعریف شده‌اند و در بسیاری از انتزاع‌های شرح داده شده در ادامه استفاده می‌شوند. .PP همچنین می‌توانید فایل‌هایی را در \fI/etc/apparmor.d/tunables/home.d\fR برای سفارشی‌سازی خاص سیستم از \fB@{HOMEDIRS}\fR، در \fI/etc/apparmor.d/tunables/multiarch.d\fR برای \fB@{multiarch}\fR و در \fI/etc/apparmor.d/tunables/xdg\-user\-dirs.d\fR برای \fB@{XDG_*}\fR اضافه کنید. .PP متغیر ویژه \fB@{profile_name}\fR برابر با نام نمایه تنظیم شده و در تمام پالیسی‌ها قابل استفاده است. .PP \fIنکاتی پیرامون بسط متغیر و نویسه /\fR .IX Subsection "Notes on variable expansion and the / character" .PP توجه به این نکته مهم است که نحوه انجام بسط متغیر (variable expansion) توسط AppArmor به زمینه‌ای که متغیر در آن استفاده می‌شود بستگی دارد. هنگامی که یک متغیر باز می‌شود، می‌تواند منجر به ایجاد رشته‌ای با چندین نویسه مسیر در کنار یکدیگر شود، به گونه‌ای که هنگام مشاهده پالیسی آشکار نیست. .PP برای مثال: .Sp .RS 4 با فرض تعریف متغیر و قانون زیر: .Sp @{HOME}=/home/*/ file rw @{HOME}/*, .Sp بسط متغیر منجر به قانونی به شکل زیر می‌شود: .Sp file rw /home/*//*. .RE .PP هنگامی که این وضعیت در زمینه‌ای رخ می‌دهد که انتظار یک مسیر می‌رود، AppArmor با ادغام نویسه‌های پیاپی / به یک نویسه واحد، مسیر را استانداردسازی (canonicalize) می‌کند. برای مثال فوق، نتیجه به این صورت خواهد بود: .PP .Vb 1 \& file rw /home/*/*, .Ve .PP یک استثنا برای این قاعده وجود دارد؛ هنگامی که نویسه‌های / متوالی در ابتدای یک مسیر قرار گیرند، این امر بیانگر یک فضای نام posix (posix namespace) است و نویسه‌ها فشرده نخواهند شد. .PP به‌عنوان مثال: .Sp .RS 4 @{HOME}=/home/*/ file rw /@{HOME}/*, .Sp منجر به بسط زیر خواهد شد: .Sp file rw //home/*//*, .Sp که به شکل زیر فشرده می‌شود: .Sp file rw //home/*/*, .Sp توجه: // ابتدایی در مثال بالا به یک / تکی فشرده نمی‌شود. با این حال، // دوم (که در مثال اول نیز مشاهده شد) فشرده می‌شود. .RE .SS "قوانین نام مستعار (Alias rules)" .IX Subsection "Alias rules" همچنین AppArmor قواعد نام مستعار (alias rules) را برای نگاشت مجدد مسیرها جهت ساختارهای محلی و اختصاصی فراهم می‌کند. این قواعد روشی جایگزین برای بازنویسی مسیر نسبت به استفاده از متغیرها هستند و پس از حل متغیرها (variable resolution) اعمال می‌شوند. قواعد نام مستعار باید در بخش مقدمه (preamble) پروفایل قرار گیرند. نام‌های مستعار سراسری سیستم در \&\fI/etc/apparmor.d/tunables/alias\fR یافت می‌شوند که توسط \&\fI/etc/apparmor.d/tunables/global\fR گنجانده شده است. \&\fI/etc/apparmor.d/tunables/global\fR معمولاً در ابتدای یک پروفایل AppArmor درج می‌شود. .SS "تطبیق الگو (AARE)" .IX Subsection "Globbing (AARE)" منابع فایلی و سایر پارامترهایی که یک AARE را می‌پذیرند می‌توانند با ساختار تطبیق الگویی (globbing syntax) مشابه شل‌های رایج مانند \&\fBcsh\fR\|(1)، \fBbash\fR\|(1)، \fBzsh\fR\|(1) مشخص شوند. .IP \fB*\fR 4 .IX Item "*" می‌تواند جایگزین هر تعداد نویسه به جز \*(Aq/\*(Aq شود .IP \fB**\fR 4 .IX Item "**" می‌تواند جایگزین هر تعداد نویسه، از جمله \*(Aq/\*(Aq شود .IP \fB?\fR 4 .IX Item "?" می‌تواند جایگزین هر نویسه منفرد به جز \*(Aq/\*(Aq شود .IP \fB[abc]\fR 4 .IX Item "[abc]" جایگزین تک‌نویسه a، b یا c خواهد شد .IP \fB[a\-c]\fR 4 .IX Item "[a-c]" جایگزین تک‌نویسه a، b یا c خواهد شد .IP \fB[^a\-c]\fR 4 .IX Item "[^a-c]" جایگزین هر تک‌نویسه‌ای که منطبق با a، b یا c نباشد خواهد شد .IP \fB{ab,cd}\fR 4 .IX Item "{ab,cd}" به یک قاعده برای تطبیق با ab و یک قاعده برای تطبیق با cd بسط می‌یابد .Sp همچنین می‌تواند شامل متغیرها باشد. .IP \fB@{variable}\fR 4 .IX Item "@{variable}" به تمام مقادیر اختصاص‌یافته به متغیر داده‌شده بسط می‌یابد. .PP هنگامی که AppArmor یک دایرکتوری را جستجو می‌کند، نام مسیر مورد جستجو به یک اسلش ختم خواهد شد (مانند \fI/var/tmp/\fR)؛ در غیر این صورت به اسلش ختم نخواهد شد. فقط قواعدی که با اسلش پایانی مطابقت دارند با دایرکتوری‌ها تطبیق می‌یابند. چند مثال که هیچ‌کدام با خود دایرکتوری \fI/tmp/\fR مطابقت ندارند عبارتند از: .IP \fB/tmp/*\fR 4 .IX Item "/tmp/*" فایل‌های موجود در داخل \fI/tmp\fR به طور مستقیم. .IP \fB/tmp/*/\fR 4 .IX Item "/tmp/*/" دایرکتوری‌های موجود در داخل \fI/tmp\fR به طور مستقیم. .IP \fB/tmp/**\fR 4 .IX Item "/tmp/**" فایل‌ها و دایرکتوری‌ها در هر کجای زیرشاخه \fI/tmp\fR. .IP \fB/tmp/**/\fR 4 .IX Item "/tmp/**/" دایرکتوری‌ها در هر کجای زیرشاخه \fI/tmp\fR. .SS "توصیف‌کننده‌های قاعده (Rule Qualifiers)" .IX Subsection "Rule Qualifiers" چندین توصیف‌کننده قاعده وجود دارند که می‌توان آن‌ها را بر قواعد دسترسی اعمال کرد. توصیف‌کننده‌های قاعده می‌توانند قاعده و/یا دسترسی‌های درون آن را تغییر دهند. .IP \fBpriority\fR 4 .IX Item "priority" اولویت قاعده را مشخص می‌کند. در حال حاضر محدوده مجاز \&\-1000 تا 1000 است که اولویت پیش‌فرض قاعده 0 می‌باشد. قواعد با اولویت بالاتر ارجحیت دارند و در موارد هم‌پوشانی، دسترسی‌های قواعد با اولویت پایین‌تر را به طور کامل بازنویسی (override) خواهند کرد. هنگامی که قواعد هم‌پوشانی جزئی دارند، دسترسی‌های قاعده با اولویت بالاتر به طور کامل قواعد با اولویت پایین‌تر را در محدوده هم‌پوشانی لغو می‌کند. در یک سطح اولویت مشخص، قواعدی که هم‌پوشانی دارند دسترسی‌ها را طبق شیوه استاندارد AppArmor تجمیع می‌کنند. .IP \fBallow\fR 4 .IX Item "allow" مشخص می‌کند که درخواست‌های دسترسی منطبق با قاعده مجاز هستند. این مقدار پیش‌فرض برای قواعد است و نیازی به مشخص کردن صریح ندارد. با توصیف‌کننده \fIdeny\fR در تضاد است. .IP \fBaudit\fR 4 .IX Item "audit" مشخص می‌کند که درخواست‌های دسترسی منطبق با قاعده باید در گزارش حسابرسی (audit log) ثبت شوند. .IP \fBdeny\fR 4 .IX Item "deny" مشخص می‌کند که درخواست‌های دسترسی منطبق با قاعده باید بدون ثبت در لاگ رد شوند. می‌تواند با \*(Aqaudit\*(Aq برای فعال‌سازی لاگ ترکیب شود. با توصیف‌کننده \fIallow\fR در تضاد است. .IP \fBowner\fR 4 .IX Item "owner" مشخص می‌کند که تسک باید دارای euid/fsuid یکسان با شیء مورد ارجاع توسط بررسی دسترسی باشد. .PP \fIبلاک‌های توصیف‌کننده (Qualifier Blocks)\fR .IX Subsection "Qualifier Blocks" .PP توصیف‌کننده‌های قاعده را می‌توان با گروه‌بندی قواعد درون یک بلاک قاعده، به طور همزمان بر چندین قاعده اعمال کرد. .PP .Vb 4 \& audit { \& /foo r, \& network, \& } .Ve .SS "سازوکار #include" .IX Subsection "#include mechanism" ‏AppArmor یک سازوکار انتزاعی ساده برای گروه‌بندی نیازمندی‌های دسترسی مشترک فراهم می‌کند؛ این انتزاع روشی فوق‌العاده منعطف برای اعطای دسترسی‌های ویژه و محلی است و نوشتن پروفایل‌های جدید AppArmor را با سرهم‌بندی بلوک‌های سازنده مورد نیاز برای هر برنامه، بسیار ساده می‌سازد. .PP استفاده از \*(Aq#include\*(Aq مستقیماً از \fBcpp\fR\|(1) الگوبرداری شده است؛ استفاده از آن دستور \*(Aq#include\*(Aq را با محتویات فایل مشخص‌شده جایگزین می‌کند. علامت \*(Aq#\*(Aq ابتدایی اختیاری است و پس از کلیدواژه \*(Aq#include\*(Aq می‌تواند عبارت شرطی اختیاری \*(Aqif exists\*(Aq بیاید که مشخص می‌کند در صورت پیدا نشدن فایل یا دایرکتوری مشخص‌شده، کامپایل پروفایل باید ادامه یابد. .PP دستور \fB#include "/absolute/path"\fR مشخص می‌کند که \fI/absolute/path\fR باید استفاده شود. دستور \fB#include "relative/path"\fR مشخص می‌کند که \fIrelative/path\fR باید استفاده شود، جایی که مسیر نسبت به دایرکتوری کاری فعلی سنجیده می‌شود. عبارت \fB#include \fR رایج‌ترین کاربرد است؛ این دستور \fImagic/path\fR را نسبت به دایرکتوری مشخص‌شده برای \fBapparmor_parser\fR\|(8) بارگذاری می‌کند. مسیر \fI/etc/apparmor.d/\fR پیش‌فرض AppArmor است. .PP پروفایل‌های عرضه‌شده AppArmor از چندین قرارداد پیروی می‌کنند؛ انتزاع‌های ذخیره‌شده در \fI/etc/apparmor.d/abstractions/\fR دسته‌های بزرگی هستند که در بیشتر پروفایل‌ها استفاده می‌شوند. در ادامه توصیف‌های کوتاهی از نحوه استفاده برخی از این انتزاع‌ها آمده است. .IP \fIabstractions/audio\fR 4 .IX Item "abstractions/audio" شامل دسترسی به فایل‌های دستگاه مورد استفاده برنامه‌های صوتی است. .IP \fIabstractions/authentication\fR 4 .IX Item "abstractions/authentication" شامل دسترسی به فایل‌ها و سرویس‌هایی است که معمولاً برای سرویس‌های احراز هویت کاربر ضروری هستند. .IP \fIabstractions/base\fR 4 .IX Item "abstractions/base" شامل فایل‌هایی است که باید در تمام پروفایل‌ها قابل خواندن و نوشتن باشند. .IP \fIabstractions/bash\fR 4 .IX Item "abstractions/bash" شامل بسیاری از فایل‌های مورد استفاده bash است؛ برای شل‌های تعاملی و برنامه‌هایی که \fBsystem\fR\|(3) را فراخوانی می‌کنند مفید است. .IP \fIabstractions/consoles\fR 4 .IX Item "abstractions/consoles" شامل دسترسی خواندن و نوشتن به فایل‌های دستگاه کنترل‌کننده کنسول مجازی، \fBsshd\fR\|(8)، \fBxterm\fR\|(1) و غیره است. این انتزاع برای بسیاری از برنامه‌هایی که با کاربران تعامل دارند مورد نیاز است. .IP \fIabstractions/fonts\fR 4 .IX Item "abstractions/fonts" شامل دسترسی به فونت‌ها و کتابخانه‌های فونت است. .IP \fIabstractions/gnome\fR 4 .IX Item "abstractions/gnome" شامل دسترسی خواندن و نوشتن به فایل‌های پیکربندی GNOME و همچنین دسترسی خواندن به کتابخانه‌های GNOME است. .IP \fIabstractions/kde\fR 4 .IX Item "abstractions/kde" شامل دسترسی خواندن و نوشتن به فایل‌های پیکربندی KDE و همچنین دسترسی خواندن به کتابخانه‌های KDE است. .IP \fIabstractions/kerberosclient\fR 4 .IX Item "abstractions/kerberosclient" شامل قواعد دسترسی به فایل مورد نیاز برای کلاینت‌های رایج کربروس (kerberos) است. .IP \fIabstractions/nameservice\fR 4 .IX Item "abstractions/nameservice" شامل قواعد فایلی برای مجاز کردن جستجوهای DNS، LDAP، NIS، SMB، پایگاه‌های داده رمز عبور کاربر و گروه، سرویس‌ها و پروتکل‌ها است. .IP \fIabstractions/perl\fR 4 .IX Item "abstractions/perl" شامل دسترسی خواندن به ماژول‌های perl است. .IP \fIabstractions/user\-download\fR 4 .IX Item "abstractions/user-download" .PD 0 .IP \fIabstractions/user\-mail\fR 4 .IX Item "abstractions/user-mail" .IP \fIabstractions/user\-manpages\fR 4 .IX Item "abstractions/user-manpages" .IP \fIabstractions/user\-tmp\fR 4 .IX Item "abstractions/user-tmp" .IP \fIabstractions/user\-write\fR 4 .IX Item "abstractions/user-write" .PD برخی از پروفایل‌ها برای برنامه‌های معمول "کاربر" از این فایل‌های ضمیمه برای توصیف دسترسی‌هایی که کاربران در سیستم دارند استفاده می‌کنند. .IP \fIabstractions/wutmp\fR 4 .IX Item "abstractions/wutmp" شامل دسترسی نوشتن به فایل‌های مورد استفاده برای نگهداری پایگاه‌های داده \fBwtmp\fR\|(5) و \fButmp\fR\|(5) است که با w(1) و دستورات مرتبط استفاده می‌شوند. .IP \fIabstractions/X\fR 4 .IX Item "abstractions/X" شامل دسترسی خواندن به کتابخانه‌ها، فایل‌های پیکربندی، فایل‌های احراز هویت X و سوکت X است. .PP برخی از این انتزاع‌ها به متغیرهایی متکی هستند که در فایل‌های موجود در دایرکتوری \&\fI/etc/apparmor.d/tunables/\fR تنظیم شده‌اند. این متغیرها در حال حاضر \&\fB@{HOME}\fR و \fB@{HOMEDIRS}\fR هستند. متغیرها را نمی‌توان در محدوده پروفایل تعیین کرد؛ آن‌ها فقط می‌توانند قبل از پروفایل مقداردهی شوند. بنابراین، هر پروفایلی که از انتزاع‌ها استفاده می‌کند باید عبارت \&\fB#include \fR را درج کند یا به نحوی اطمینان حاصل نماید که \&\fB@{HOME}\fR و \fB@{HOMEDIRS}\fR قبل از شروع تعریف پروفایل مقداردهی شده‌اند. ابزارهای \&\fBaa\-autodep\fR\|(8) و \fBaa\-genprof\fR\|(8) به طور خودکار عبارت \&\fB#include \fR را در پروفایل‌های تولیدشده صادر می‌کنند. .SS "ویژگی ABI (Feature ABI)" .IX Subsection "Feature ABI" ویژگی abi به AppArmor می‌گوید که این سیاست بر پایه کدام مجموعه ویژگی‌ها توسعه یافته است. این امر برای اطمینان از این مهم است که هسته‌های دارای مجموعه ویژگی‌های متفاوت، ویژگی‌هایی را که سیاست از آن‌ها پشتیبانی نمی‌کند تحمیل نکنند؛ چرا که این امر می‌تواند منجر به خرابی‌های غیرمنتظره برنامه‌ها شود. .PP هنگام کامپایل سیاست، هم ویژگی abi هسته و هم ویژگی abi سیاست بررسی می‌شوند تا سیاستی ساخته شود که برای هسته سیستم به درستی کار کند. .PP اگر هسته از ویژگی‌ای پشتیبانی کند که در سیاست پشتیبانی نشده است، سیاست به گونه‌ای ساخته می‌شود که هسته آن ویژگی را اعمال و تحمیل نکند. .PP اگر سیاست از ویژگی‌ای پشتیبانی کند که هسته از آن پشتیبانی نمی‌کند، فرایند کامپایل ممکن است قاعده حاوی آن ویژگی را به چیزی که هسته پشتیبانی می‌کند تنزل دهد، قاعده را به طور کامل حذف کند یا کامپایل با شکست مواجه شود. .PP اگر abi سیاست به صورت \fBkernel\fR مشخص شود، آنگاه abi هسته در حال اجرا استفاده خواهد شد. این مقدار هرگز نباید در سیاست‌های توزیع‌شده استفاده شود زیرا با نصب یک هسته جدید می‌تواند باعث خرابی سیستم شود. .PP \fIسازگاری ABI با AppArmor 2.x\fR .IX Subsection "ABI compatibility with AppArmor 2.x" .PP نسخه AppArmor 3 با تشخیص زمان‌هایی که یک پروفایل ویژگی ABI مشخصی ندارد، سازگاری خود را با AppArmor 2.x حفظ می‌کند. در این حالت، کامپایل سیاست یا ویژگی ABI تثبیت‌شده را طبق فایل کانفیگ یا خط فرمان اعمال می‌کند، یا در صورت عدم تعیین هیچ‌یک، از یک ویژگی ABI پیش‌فرض استفاده می‌نماید. .PP مهم است توجه شود که ویژگی ABI پیش‌فرض از ویژگی‌های جدید اضافه‌شده در AppArmor 3 یا بالاتر پشتیبانی نمی‌کند. .SH "مثال (EXAMPLE)" .IX Header "EXAMPLE" یک نمونه پروفایل AppArmor: .PP .Vb 2 \& # which feature abi the policy was developed with \& abi , \& \& # a variable definition in the preamble \& @{HOME} = /home/*/ /root/ \& \& # a comment about foo. \& /usr/bin/foo { \& /bin/mount ux, \& /dev/{,u}random r, \& /etc/ld.so.cache r, \& /etc/foo.conf r, \& /etc/foo/* r, \& /lib/ld\-*.so* rmix, \& /lib/lib*.so* r, \& /proc/[0\-9]** r, \& /usr/lib/** r, \& /tmp/foo.pid wr, \& /tmp/foo.* lrw, \& @{HOME}/.foo_file rw, \& /usr/bin/baz Cx \-> baz, \& \& # a comment about foo\*(Aqs hat (subprofile), bar. \& ^bar { \& /lib/ld\-*.so* rmix, \& /usr/bin/bar rmix, \& /var/spool/* rwl, \& } \& \& # a comment about foo\*(Aqs subprofile, baz. \& profile baz { \& #include \& owner /proc/[0\-9]*/stat r, \& /bin/bash ixr, \& /var/lib/baz/ r, \& owner /var/lib/baz/* rw, \& } \& } .Ve .SH "فایل‌ها (FILES)" .IX Header "FILES" .IP \fI/etc/apparmor.d/\fR 4 .IX Item "/etc/apparmor.d/" .SH "باگ‌های شناخته‌شده (KNOWN BUGS)" .IX Header "KNOWN BUGS" .IP \(bu 4 گزینه‌های mount از تطبیق الگو پشتیبانی می‌کنند اما فلگ‌های mount به درستی با الگوهای مشخص‌شده اشتراک داده نمی‌شوند. به عنوان مثال، \*(Aqmount options=**,\*(Aq باید معادل \*(Aqmount,\*(Aq باشد، اما چنین نیست. (LP: #965690) .IP \(bu 4 هنگامی که فلگ‌های معینی از دستور mount استفاده می‌شوند ممکن است تطبیق با fstype انجام نشود. به طور مشخص، تطبیق fstype در حال حاضر فقط هنگام ایجاد یک mount جدید کار می‌کند و نه remount، bind و غیره. .IP \(bu 4 قواعد mount با چند شرط \*(Aqoptions\*(Aq طبق مستندات اعمال نمی‌شوند بلکه به گونه‌ای ادغام می‌گردند که \*(Aqoptions in (ro,nodev) options in (atime)\*(Aq معادل \*(Aqoptions in (ro,nodev,atime)\*(Aq خواهد بود. .IP \(bu 4 هنگام مشخص کردن گزینه‌های mount با شرط \*(Aqin\*(Aq، با تعیین هر کدام از مقادیر مثبت یا منفی، هر دو مقدار تطبیق داده می‌شوند. به عنوان مثال، هنگامی که \*(Aqro\*(Aq مشخص شده باشد \*(Aqrw\*(Aq نیز مطابقت می‌یابد و هنگامی که \*(Aqnodev\*(Aq مشخص شده باشد \*(Aqdev\*(Aq نیز مطابقت می‌یابد، به طوری که \*(Aqoptions in (ro,nodev)\*(Aq معادل \*(Aqoptions in (rw,dev)\*(Aq خواهد بود. .SH "همچنین ببینید (SEE ALSO)" .IX Header "SEE ALSO" \&\fBapparmor\fR\|(7)، \fBapparmor_parser\fR\|(8)، \fBapparmor_xattrs\fR\|(7)، \fBaa\-complain\fR\|(1)، \&\fBaa\-enforce\fR\|(1)، \fBaa_change_hat\fR\|(2)، \fBmod_apparmor\fR\|(5) و .