David Boles wrote:
Protection? Do you mean does SElinux actually stop unauthorized disk
and file access? Sure it does. At time too well. It stops things that
some people want.
I mean cases where the standard unix mechanisms failed first, then
selinux did
something useful.
Now I am confused. What is "standard unix mechanisms"? Please clarify that
statement for me.
Traditional unix security is very simple. Every process has a user and
group id, typically
inherited from its parent process and all access to files and devices
depends on the
modes set in the inodes and tests applied during the open() of the
file/device based
on the relationships of the uid/gid and modes. It is all very easy to
understand.
Nothing 'standard unix mechanisms' that I can think of does
what SElinux does. Or is supposed to do.
Yes, that is my point. I'm looking for real cases where someone has
subverted
a program to gain access to some uid that he should not normally be able to
use, but was prevented from doing damage by the additional selinux
restrictions. Windows NT made a lot of claims about being more secure
than unix too and the theories sounded good, but it didn't pan out in
practice.
I just want to see where this has worked in practice. I'm not
convinced yet
that making security concepts less understandable is the way to make things
more secure or that adding a lot of new and complex code is the way to
reduce
security flaws. What have you seen that convinces you otherwise?
Have you actually looked and found
out what it is that SElinus does? Or, again, it is supposed to do?
My impression is that it imposes additional restrictions based on
processes. However
modern distributions assign unique uids to most system processes and
traditional
file ownership and modes to restrict a subverted process from being able
to do
much damage to anything except the ones that selinux would also have to
permit for that program's normal operation.
--
Les Mikesell
lesmikesell@xxxxxxxxx
