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.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
