3 ms·

> I'm still to find a decent document that starts from the simple stuff and lets one build a mental concept of how it works before jumping into the more complic

> I'm still to find a decent document that starts from the simple stuff and lets one build a mental concept of how it works before jumping into the more complicated (real-world) use cases. Well, there is this: https://people.redhat.com/duffy/selinux/selinux-coloring-book_A4-Stapled.pdf https://people.redhat.com/duffy/selinux/selinux-coloring-boo... You can link it to repeat offenders who disable SELinux. (That might not be a good idea.)

reitanqild 10y ago
Read that a while ago and it didn't make it click for me. If I had just stumbled across it without a recommendation and without recognising the bame of the author I'd easly dismissed it as some kind of trolling but thats maybe just me. What I want is: 1. How to do tasks x, y and z (with explanations on why). 2. Complete documentation of all commands, settings files etc. Usually 2. is somewhat covered in the official docs and 1. is available in blog posts etc. Last I checked 1 was not covered in any way when it comes to SELinux. Making a coloring book out of it is nowhere on my list.
- reitanqild 10y ago
  To late to edit but let me be perfectly clear that I am totally fine with people making coloring books etc, i just wish there was more how-to, but that might just be me.
hobarrera 10y ago
That sounds pretty cool, but where do rules come from? Suppose some author wrote some daemon. Is the packager responsible for writing the rules? It sounds like having packagers understand SELinux rules is a lot of responsibility, and if upstream is cross-platform, they might not care about such specific needs so as to provide it. Also, what happens if I write some small app? Do I need to write its rules? If it has no rules applied to it, then it's basically game over, because SELinux sounds like it works ONLY if it applies to all processes.
- snuxoll 10y ago
  A packager is generally responsible for selinux policies if they aren't suitable for inclusion in the core policy, as a developer if you want to write them please do but certain aspects rely on things like where binaries and application data are stored so you can't always write a policy that won't need tweaking on a specific distribution. SELinux policies take some time to write the first time or two, but typically running in permissive mode and running your app with a permissionless context will give you everything you need to include in one. Admins have the hard job when they move default data directories around, takes time to get used to running 'semanage fcontext' in addition to setting file system permissions.

reitanqild 10y ago

Read that a while ago and it didn't make it click for me. If I had just stumbled across it without a recommendation and without recognising the bame of the author I'd easly dismissed it as some kind of trolling but thats maybe just me. What I want is: 1. How to do tasks x, y and z (with explanations on why). 2. Complete documentation of all commands, settings files etc. Usually 2. is somewhat covered in the official docs and 1. is available in blog posts etc. Last I checked 1 was not covered in any way when it comes to SELinux. Making a coloring book out of it is nowhere on my list.

reitanqild 10y ago
To late to edit but let me be perfectly clear that I am totally fine with people making coloring books etc, i just wish there was more how-to, but that might just be me.

hobarrera 10y ago

That sounds pretty cool, but where do rules come from? Suppose some author wrote some daemon. Is the packager responsible for writing the rules? It sounds like having packagers understand SELinux rules is a lot of responsibility, and if upstream is cross-platform, they might not care about such specific needs so as to provide it. Also, what happens if I write some small app? Do I need to write its rules? If it has no rules applied to it, then it's basically game over, because SELinux sounds like it works ONLY if it applies to all processes.

snuxoll 10y ago
A packager is generally responsible for selinux policies if they aren't suitable for inclusion in the core policy, as a developer if you want to write them please do but certain aspects rely on things like where binaries and application data are stored so you can't always write a policy that won't need tweaking on a specific distribution. SELinux policies take some time to write the first time or two, but typically running in permissive mode and running your app with a permissionless context will give you everything you need to include in one. Admins have the hard job when they move default data directories around, takes time to get used to running 'semanage fcontext' in addition to setting file system permissions.