[cap-talk] What are caps good for?

[David Hopwood]

Jed Donnelley wrote:
> At 08:09 PM 5/6/2004, Jonathan S. Shapiro wrote:
>> On Thu, 2004-05-06 at 21:07, Jed Donnelley wrote:
 >>
>> > >In actual practice, we don't get attacked by commercial software. It
>> > >isn't Windows or Word that is out to get you [I'll deal with 
>> > >penetration and scripts below in section 2].
>> >
>> > Hmmm.  I'm not sure I agee with the above.  Word's macros are
>> > notorious.  I am afraid to open any Word document that I receive
>> > with Word.  I generally use Wordpad.  I have a colleague that will
>> > only open Word documents in a VMWare virtual machine that
>> > does no have persistent state.
>>
>> Word != Word Virus. Word, the application, is not what attacks us. The
>> typical scripting virus is "unstaked" software supplied by a third
>> party. The failure in Word lies in incorrectly controlling the authority
>> of the scripting environment.
> 
> The point I was trying to make is that all our applications, even if
> we feel we can trust the vendor, need to have POLA applied to them.
> In this case you say Word's "failure" is in incorrectly controlling
> the authority of the scripting environment.  Are you suggesting that
> Word should do what the OS seems to be incapable of doing?

Word should make use of whatever mechanisms the OS provides to control
its transfer of authority to scripts. If Word allows harmful script
viruses, then it has indeed failed to correctly control the authority
of the scripting environment, even if that failure can in large part
be explained by the OS not providing adequate mechanisms.

[In the particular case of Word, it implements the scripting environment
effectively "from scratch", as an interpreter. Internet Explorer does not
implement its scripting environment from scratch; it uses an OS component
(Windows Scripting Host), but this component has many of the same security
design flaws that apply to Word. Where the OS boundary lies is far less
important than what security mechanisms are used.]

> With
> Word the scripting environment runs in the environment of the user
> just as Word does.  That's where the problem lies in my opinion.
> I think it entirely reasonable that Word would share it's appropriately
> limited access rights with scripts/macros that it is asked to run.

Even if the authority granted to Word is fastidiously limited according to
POLA, it's still necessary for Word to further limit the authority it grants
to scripts. For example, Word needs to maintain preferences that apply to
all documents edited by a user, but without explicit authorization, a macro
should only be able to affect its own document.

> There's a fundamental nut to the Trojan horse problem that is unsolvable.
> If you have to trust an agent with something, the agent can abuse that
> trust.  I believe the major security/integrity problem in computing
> (throughout the "ages") is the inability to limit such agents to POLA.
> I believe an appropriate application of the capability concept/model
> would solve this problem is so far as it can be solved, making a huge (!)
> improvement in the security/integrity of computing.

Imagining that there is a single boundary, between the user's shell and
applications, where POLA needs to be applied is a misconception. It is
commonplace for applications to need to enforce their own security
boundaries. Mechanisms like confinement are intended to support this.
There is an interesting argument to be had about *how well* confinement
supports building security boundaries at the user level, but it is clear
that it is necessary to be able to build such boundaries.

> I believe the discussion of "confinement" is nearly meaningless
> except as a distraction that's counter productive.  I believe providing
> mechanisms and interfaces to support Principle Of Least Access
> is where we should be focused.  In principle such POLA restrictions can
> be done with access lists.  However, I believe access lists are very
> awkward for this purpose.  They seem to appeal to people largely because
> of their ability to display who has access to a resource.  However, in this
> context people are thinking about which people have access to a resource.
> There is also the thought that access rights in an access list can be
> revoked at the list associated with the object.  This putative value is
> useless if the subjects are processes.  I'm going to look at the access
> list for my file and decide to revoke the right of process 5237 to the 
> file?

Agreed except for the first sentence. I don't believe that the first
sentence follows from any of the rest of this argument. On the contrary,
confinement is one of the "mechanisms and interfaces to support Principle
Of Least [Authority]".

> I believe there are other more suitable mechanisms, using the capability 
> model, that can be used for rights revocation.

The main usefulness of confinement is not revocation; it's delineating
security boundaries across which authority should not be granted in the
first place.

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>