Selinux: (not) "Black Voodoo Magic?"

[Ivan Gyurdiev]

>>
>> Could SELinux be used to prevent this and, more generally, disallow
>> replacement of rpm-controlled files even by the root user ?
>
> One of the SElinux guys can probably answer that better than I, as I
> don't use SElinux personally, and my knowledge of what all it can
> do, and how to make it do that, is rather limited.  As some of our
> other developers have mentioned before, it's black voodoo magic.

Black Voodoo Magic?

All those complains about how "selinux is hard", and "I have no idea how 
selinux works, I'm turning it off" make no sense to me. Selinux policy 
follows what your code does, and establishes a bound around what it's 
allowed to do. If you're able to understand thousands of lines of 
complex code (in a project such as the X server), then surely you can 
figure out the (much simpler) security box around it, and change it to 
your advantage. The job of the selinux developers (figure out each and 
every detail of X, so it will never leave the security box, and fail) 
seems harder to me.

Ultimately a failure in selinux means that either (1) your application 
is doing something it shouldn't, or (2) the selinux developers' did not 
anticipate or understand that your application would need such 
privileges. Policy writing is a manual project at this time. Some people 
have mentioned to me that it might be possible to automate certain parts 
of it, but this isn't available today...

I agree with the earlier poster, which said application developers 
should help with policy. If you are interested in that, you can look at: 
http://serefpolicy.sourceforge.net/, download the code, and at least 
have a look at the policy for your project (if one is available), and 
point out any critical flaws in it on the fedora-selinux list. I'm sure 
patches are also welcome.

========================

I'm not currently involved with policy development, so questions would 
be better directed at the selinux list.
However, I have written some policy in the past, so here's what my 
suggestions would be (follow at your own risk):

1. policy is a collection of language rules, as described here: 
http://www.nsa.gov/selinux/papers/policy2/x107.html
2. later extended by Tresys to this: 
http://sepolicy-server.sourceforge.net/index.php?page=module-language
3. that are later processed through m4, which allows simulation of 
"functions" and "if-else" statements (now organized in modules, with 
api, which get compiled and linked in two steps)

4. reading all the above is very useful, but in the short run you can 
follow existing patterns to learn what's going on

5. everything that is not specifically allowed is denied
6. A typical rule is:
      allow { src1_t src2_t } { target1_t target2_t }:{ class1 class2 } 
{ permission1 permission2 }.
    Things that end in _t are types - they're defined with the "type" 
language rule.

    class1, class2 are typically things like: file, dir, fifo_file, and 
are defined in flask/security_classes
    permission1, permission2 are specific to the above class, and are 
defined in flask/access_vectors.
 
    This rule allows subjects in { src1_t src2_t } to act on objects in 
{ target1_t target2_t } of type { class1 class2 } in ways { permission1 
permission2 }.  The set notation above expands as a cartesian product.

7) Because m4 expansion is used, things are written in if-else 
statements (conditioned on things called booleans), and in 
functions/interfaces. This has the drawback of having a steep learning 
curve, because you might not be familiar with the other macros being 
called. I suggest use of grep, and 
http://serefpolicy.sourceforge.net/api-docs/ to figure it out. It would 
be absolutely wrong to write only low-level rules - the policy structure 
should model the program being confined. Things in a shared library 
should go into a shared interface.

8) Follow existing patterns. Interfaces go in the .if file (they take 
arguments $1, $2), other rules go in the .te file, file context labels 
go in the .fc file.

9) Important concepts are:
      domain transition (this is how you get out of your domain, and 
into another one, potentially causing havoc there).
      type transition (this is how your program sets the context of your 
files to something other than the parent directory, without modifying 
the application code - black magic! automatic chmod. very useful in 
practice)
 
     Grep for domtrans/filetrans/domain_auto_trans in the policy, I'm 
not sure what those are called nowdays, but it shouldn't be hard to 
figure it out.