Thomas Bleher wrote:
* Peter Dolding <[EMAIL PROTECTED]> [2007-10-22 09:54]:
Lets start with a few basic problems I have found with all LSM's I have tried.
Number 1 they forget users might need to limit applications without
administrators approval and only locally. This is like running
Firefox locked out from seeing a particular directories choose by the
user because the user know they contain stuff that should not be seen
online. Most of the limitations a system admin can apply to
applications users need to be able to apply to there own. Of course
user should never be able to grant more permissions than what they
have.
Yes, this is an important capability, but you don't need kernel support
for that. For SELinux, look at the SELinux Policy Management Server
(http://oss.tresys.com/projects/policy-server).
Using the Policy Management Server, you could allow your users to create
an arbitrary number of confined domains, where the user decides how much
access the confined domain gets, yet no domain can access anything the
user cannot.
I'm sure something like that could be written for other security
modules.
Point your are dealing with users. They are not people you want to
teach 10 to 12 different systems to. Also with 10 to 12 different
system to set the limitations from applications to allow applications to
take control of there security risks. This is just been too hard on
developers. This is also depending on Selinux to be loaded to work.
Best way is a common limitation system like posix permissions common to
all LSM. Not dependent at all on a LSM module being there. Also since
its common can build build into file managers and wm's for users. Using
a policy server is just a hack. IBM and posix file caps is heading the
right way. Always available and tidy.
Number 2 most are attempting to fix the suid and the guid bits defects
yet it never is attempted to be addressed kernel fault/Posix design
fault. Posix file capabilities get close. Even that these cannot be
used to replace suid and guid they should be made able to used to
provide limitation to them.
I think you should more clearly explain which "defects" you mean.
For SELinux, there was some discussion of granting capabilities through
policy, but I'm not sure what the status of that patch is (it is
certainly not in mainline yet). This would make it possible to remove
almost all suid bits on a SELinux system.
Not sure if that's what you mean.
Still again depending on SELinux module to fix. User disables it you
now have pants down. Correct answer to suid bit problem is like posix
file caps that are there even without a LSM module.
Problem is at moment posix file caps just stop a little short of killing
that problem of suid off without a LSM. Posix file caps cannot be used
to limit the function of a suid bit or be used to replace the suid bit
forever.
Some things should be main kernel patches nothing to do with a LSM since
they are design defects causing security defects. Using LSM to fix a
design defect is the incorrect thing to be doing.
This is a future one I have not seen a security containers so that
different sections of a virtual server could use different security
modules.
As has already been discussed on this list, security properties are
"whole machine" properties. At least for MAC systems like SELinux, I
don't think partitioning a system like that is possible or sensible. If
you really need different security modules, use different kernels and
something like KVM.
Its down right possible. But it requires a major over haul of how LSM
works.
Crispin with apparmor is also making the simlar point so I will be generic.
Container level device secuirty and other access rights. Basically the
Container all ready has a MAC. So in some ways have a LSM in at this
point is already overlapping.
KVM and lguest is still not good solution. There is no sharing of
resources. Lets say 2 OS running the same LSM and all with another 2 OS
running a different LSM.
If working inside containers lower memory usage. If KVM XEN or whatever
no memory sharing.
Lower memory usage more servers per machine. So value extractable from
one machine is higher. So this is a simple game of dollars. No matter
the logic you try to apply money is the game.
Now what are the overhaul to LSM. Is to see you all need common
features. This is like Virtual Servers vs Containers. All Virtual
Servers need the features of Containers so containers are build common.
Basically there should be a list of needed features to enforce
security. Just like posix file caps can replace some of the need for
LSM's. By LSM's using equal to removes need for duplication in kernel
at processing and reduces hooking requirements.
Basically the giant hooking mess using current model will not work with
contianers.
So if LSM are using common existing parts to do there job there could be
no difference between running 1 to running 1000 LSM's side by side.
The speed problems you are point to are a design problem. Because LSM's
should not need to stack more than 2 deep and need overlapping hooking.
The containers only overlap point could be devices. So one deep the
rest of the time.
Basically LSM split into two halfs enforcing and controlling. The
difference inside containers is just changing the controller.
This is like the overhaul Virtual Server solutions for Linux are working
threw. Containers will provide many more advantages than inserting one
or another Virtual Server solution into linux.
Same is true with redesign of the LSM system to get as much as possible
shared between LSMs. Also allowing more security to remain with LSM's
disabled.
Apparmor and Selinux idea for containers is basically not up to snuff.
Both are forcing server rooms to split by LSM.
Idea of containers is that each container can basically a whole machine
from the point of view of the software contained. This is the reason
why each container can have its own root user and so on. So each
container should be able to have its own LSM.
If it means completely redoing you models that is what needs doing. Yes
idea of whole machine is different once you start adding containers.
Model need to change. Static embedding LSM misses what is needed.
Now you are welcome to come up with a passive system. But this will
require the means to disable and enable selinux or apparmor or any other
LSM on a container by container bias. This already screws MAC models
and is more risky.
You also don't want to have to restart machines to add a feature a
client wants. Or be reducing the number Virtual Servers you can fit on
the hardware.
Nice little balancing act. Note that is high end there is also a need
low end of this as well.
Low end has another problem. Its called opengl note kvm lguest and xen
cannot cope well with opengl. Since you are on one kernel with
containers it can. Now heres the kicker. Selinux and Apparmor and
other LSM's not working as one stop users from installing different
distros with there security enabled. So users will have two options.
Fly by seat of pants without LSM. Or try to make it fit. Past history
says they will run by seat of pants.
So your ideas are dead in water costs at one end and forces unskilled
users to run weak system at the other. Mine might not be perfect but
something has to be done to come up with a valid solution.
Peter Dolding
-
To unsubscribe from this list: send the line "unsubscribe
linux-security-module" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
