l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Design principles


From: Jonathan S. Shapiro
Subject: Re: Design principles
Date: Mon, 15 Jan 2007 21:03:52 -0500

On Tue, 2007-01-16 at 02:11 +0100, Marcus Brinkmann wrote:
> At Mon, 15 Jan 2007 19:50:31 -0500,
> "Jonathan S. Shapiro" <address@hidden> wrote:
>
> > No. What I want to say is "this is the trivial security policy: it
> > imposes no restrictions".
> 
> Are you saying you can delete old revisions of wikipages in Wikipedia?
> Or deny other participants access to the full database?  Or deny other
> participants the ability to restore old revisions?

No. I am saying that these statements are a consequence of the
operations that implement Wikipedia. They are not a consequence of a
policy that is imposed that restricts these operations in a context
dependent way.

This is true in the same sense that the authority to zero a page named
by a read-write page capability is not a consequence of a security
policy. It is a consequence of the operational semantics of the
capability system implementation.

A security policy is something that is layered on top of the permissions
structure in such a way that different principals or subjects are
restricted in different ways.

Wikipedia's policy is a policy only in the most trivial sense. It is the
policy whose specification is "impose no further restrictions beyond
those that are intrinsic in the underlying permissions structure".

> > Availability is not generally considered part of security policy
> > specification. Perhaps it should be. Certainly it is an important issue.
> > But the literature on security policies is concerned with information
> > flow, not availability.
> 
> But if information is not available, it can't flow.  I have seen
> availability frequently mentioned in the context of security issues.

Yes. And as I said before, availability is indeed very important.

> I don't know about formal descriptions of "security policies", but
> it's certainly a part of the IT security canon, and my impression was
> not only in the sense of restricting access to them.

The term "availability" has two senses:

  Availability in the sense "the resource is available in principle,
  but some attack is making it impossible for you to get it." This
  is an information flow issue.

  Availability in the sense "it is good for the system to be up".
  This is a robustness issue.

In practice, the first sense ends up discussed in security discussions
under the headings of "denial of resource" and "denial of service". In
these discussions it usually becomes quickly apparent that these aren't
really security policy issues at all. They have more to do with
provisioning and architecture. At that point the *useful* discussion of
security policy reverts to information flow questions.

-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC
+1 443 927 1719 x5100





reply via email to

[Prev in Thread] Current Thread [Next in Thread]