[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <23C85F2D-9715-4C9B-BD4D-B7186A71F33D@mac.com>
Date: Sat, 9 Jun 2007 12:18:52 -0400
From: Kyle Moffett <mrmacman_g4@....com>
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 Jun 09, 2007, at 01:18:40, david@...g.hm wrote:
> 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.
WRONG. You clearly don't understand SELinux at all. Try booting in
enforcing mode with an empty policy file (well, not quite empty,
there are a few mandatory labels you have to create before it's a
valid policy file). /sbin/init will load the initial policy, attempt
to re-exec() itself... and promptly grind to a halt. End-of-story.
Typical "targetted" policies leave all user logins as unrestricted,
adding security for daemons but not getting in the way of users who
would otherwise turn SELinux off. On the other hand, a targeted
policy has a "trusted" type for user logins which is explicitly
allowed access to everything.
That said, if you actually want your system to *work* with any
default-deny policy then you have to describe EVERYTHING anyways.
How exactly do you expect AppArmor to "work" if you don't allow users
to run "/bin/passwd", for example.
Cheers,
Kyle Moffett
-
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