[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f5ml5r$29j$2@taverner.cs.berkeley.edu>
Date: Sun, 24 Jun 2007 20:45:47 +0000 (UTC)
From: daw@...berkeley.edu (David Wagner)
To: linux-kernel@...r.kernel.org
Subject: Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation,
pathname matching
Stephen Smalley wrote:
>That would certainly help, although one might quibble with the use of
>the word "confinement" at all wrt AppArmor (it has a long-established
>technical meaning that implies information flow control, and that goes
>beyond even complete mediation - it requires global and persistent
>protection of the data based on its properties, which requires stable
>and unambiguous identifiers).
1. Yes, that's the usage that has the greatest historical claim, but
"confinement" has also been used in the security community to refer to
limiting the overt side effects a process can have rather than controlling
information flow. The term "confinement" is arguably ambiguous, but I
think there is a semi-established meaning that doesn't imply information
flow control.
2. This is a can of worms we probably don't want to open. Keep in
mind that SELinux doesn't meet definition of confinement in Lampson's
original paper, either, because it only restricts overt information flows.
SELinux doesn't prevent covert channels, even though Lampson's original
paper included them as part of the confinement problem. Yet I don't
think it would be reasonable to criticize someone for describing SELinux
as a tool for "confinement". I don't know of any practical solution
that solves the confinement problem as Lampson envisioned it. I'd
recommend making decisions on the basis of whether the mechanisms are
useful, rather than whether they solve Lampson's notion of the
"confinement" problem.
-
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