linux-kernel - Re: [malware-list] [RFC 0/5] [TALPA] Intro to alinuxinterfaceforon access scanning

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 15 Aug 2008 14:22:17 +0200 (CEST)
From:	"Rob Meijer" <capibara@...all.nl>
To:	"Alan Cox" <alan@...rguk.ukuu.org.uk>
Cc:	rmeijer@...all.nl, capibara@...all.nl, david@...g.hm,
	"Eric Paris" <eparis@...hat.com>, "Theodore Tso" <tytso@....edu>,
	"Rik van Riel" <riel@...hat.com>, davecb@....com,
	linux-security-module@...r.kernel.org,
	"Adrian Bunk" <bunk@...nel.org>,
	"Mihai Don??u" <mdontu@...defender.com>,
	linux-kernel@...r.kernel.org, malware-list@...ts.printk.net,
	"Pavel Machek" <pavel@...e.cz>,
	"Arjan van de Ven" <arjan@...radead.org>
Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to	alinuxinterfaceforon 
          access scanning

On Fri, August 15, 2008 13:02, Alan Cox wrote:
>> The package manager approach is interesting in that it marks 'trusted',
>> and is thus permissive rather than restrictive. Maybe it would be
>> possible
>> to extend on this and simply define a set of currently unprivileged
>> access
>> as privileged for untrusted applications. That way you could allow
>> untrusted software to run without risk, even if that untrusted software
>> turns out to be malware. That is, it may be possible to solve the
>> malware
>> problem in a much more fundamental way here by just allowing malware to
>> run without the need to know if it is malware, just by running untrusted
>> software with reduced privileges.
>>
>
> 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.

Rob

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