You're not an idiot and you're not alone. In fact even those who you might expect to know it get it wrong and struggle to figure out what's gone on. For example recently I decide I didn't know systemd very well so picked a random service to setup and play with (tor) and a distro that uses systemd (Fedora 25).

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

If you're having issues with selinux run:

  sealert -a /var/log/audit/audit.log

Most of the time, that will give you a detailed description of what's going wrong and tell you the command to fix it. Completely changed my opinion on selinux when I learned it. Also, the SELinux For Mere Mortals[1] talk is a great introduction.

[1] https://www.youtube.com/watch?v=MxjenQ31b70&t=1s

It's nice... but the suggestions are often terrible when they could be fixed properly with a bool or changing the context of a directory.

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.

I personally feel like the included man pages on RH distros for selinux discussion on specific topics are quite good. You can see the full list of these by searching your man database with: man -k _selinux

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.

That "show me all contexts related to samba" is something I'm really missing. I worked one weekend on getting NextCloud to play nicely with SELinux and Apache on Fedora 25 without any dirty tricks, and one thing that would really have come in handy was an accurate list of all the labels related to Apache. The only comprehensive lists I could find online were out-of-date, and the only things that were up to date were single examples.

sesearch is one way of doing it, for example:

  $ 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 };

Or, say you want to do the opposite – you know the label, and want to find all domains that can read and write it:

  $ 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 };

You can use regexes for the parameters if you don't know the exact types (just specify '-r[stcdb]').

I had no idea this existed. Thank you.

I found it to be extremely helpful to check out the Fedora SELinux repositories. They're an excellent reference and full of good examples.

https://github.com/fedora-selinux/selinux-policy

AppArmor took some time to understand, but it wasn't too bad. I've written AppArmor profiles for in-house apps. I realize AppArmor isn't as powerful as SELinux, but I do find it easier to understand.

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.

Such comments made me do a new submission on the original motivation and architecture for it so things might make a bit more sense. At least explain why it's so complex.

https://news.ycombinator.com/item?id=13783975