[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20070609014644.9ed4fa29.seanlkml@sympatico.ca>
Date: Sat, 9 Jun 2007 01:46:44 -0400
From: Sean <seanlkml@...patico.ca>
To: david@...g.hm
Cc: Greg KH <greg@...ah.com>, Andreas Gruenbacher <agruen@...e.de>,
Stephen Smalley <sds@...ho.nsa.gov>,
Pavel Machek <pavel@....cz>, jjohansen@...e.de,
linux-kernel@...r.kernel.org,
linux-security-module@...r.kernel.org,
linux-fsdevel@...r.kernel.org
Subject: Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation,
pathname matching
On Fri, 8 Jun 2007 22:18:40 -0700 (PDT)
david@...g.hm wrote:
> the way I would describe the difference betwen AA and SELinux is:
>
> SELinux is like a default allow IPS system, you have to describe
> EVERYTHING to the system so that it knows what to allow and what to stop.
>
> AA is like a default deny firewall, you describe what you want to happen,
> and it blocks everything else without you even having to realize that it's
> there.
>
> now I know that this isn't a perfect analyogy, that SELinux doesn't allow
> something to happen unless it's been told to let it, but in terms of
> complexity and the amount of work to configure things I think the analogy
> is close.
It must be drop dead simple to modify SELinux to be default-deny. That
seems like it could be done in a small patch instead of requiring a huge
new infrastructure.
Let's assume that everyone agrees that AA is a good idea. Which parts of it
absolutely can't be implemented in terms of SELinux? SELinux isn't fixed in
stone, it can be altered if necessary to accommodate AA (as in the example
above of becoming default-deny).
Sean.
-
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