[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080815151855.4e9c2f09@lxorguk.ukuu.org.uk>
Date: Fri, 15 Aug 2008 15:18:55 +0100
From: Alan Cox <alan@...rguk.ukuu.org.uk>
To: rmeijer@...all.nl
Cc: 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
> 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.
SELinux is quite happy to apply different rules to content labelled in
different ways. WHat specific things do you need that it can't do ?
--
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/
Powered by blists - more mailing lists