From: daw@cs.berkeley.edu (David Wagner)
To: linux-kernel@vger.kernel.org
Subject: Re: AppArmor FAQ
Date: Tue, 17 Apr 2007 23:53:22 +0000 (UTC) [thread overview]
Message-ID: <f03mli$8g8$1@taverner.cs.berkeley.edu> (raw)
In-Reply-To: 1176852059.5946.128.camel@localhost.localdomain
Karl MacMillan wrote:
>My private ssh keys need to be protected regardless
>of the file name - it is the "bag of bits" that make it important not
>the name.
I think you picked a bad example. That's a confidentiality policy.
AppArmor can't make any guarantees about confidentiality. Neither can
SELinux. If you give a malicious app the power to read your private ssh
key, it's game over, dude. (Covert channels, wall banging, and all that.)
So don't do that.
>Similarly, you protect the integrity of the applications that
>need name resolution by ensuring that the data that they read is high
>integrity. You do that by controlling data not the file name used to
>access the data. That is James point - a comprehensive mechanism like
>SELinux allows you to comprehensively protect the integrity of data.
I think this argument just misses the point. What you want isn't what
AppArmor does. Fine. Nobody is forcing you to use AppArmor. But that
doesn't mean AppArmor is useless. There may be people who want what
AppArmor has to provide.
It sounds like you want a comprehensive information flow control system.
That's not what AppArmor provides. If I understand correctly, one
thing AppArmor does provide is a way to confine untrusted legacy
apps in a restricted jail. That can be useful in some scenarios.
Consider, for instance, a web server where untrusted users can upload PHP
scripts, and you're concerned that those PHP scripts might be malicious.
Maybe you'd like to confine the PHP interpreter to limit what it can do.
That might be a good application for something like AppArmor. You don't
need comprehensive information flow control for that kind of use, and
it would likely just get in the way.
Those who want a information flow control system, will probably use
SELinux or something like it. Those who want what AppArmor has to offer,
might well use AppArmor. They solve different problems and have different
tradeoffs. There is room for more than one security tool in the world.
next prev parent reply other threads:[~2007-04-18 0:00 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
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 [this message]
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='f03mli$8g8$1@taverner.cs.berkeley.edu' \
--to=daw@cs.berkeley.edu \
--cc=daw-usenet@taverner.cs.berkeley.edu \
--cc=linux-kernel@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