hi, i have a query if i want to start a completely custom made service .i have defined all the transitions and types.now i need only the allow rules. what is the difference between (going to permissive mode and checking the logs to generate the entire set of policy's allow rules ) and ( generating the allow rules one by one after updating the policy again and again in the enforcing mode ).i find it easier to generate the entire set of allow rules switching to permissive mode.is there any chance that i may miss a rule if i switch to permissive mode and generate the rules from the logs or say i give extra permissions ?
which is the preffered method?.
On 01/05/2010 09:03 AM, sai ganesh wrote:
hi, i have a query if i want to start a completely custom made service .i have defined all the transitions and types.now i need only the allow rules. what is the difference between (going to permissive mode and checking the logs to generate the entire set of policy's allow rules ) and ( generating the allow rules one by one after updating the policy again and again in the enforcing mode ).i find it easier to generate the entire set of allow rules switching to permissive mode.is there any chance that i may miss a rule if i switch to permissive mode and generate the rules from the logs or say i give extra permissions ?
which is the preffered method?.
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
If you are using F11/F12 you can setup a permissive domains
permissive myapp_t;
This will allow you to run the machine in enforcing, but your new domain in permissive mode.
We almost always develop policy in permissive mode, but you have to be aware that sometimes you can deny something and cause an application to go down a different code path. For example, apps that use the pam stack attempt to read shadow_t, if you dontaudit this, the app will execute a helper application to read the shadow file. This is considered more secure.
On 01/05/2010 03:03 PM, sai ganesh wrote:
hi, i have a query if i want to start a completely custom made service .i have defined all the transitions and types.now i need only the allow rules. what is the difference between (going to permissive mode and checking the logs to generate the entire set of policy's allow rules ) and ( generating the allow rules one by one after updating the policy again and again in the enforcing mode ).i find it easier to generate the entire set of allow rules switching to permissive mode.is there any chance that i may miss a rule if i switch to permissive mode and generate the rules from the logs or say i give extra permissions ?
which is the preffered method?.
Well it is not black or white in my opinion. Both have drawbacks.
You cannot without testing know whether you defined all transitions. Atleast not transitions to external domains.
If you test in permissive mode you must be very careful with what you add especially when your domain executes external executable files.
Questions like should i domain transition or run in the local domain are important. Implementing a domain transition will change the whole scenario.
So if you test in permissive, than during the first run, check for execute_no_trans in your AVC denials. Then decide whether it is best to transition or execute_no_trans there.
If you decide to transition then basically your current batch of AVC denials becomes useless. You would only add the domain transition policy to you module, rebuild, reinstall and retest again.
Testing in enforcing mode is a pain.
On newer systems you can also use "Permissive domains". When you use this you can run single domain types permissive as opposed to the whole system. This is a nice feature and i consider this my favorite.
You will still have to be aware of implementing possible domain transitions before anything else to avoid adding more policy than strictly required.
Another thing you should keep in mind when using "Permissive domains" is that although the local domain is permissive; external domains interacting with the local domain are strictly enforced.
Thus, Although your local domain type is permissive, it can still fail to run. Simply because some external domain is denied interaction with objects owned by the local domain or domain types owned by the local domain.
So in a nut shell:
Permissive domains: pros: saves time cons: external domain interacting with local permissive domain are still denied on each system call they make. cons: make sure you domain transition first (if required) before adding other policy
Permissive mode: pros: saves even more time cons: system is unprotected. cons: make sure you domain transition first (if required) before adding other policy
hth
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
On Tue, 2010-01-05 at 19:33 +0530, sai ganesh wrote:
hi, i have a query if i want to start a completely custom made service .i have defined all the transitions and types.now i need only the allow rules. what is the difference between (going to permissive mode and checking the logs to generate the entire set of policy's allow rules ) and ( generating the allow rules one by one after updating the policy again and again in the enforcing mode ).i find it easier to generate the entire set of allow rules switching to permissive mode.is there any chance that i may miss a rule if i switch to permissive mode and generate the rules from the logs or say i give extra permissions ?
which is the preffered method?.
One other item to keep in mind about permissive mode: When in permissive mode, SELinux only logs the first instance of a given permission denial, i.e. once per (process security context, object security context, object security class, permission) tuple and then SELinux silences further denials on that same permission by granting the permission until the administrator switches to enforcing mode or reloads the policy. This is to avoid flooding syslogd or auditd with repeated denials on the same permission, and to avoid unnecessary duplication in the logs as the duplicates would yield the same allow rule regardless. It can however mask denials on different subjects/objects that happen to be in the same security context.
See: http://marc.info/?t=122953404700001&r=1&w=2
selinux@lists.fedoraproject.org