becouse the SELinux people don't want to have this in their code for one
thing.
you seem to be ignoring the SELinux people who say that pathnames are
fundamentally different from labels, labels stay with the data if the file
is renamed, path names do not. multiple hard-links to the same file will
always have the same label for SELinux, but could have very different
permissions with AA
labels are part of policy, policy is not supposed to be decided by the
kernel.
SELinux treats all files with the same label the same. to have the same
ability to treat every file differntly that AA has SELinux would have to
give every file a different label.
how will you know how many labels you need to put into your policy that
you load into the kernel?
how will the kernel figure out what label to use for a file
and the userspace code that converts the policy needs to know the names
when it feeds the policy into the kernel.
and you still need to implement the new LSM hooks that AA is asking for to
figure out what the path to a file is.
the policy mechanism is supposed to be the LSM hooks, and AA is trying to
re-use them.
after you change SELinux to be able to do everything that AA does then you
can tell SELinux to act like AA, true but irrelavent.
first off, and for the record, it's not _my_ implementation. I have
nothing to do with writing AA.
I am just someone who manages hundreds of servers for which AA would be a
good fit. In the past I've gone to a lot of effort to get less security
then AA would provide to implement seperate services in seperate chroot
sandboxes. I'm looking for easier and better options, I've looked at
SELinux and don't believe that I can produce a reasonable policy in a
reasonable amount of time (and I don't trust distro vendors to do it for
me, they have to allow a lot of things that don't make sense on my
systems, and I occasionally need to allow something that wouldn't make
sense in the general case, let alone all the software I run that the disto
doesn't know anything about)
chroot sandboxes, virtual machines, containers all have the problem that
when you need to have more then one application interacting they need to
be put togeather and the basic mechanism doesn't provide you any security
against each other.
SELinux is aiming for 'perfect' security, I'll readily admit that, just
like I'll admit that AA is only aiming for 'good enough' security, but
that 'good enough' security would help me and I don't see any way to get
to SELinux's 'perfect' security.
I also don't care about the details of how it gets implemented, but when
the AA people have a working implementation, and the SELinux people are
strongly opposed to the concept, I don't see any advantage in trying to
get the AA people to throw away a lot of their working code to try and get
people (many of who have be very insulting frankly) to accept such
fandamental changes.
if the SELinux people had responded to the announcement of AA with "that's
a nice idea, if we add these snippits from your code to SELinux then we
can do the same thing" it would be a very different story.
but as always patches talk louder then anything else, if you believe that
the efforts should be combined so strongly why don't you start submitting
the appropriate patches to SELinux to make it able to do what AA does?
David Lang
-
