Rob Meijer wrote:
On Tue, April 17, 2007 23:55, Karl MacMillan wrote:
On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote:
On Mon, 16 Apr 2007, John Johansen wrote:
Label-based security (exemplified by SELinux, and its predecessors in
MLS systems) attaches security policy to the data. As the data flows
through the system, the label sticks to the data, and so security
policy with respect to this data stays intact. This is a good approach
for ensuring secrecy, the kind of problem that intelligence agencies
have.
Labels are also a good approach for ensuring integrity, which is one of
the most fundamental aspects of the security model implemented by
SELinux.
Some may infer otherwise from your document.
Not only that, the implication that secrecy is only useful to
intelligence agencies is pretty funny. Personally, I think that
protecting the confidentiality of my data is important (and my bank and
health care providers protecting the data they have about me). Type
Enforcement was specifically designed to be able to address integrity
_and_ confidentiality in a way acceptable to commercial organizations.
Karl
Shouldn't that be _OR_, as I have always understood confidentialy
models like BLP are by their very nature incompatible with integrity
models like Biba. Given this incompatibity, I think the idea that
BLP style use of lables (ss/* property and the likes) is only usefull
to intelligence agencies may well be correct, while usage for integrity
models like Biba and CW would be much broader than that.
Biba and BLP are only incompatible if they are using the same label, if
each object has a confidentiality and integrity label they work fine
together (as well as MLS systems work in general that is). Type
enforcement, however, lets you accomplish both integrity and
confidentiality (though not easily hierarchal confidentiality*). Take a
mail client for example, I could argue that my mail is confidential so I
label it my_mail_t and only give access to my mail client to read it and
the MTA to write it. Further I limit access of my mail client to objects
that can reduce its integrity such as untrusted files in /tmp, less
trusted user home directories and so on. Despite AA advocate claims that
info flow doesn't matter to integrity it does. I must be able to see
what can write to objects that my mail client can read if I want to make
any claims about its integrity.
* hierarchal confidentiality is obtained with an additional BLP label
that is evaluated as set of constraints over the type enforcement
permissions. SELinux is extensible in this way where AA is not.
A path based 'least priviledge' (POLP) solution would I think on its own
address neither integity nor confidentiality, and next to this would
proof to be yet an other 'fat profile' administration hell.
Having said that, I feel a path based solution could have great potential
if it could be used in conjunction with the object capability model, that
I would consider a simple and practical alternative integrity model that
does not require lables in an MLS maner, and that extends on the POLP
concept in a way that would be largely more practical.
This would be combining two bad systems to get a worse one IMO.
Capability systems are inherently discretionary since propagated
capabilities must be removed at the discretion of the possessor of the
capabilities.
The argument that labels are not practical has yet to be shown but is
thrown around as if it is fact. Path based systems are inferior to label
based systems based if for no other reason than path based systems can't
control transient objects. With policy based type transition in SELinux
when my ssh client writes my agent socket to /tmp/ssh-xxxxxxxxxx SELinux
calculates a type transition based off my domain to label it
sysadm_ssh_t (or whatever is appropriate) whereas path based systems
can't possibly control access to these objects. The same goes for any
files written to home directories by user apps.
That is, using 'thin' path based profiles would become very practical if
all further authority can be communicated using handles in the same way
that an open file handle can be communicated.
Once again, this creates a discretionary system that would not work
without modifying every single application that uses such authority (and
trusting the code is bug free so that it does the right thing) and gives
you an inflexible, decentralized, unmaintainable, unanalyzable policy
since it is distributed throughout code all over the system, you give
users no way to change the security characteristics of the system.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
