On Thu, Jun 25, 2020 at 8:54 PM Samuel Sieb <samuel@sieb.net> wrote:
On 6/24/20 12:03 PM, Iñaki Ucar wrote:
> Thanks. I found another tutorial (from RedHat) which basically says:
>
> 1. Implement your service, give it a new SELinux type and run it.
> 2. Collect all the complaints from SELinux.
> 3. Use audit2allow to convert them to rules.
> 4. Repeat until you don't get any more complaints.
>
> And I cannot believe my eyes. Is this *really* the way to implement
> SELinux policies? It seems like a joke to me. Isn't there any notion
> of inheritance or something like that? Like, I want my type to have

I suppose that's the "easy" way.  The better way would be to figure out
what permissions and transitions your service needs and write the rules
for that.
You are right as nobody else but the developer can be aware of which permissions are actually needed: SELinux can also help with finding bugs in the app so it is not always reasonable to allow every permission audited.

There are tools which can support you in the beginning, like sepolicy generate. Some of the audited denials are easy to understand, for some it needs to be figured out what they mean:
https://selinuxproject.org/page/ObjectClassesPerms

If your goal is to confine the application, you should follow this documentation:
https://fedoraproject.org/wiki/SELinux/IndependentPolicy
The selinux-policy devel package, e. g. the example.?? files, can work as a source of inspiration.

_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


--

Zdenek Pytela
Security controls team