[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Selinux: (not) "Black Voodoo Magic?"





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.





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]