SELinux always makes me feel like I'm a complete idiot (the worst thing about that is that I could be an idiot and not know it or refuse to acknowledge it).
So, maybe this introduction will make it a little more accessible.
So, maybe this introduction will make it a little more accessible.
I set up a hidden ssh service which was initially fine but after a reboot it failed with some weird permissions issue I couldn't figure out. Turns out this was some weird misconfiguration in SELinux for the Fedora tor package which afaik is still unresolved.
https://bugzilla.redhat.com/show_bug.cgi?id=1279222
https://bugzilla.redhat.com/show_bug.cgi?id=1250893
https://bugzilla.redhat.com/show_bug.cgi?id=1375369
There's more of these floating around if you search for the right terms. If SELinux was widely well-understood then this would be a pretty simple issue to identify and resolve (note: I'm not well versed enough in it - I've applied a workaround and have resolved to return and fix it properly "later") but it doesn't appear that this is the case
sealert -a /var/log/audit/audit.log
I sat the RHCE course/exam recently and the Red Hat trainer dealt with this in... amusing... ways.
Unfortunately, fixing things properly requires knowledge, if only of where to find the information. Thinking solely about file contexts, it's not easy to for example search them. e.g. "show me all contexts related to samba" so you can find the share rw label. (One of the RHEL 7.0 man pages suggests the nfs rw label which doesn't work, had to make a point of remembering that for the exam!) Everything's spread across selinux's man pages, service's man pages... ugh.
$ sesearch -A -s some_app_t -c file -p read -p write
allow some_app_t some_type_t:file { read write };
allow some_app_t some_other_type_t:file { read write };
allow some_attribute_of_some_app_t yet_another_type_t:file { read write };
$ sesearch -A -t some_type_t -c file -p read -p write
allow some_app_t some_type_t:file { read write };
allow some_other_app_t some_type_t:file { read write };
In this specific case, you're looking for samba_selinux. It's not perfectly written, but it should at least cover all the relevant information: (https://linux.die.net/man/8/samba_selinux). You mentioned looking for the read/write share label, and that's specifically discussed, and described with examples.
You can also use sesearch to query your selinux policy for more information about anything mentioned in that man page. For example, to understand the implications of setting samba_enable_home_dirs you can run `sesearch -A -b samba_enable_home_dirs`. You can run similar queries for file types, process types, port types, etc. If you really want a list of every type relevant to samba, you can run: `sesearch -A -s smbd_t`. If you wanted to use sesearch to find everything smbd_t can write to, as an alternate method of discovering public_content_rw_t, you can filter that, like: `sesearch -A -s smbd_t -p write -d -c file -C`. This will also show you that the public_content_rw_t rule is conditional on the smbd_anon_write boolean.
I used to teach RHCE courses and exams; I'm curious about the amusing ways of dealing with selinux you encountered.
I feel like having to worry about complex SELinux configuration isn't going to matter as much for people who start to use containers. Most distributions have SELinux profiles for docker that work, and containers provide a decent level of isolation.
They're not as good as full VMs, and a kernel exploit can still break out of a container, but if you're running all your own in house/trusted code on your container system, it seems like a pretty good trade-off for isolation/security.