Cc: <rmeijer@...>, <capibara@...>, <david@...>, Eric Paris <eparis@...>, Theodore Tso <tytso@...>, Rik van Riel <riel@...>, <davecb@...>, <linux-security-module@...>, Adrian Bunk <bunk@...>, Mihai Don??u <mdontu@...>, <linux-kernel@...>, <malware-list@...>, Pavel Machek <pavel@...>, Arjan van de Ven <arjan@...>
This "permitted to execute" is what I feel is the wrong aproach with
respect to malware. If you simply allow everything to 'execute', I think
that untrusted programs may still be used for usefull things, but without
the potential do do malice. If you start from the point where everything
both trusted and untrusted is permitted to be executed, you could make it
the job of SELinux or any other LSM to make untrusted code run without
doing malice, but with the possibility to still run and do usefull non
malicious stuff. This might require some aditional hooks in LSM though I
could imagine.
To take this one step further, it might be usefull to see what kernel/LSM
changes would be needed to allow SELinux and/or possibly better yet,
AppArmor, to work with some powerbox style UI component in order to both
allow and force untrusted programs to run with least authority and still
do usefull stuff.
I feel the Polaris/Capdesk/Plash approach to untrusted code is much more
prommising than the "don't run" approach used by regular AV products.
Making such an approach integrate with LSM's would IMHO be a much more
fundamental approach to malware.
Rob
--
