On 10/29/07, Crispin Cowan <[email protected]> wrote:
> To reject an LSM for providing "bad" security, IMHO you should have to
> show how it is possible to subvert the self-stated goals of that LSM.
> Complaints that the LSM fails to meet some goal outside of its stated
> purpose is irrelevant. Conjecture that it probably can be violated
> because of $contrivance is just so much FUD.
LSM is providing bad security on two fronts.
Number 1 LSM are speeding effort to create features. Apparmor and
Selinux both provide file access filtering from applications. Yet
they double up the code to do it. So they cannot be used with each
other without doubling up hooks. Then other LSM are creating there
own sections of code to do the same thing. Simple rule more code
more risk of bugs since it will be less audited. Duplication defense
features is really bad for security. Some how code sharing has to be
got into LSM construction.
Number 2 The critical bit LSM stop at the edges of applications. Now
without overlapping my hooks with existing LSMs I cannot create
application level protections. Overlapping hooks will cause speed
loss.
LSM is set to protect the application. But inside the application
there will be sections that need the access rights and others that
don't. Now a exploit in any section of the application under LSM gets
the LSM assigned rights. With application level this can be done a
few ways extension to elf that is create by the complier and api calls
lowering access functions of current thread or for a starting thread.
If you exploit a section of the code without access to disk network
access and so on and without the right to call any function that does
that. What have you exploited. Minor data damage compared to
complete data that the application have access to being stolen as what
is the case with LSM at moment. Basically LSM prevent taking control
of the complete system but don't help to stop peoples private data
from being stolen. Both are bad to happen to a person.
LSM design is there to help security development not get in its way or
to cause bitrot. Currently LSM design is causing major risk bitrot in
duplicated code.
Reading and processing configuration files should be independent to
the protection methods. Hopefully designed to be able to run user
mode to test if the new profile for a application is safe to add
before adding it to the OS. Typo prevention on both sides. Current
method of just sticking everything into one huge blob is preventing
code sharing and risking more security holes.
The current LSM design is bad on so many levels. I am surprised that
it takes a Non PHD System Admin to see it. Some how I think its a
empire thing. If everything was just simple blocks a person could
write a new LSM in hours with pretty good security. Compared to
todays long time trying effort. Leads of Apparmor selinux and so on
not being prepared to give up there little empire for the greater
good.
I personally hate stacking as a idea. I personally prefer two layers
only. Config reading and enforcement. Of course that does not stop
applications being assigned to different config reading systems.
Depth the two layers should stay fixed even if you have many different
models in use.
All LSM seam to want to force System Admins to pick there LSM over
another. Instead of being able to pick LSM for task at hand. Same
with poor security being better than no security its true. Its
nothing strange to find selinux based systems with there security
disabled because the Admin cannot configure it. But the reverse is
also true that when you have skilled Admins stuck with a system like
Apparmor cannot harden the system as far as they could with selinux.
Both ways its causing security holes poor security when you should
have good security is bad too. Part of the problem LSM maintainers
are not at the front lines is all I can guess. Because they don't
seam to know what is really needed.
Peter Dolding
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
