Graphics are far from professional level, unfortunately. I would throw away coloring idea. Instead, I'd put a decent graphics. It could be even made into some simple story.
> The SELinux primary model or enforcement is called type enforcement.
"or" should be "of" or "for". I'm not sure which, because it doesn't even tell you what enforcement means.
First page:
> Imagine a system where we define types on objects like cats and dogs.
"On" isn't a preposition you usually use with "type". You can say things have a type, or are a type, but "define a type on" is a unfamiliar construction.
> A cat and dog are process types.
I'm confused. Do they have types defined on them, or are they the types? Earlier, it said they are objects, now they are process types?
> We have a class of objects that they want to interact with which we call
food. And I want to add types to the food, cat_chow and dog_chow.
Using "they" to refer to a noun from the previous page is a little confusing. "food" should be quoted. You can start a sentence with "And", but it feels gratuitous here since the previous sentence is short.
> As a policy writer, I would say that a dog has permission to eat dog_chow
write this rule in policy, as shown below.
What happened between "dog_chow" and "write" here? The latter half looks like a random fragment of text. What is a "policy writer"?
> food and a cat has permission to eat cat_chow food. In SELinux we would
The last two sentences that you complain about are on a two-page spread: "As a policy writer, I would say that a dog has permission to eat dog_chow food and a cat has permission to eat cat_chow food. In SELinux we would write this rule in policy, as shown below."
This is one of the weirder artifacts I've come across lately. One of those things for which I like to imagine how a far-future archaeologist would react to it.
That is, if we still made documents that will be around for far-future archaeologists to puzzle over.
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.
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.
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
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.
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.
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.
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.
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.
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.
At the point you have to make a "cute" coloring book (for adults) to make your OS seem more friendly, maybe it's time to reflect on the reality that there's something fundamentally wrong with the reasoning used to justify the logic required to use it.
You may not like the approach, but, please, stop using "infantilization" argument. Not all comic books and animated movies are for kids, even though they look like it might be the case.
Here, it may open the subject for broader audience. It is easier to comprehend even for a layman. And even if you're not the one, you could dig in - just for fun.
While I do enjoy some comic book and/or tv shows I did find this book a bit infantilizing. This looks more like Teletubbies than Rick and Morty if you see what I mean.
"Hey, I've heard you're too much of a dumb-dumb to get SELinux to work? Maybe if we turn it into an episode of Dora the Explorer you'll get it this time! Don't forget to renew your RHEL subscription by the way."
This trend of using illustration to explain complex topics is really wonderful. I know that people may criticize it as childish, but I find it helpful and enlightening.
The illustrations that I've found most amazing and well done are created by people like:
You may notice a trend with the gender of the authors above. I personally believe that women have a better sense for simplifying complex ideas, and greater empathy and patience for teaching those ideas once they've been made simple.
It is a question of personal taste. I personally don't like it, there's too much distraction and too little substance. It might be interesting to illustrate some concept, but not everything imo.
I wonder if it's because a colouring book is not a Serious Adult thing, and women have - or allow themselves - a bit more wiggle room to not be Serious Adults all the time.
When Google Chrome first came out in 2008, they used a series of cartoons to explain their innovations (multi-process browsing, JIT compilation for JS, etc).
I love this idea. It's not meant to teach people everything, but it shows the basic SELinux concepts in a fun manner, that is different from the typical dry written documentation.
The best utility that this has is that it gets people asking questions. I could put this on my wall at work, and then when my colleagues ask about it, I could use it to segue into actually teaching them about SELinux. Putting the SELinux text documentation on my wall would not have the same effect.
The problem with SELinux is not really in the beginner documentation, but in the documentation of the policy macro packages eg. in Fedora -- which are what you in the end should/need to use for actually writing or modifying policies.
Answers to questions on eg. finding the difference between "userdom_user_application_domain" and "application_domain", or learning that "~/.local/share" has the symbolic name "data_home_t" are very difficult to find. Everything in SElinux has a symbolic name, so there's also at least one more layer of indirection as compared to apparmor.
I don't necessarily think that the illustrations are what makes this great. They're cute, but the simple and explicit examples with uncontrived situations are what really makes this worthwhile.
It may be that getting into "writing for a coloring book" mode makes people think simpler and "cuter," which lends itself well to quick illustration of complex ideas.
I'd like to see more of this kind of explanation in guides and manuals in general, with the "normal" manuals being for reference when people need to drill down into something specific.
56 comments
[ 2.9 ms ] story [ 201 ms ] threadVery first sentence:
> The SELinux primary model or enforcement is called type enforcement.
"or" should be "of" or "for". I'm not sure which, because it doesn't even tell you what enforcement means.
First page:
> Imagine a system where we define types on objects like cats and dogs.
"On" isn't a preposition you usually use with "type". You can say things have a type, or are a type, but "define a type on" is a unfamiliar construction.
> A cat and dog are process types.
I'm confused. Do they have types defined on them, or are they the types? Earlier, it said they are objects, now they are process types?
> We have a class of objects that they want to interact with which we call food. And I want to add types to the food, cat_chow and dog_chow.
Using "they" to refer to a noun from the previous page is a little confusing. "food" should be quoted. You can start a sentence with "And", but it feels gratuitous here since the previous sentence is short.
> As a policy writer, I would say that a dog has permission to eat dog_chow write this rule in policy, as shown below.
What happened between "dog_chow" and "write" here? The latter half looks like a random fragment of text. What is a "policy writer"?
> food and a cat has permission to eat cat_chow food. In SELinux we would
We would what?
This is one of the weirder artifacts I've come across lately. One of those things for which I like to imagine how a far-future archaeologist would react to it.
That is, if we still made documents that will be around for far-future archaeologists to puzzle over.
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
[1] https://www.youtube.com/watch?v=MxjenQ31b70&t=1s
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.
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.
https://github.com/fedora-selinux/selinux-policy
https://news.ycombinator.com/item?id=13783975
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.
... is right about the point where you've lost completely. what is this nonsense? This infantilization of adults is insane.
Here, it may open the subject for broader audience. It is easier to comprehend even for a layman. And even if you're not the one, you could dig in - just for fun.
A picture is worth a thousand words, they say.
"Hey, I've heard you're too much of a dumb-dumb to get SELinux to work? Maybe if we turn it into an episode of Dora the Explorer you'll get it this time! Don't forget to renew your RHEL subscription by the way."
the selinux one is just a cute marketing move for red-hat to sell courses
Finally managed to get it working and get all my sensitivities and categories set up the way I wanted them. Wasn't fun at all.
Before I started I had this idea I was going to use it all the time for all my data. That didn't last long.
(I also have a video explaining some specific/common things: https://serversforhackers.com/video/battling-selinux-cast)
The illustrations that I've found most amazing and well done are created by people like:
Lin Clark (https://code-cartoons.com/)
Julia Evans (http://jvns.ca/zines/)
Linda Liukas (http://www.helloruby.com/)
Amy Wibowo (https://shop.bubblesort.io/)
You may notice a trend with the gender of the authors above. I personally believe that women have a better sense for simplifying complex ideas, and greater empathy and patience for teaching those ideas once they've been made simple.
SELinux is not a "complex idea", SELinux is a tool with subpar documentation.
A coloring book does nothing to fix that.
Here's an edition from 17 years ago: https://www.amazon.co.uk/Human-Brain-Coloring-Book-Concepts/...
https://www.google.com/googlebooks/chrome/
Boy, I can't wait to tell my 5 year old about SELinux!
The best utility that this has is that it gets people asking questions. I could put this on my wall at work, and then when my colleagues ask about it, I could use it to segue into actually teaching them about SELinux. Putting the SELinux text documentation on my wall would not have the same effect.
Answers to questions on eg. finding the difference between "userdom_user_application_domain" and "application_domain", or learning that "~/.local/share" has the symbolic name "data_home_t" are very difficult to find. Everything in SElinux has a symbolic name, so there's also at least one more layer of indirection as compared to apparmor.
here's a couple lost pages found by the grsecurity folks:
https://grsecurity.net/~spender/pics/lost_selinux_coloring_b...
https://grsecurity.net/~spender/pics/lost_selinux_coloring_b...
:)
It may be that getting into "writing for a coloring book" mode makes people think simpler and "cuter," which lends itself well to quick illustration of complex ideas.
I'd like to see more of this kind of explanation in guides and manuals in general, with the "normal" manuals being for reference when people need to drill down into something specific.