On Wed, Aug 6, 2008 at 11:55 PM, Eric Paris <eparis@redhat.com> wrote:
quoted text
> On Wed, 2008-08-06 at 06:49 -0700, Arjan van de Ven wrote:
>> On Wed, 6 Aug 2008 09:11:14 -0400
>> > There was probably an implicit assumption on everyone's part,
>> > including Red Hat's, that what ought to be done was to replace the
>> > existing syscall-based event trapping with some other interface that
>> > more or less does the same thing in a cleaner way -- NOT to have all
>> > of the AV and other product vendors go out and completely rethink
>> > their models.  And that's not because we inherently object to
>> > rethinking.  It's really an issue of what kind of time frame we have
>> > before a new OS goes out that completely breaks our products.
>>
>> not writing to the syscall table hasn't been possible/allowed for..
>> about 5 years now. (yes I know there were still bad hacks possible
>> until 2 years ago). So I'm sorry, but the timeline argument doesn't
>> hold, you've had 5+ years of warning.
>>
>> All existing RHEL products already don't allow this (I know it for the
>> earlier ones since I was part of the design team)...  unless your
>> software acts entirely like a rootkit (but even then)
>
> Other options involved overwriting LSM function pointers.  I was told
> that recently moving SELinux to be statically compiled in apparently
> messed them up on that method, at least for RH products.  The other
> method I've heard is hunting down all of the filesystem_operations
> structs and overwriting those functions.  I was also told that until
> recently pages marked RO could just be marked RW and then remarked RO,
> although it was recently fixed to RO pages stayed RO.  So yeah, I'd have
> to call them all ugly rootkit like hacks.
>
> they just keep finding uglier and uglier ways to infiltrate the kernel
> which is why I was ask to try to help get a clean solution.
>
Simplely they are following the windows way of doing things.  Rootkit
the OS no one will stop us.  Sorry that RootKitting is not going to
work here long term because we will fix Root Kit weaknesses.  TPM from
IBM will make it even harder.  Nice bits of that are in 2.6.27.

Allowing LSM stacking solves nothing.   IBM's developers credentials
is a far better place for file system monitoring to hook in.  Its pre
caching allows all the alterations they could want.  Even better
credentials is a required patch to clean up Linux internal permission
splating all over the place.  Then generic filesystem caching sits on
top of that.   So 1 less cache needed.  Ie the cache of passes and
failures they keep so they don't slow the system down too much.

About time they wake up Linux Different OS.  We have zero tolerance of
root kits.   There is a section with the design to provide the file
system monitoring and the network monitoring both without being in LSM
space.  So why do they need LSM's.   Cannot they just use system LSM's
to protect there anti-virus like everyone else.   No need to treat
them special.   If they have a issue with a LSM not being good enough
they need to speak up.

They really need to provide what they want to do to us.   There issue
is they keep on looking in the wrong places and doing things the
windows way.   This is not WINDOWS.   In time mac and other OS's could
come tighter on root kits as well causing the programs to fail as
well.   Basically get use to working with a OS that does not tolerate
secuirty flaws.

Peter Dolding
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/