By observing this log entry, it is possible to build a rule that would allow this operation. For example, <literal>allow syslogd_t device_t:fifo_file { read write }</literal>. This process can be automated, and it is exactly what the <command>audit2allow</command> command (of the <emphasis role="pkg">policycoreutils</emphasis> package) offers. This approach is only useful if the various objects are already correctly labeled according to what must be confined. In any case, you will have to carefully review the generated rules and validate them according to your knowledge of the application. Effectively, this approach tends to grant more rights than are really required. The proper solution is often to create new types and to grant rights on those types only. It also happens that a denied operation isn't fatal to the application, in which case it might be better to just add a “<literal>dontaudit</literal>” rule to avoid the log entry despite the effective denial.
من خلال دراسة مدخلة السجل هذه، يمكننا بناء قاعدة تسمح بهذا الإجراء. مثلاً: <literal>allow syslogd_t device_t:fifo_file { read write }</literal>. يمكن أتمتة هذه العملية، وهذا بالضبط ما يُقدِّمه الأمر <command>audit2allow</command> (من الحزمة <emphasis role="pkg">policycoreutils</emphasis>). يفيد هذا الأسلوب فقط إذا كانت الكائنات المختلفة موسومة مسبقاً بشكل صحيح وفقاً للعملية التي يجب تقييدها. في جميع الحالات، عليك مراجعة القواعد المولدة بحذر والتحقق من صحتها على حسب معرفتك بالتطبيق. في الواقع، تميل هذه الطريقة لمنح صلاحيات أكثر مما يلزم فعلاً. الحل الأنسب غالباً هو إنشاء أنواع جديدة ومنح الصلاحيات على هذه الأنواع فقط. كما قد تصادفك أيضاً إجراءات لا يكون حظرها مصيرياً بالنسبة للتطبيق، وفي تلك الحالة قد تكون إضافة ”<literal>dontaudit</literal>“ فقط لتفادي تسجيل مدخلة في السجل رغم حظر الإجراء أفضل.