>>> Its called SELinux and SELinux can already do this sort of stuff,
>>> including things like "only rpm may create files you are permitted to
>>> execute"
>>
>> 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.
>>
> They way I look at this. Most users complain that creating profiles
> for applications is too complex.
>
> Lets look for where a system that deals with the same kind of issue.
> Its in the firewall with ipset
http://ipset.netfilter.org/.
>
> You have a set of rules to do things assigned in the firewall. With
> secuirty this would be the LSM. User gets to choose from a predefined
> list for applications without profiles.
>
> Lets look at some basics here. Firefox and most internet applications
> don't need to edit everything in the user account. If some link
> could be designed into LSM for user to once off approve actions
> outside filesystem permissions from the grouping. Malware reading and
> writing stuff would be a lot harder.
>
> Major problem everyone keeps on missing. TALPA is only operating with
> part of the full information about the file. When file systems go
> from native file system to inodes currently the permissions on the
> native file system are translated to what linux supports and any that
> don't fit is disregarded. Due to that difference each file system
> has its own cache and holes on the file system where viruses could
> hide data for other OS's on the system. So TALPA might save Linux
> only to see another OS on the system infected. Worst case is if the
> other OS infected could come back and alter Linux disabling the virus
> scanner and reinfecting Linux.
