From: Andi Kleen <andi@firstfloor.org>
To: Casey Schaufler <casey@schaufler-ca.com>
Cc: Andi Kleen <andi@firstfloor.org>,
James Morris <jmorris@namei.org>,
linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org,
linux-fsdevel@vger.kernel.org
Subject: Re: AppArmor FAQ
Date: Tue, 17 Apr 2007 23:16:53 +0200 [thread overview]
Message-ID: <20070417211653.GB11944@one.firstfloor.org> (raw)
In-Reply-To: <657751.18080.qm@web36614.mail.mud.yahoo.com>
> For SELinux to be effective it has to have a complete policy definition.
> This would prevent the OpenOffice access (unless OpenOffice is in the
> modify_resolv_conf_t domain) above.
This would mean no fully functional root user anymore. My understanding
is rather that at least in the Fedora default setup individual applications
are confined with targetted policy and root left alone because normal system
administrators get very unhappy when root becomes powerless.
I was merely pointing out that in this setup path or namespace based access
control are much easier to fit in than label based access because they normally
don't require changing applications. John's original document also
listed some other advantages that I don't need to repeat.
In "i don't care if it looks like Unix anymore" security setups like
you're describing that's undoubtedly different and labels might indeed
work because you forbid just anybody changing them easily. If that makes
the users happy is a different question though. I suppose it will
keep security consultants employed at least @)
Arguably the preserving label issue is not unique to SELinux but
also applies to ACLs and other possible uses of EAs, but then people normally
don't need to set any ACLs on /etc/resolv.conf.
I personally don't like either too much. Path based access control
is somewhat hackish and ugly and slow in the current implementation,
but I haven't seen an similarly easy to configure solution yet.
plan9 like limited namespaces for individual processes initially seem
like a nice alternative, but in practice they're also too hard to use and
suffer from many of the problems the EA label approach has.
But easy to use security is probably better than complicated security
because normal people will more likely use it.
-Andi
next prev parent reply other threads:[~2007-04-17 21:16 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-16 21:33 AppArmor FAQ John Johansen
2007-04-17 0:20 ` James Morris
2007-04-17 15:03 ` David Safford
2007-04-17 16:00 ` Karl MacMillan
2007-04-17 18:05 ` Andi Kleen
2007-04-17 17:47 ` James Morris
2007-04-17 18:10 ` Andi Kleen
2007-04-17 20:19 ` Casey Schaufler
2007-04-17 20:50 ` James Morris
2007-04-17 21:16 ` Andi Kleen [this message]
2007-04-17 21:41 ` Karl MacMillan
2007-04-17 21:51 ` David Wagner
2007-04-17 22:17 ` Alan Cox
2007-04-18 1:34 ` James Morris
2007-04-18 1:55 ` David Wagner
2007-04-18 2:20 ` James Morris
2007-04-18 2:31 ` David Wagner
2007-04-17 22:12 ` Andi Kleen
2007-04-17 22:29 ` Karl MacMillan
2007-04-17 21:58 ` Alan Cox
2007-04-18 13:45 ` James Morris
2007-04-18 14:33 ` Shaya Potter
2007-04-18 19:41 ` Crispin Cowan
2007-04-18 20:03 ` Shaya Potter
2007-04-18 21:14 ` James Morris
2007-04-19 16:35 ` David Wagner
2007-04-19 17:39 ` Stephen Smalley
2007-04-19 20:47 ` David Wagner
2007-04-24 0:58 ` Crispin Cowan
2007-04-24 2:03 ` Joshua Brindle
2007-04-25 1:03 ` Joshua Brindle
2007-04-19 17:14 ` Stephen Smalley
2007-04-19 20:08 ` David Wagner
2007-04-19 21:03 ` Stephen Smalley
2007-04-19 21:08 ` James Morris
2007-06-09 21:01 ` Pavel Machek
2007-06-09 21:28 ` david
2007-06-09 23:02 ` Pavel Machek
2007-06-10 0:06 ` david
2007-04-18 20:15 ` David Lang
2007-04-19 17:27 ` Stephen Smalley
2007-04-19 18:19 ` Bernd Eckenfels
2007-04-19 20:19 ` James Morris
2007-04-17 21:48 ` Karl MacMillan
2007-04-17 23:12 ` Casey Schaufler
2007-04-17 22:26 ` Karl MacMillan
2007-04-19 17:46 ` Stephen Smalley
2007-04-20 18:45 ` David Lang
2007-04-20 19:23 ` Karl MacMillan
2007-04-17 23:09 ` Crispin Cowan
2007-04-17 23:20 ` Karl MacMillan
2007-04-17 23:53 ` David Wagner
2007-04-18 1:56 ` James Morris
2007-04-18 2:08 ` David Wagner
2007-06-09 19:38 ` Pavel Machek
2007-04-19 17:56 ` Stephen Smalley
2007-04-19 20:54 ` David Wagner
2007-04-19 21:17 ` Stephen Smalley
2007-04-17 21:55 ` Karl MacMillan
2007-04-17 22:55 ` Crispin Cowan
2007-04-17 23:13 ` Karl MacMillan
2007-06-09 14:11 ` Pavel Machek
2007-04-18 7:21 ` Rob Meijer
2007-04-18 7:08 ` David Lang
2007-04-18 13:33 ` James Morris
2007-04-18 12:15 ` Joshua Brindle
2007-04-18 13:31 ` Casey Schaufler
2007-04-18 14:05 ` Rob Meijer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070417211653.GB11944@one.firstfloor.org \
--to=andi@firstfloor.org \
--cc=casey@schaufler-ca.com \
--cc=jmorris@namei.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox