[cap-talk] High level dissonance

James A. Donald jamesd at echeque.com
Sun Feb 24 01:11:40 EST 2008


Toby Murray wrote:
 >>  > If we cannot convey the inherent power of the C:
 >>  > authority (i.e. how dangerous it could be in the
 >>  > wrong hands) users will be doomed to grant it all
 >>  > too easily, thereby ensuring they remain no more
 >>  > secure than they are today.

James A. Donald:
 >> Rather, we need to protect users from the necessity
 >> to make such hard decisions

Toby Murray wrote:
 > I don't think we can do that, whilst allowing users to
 > innovate and experiment with their machine in
 > generative ways.

The only things that need plenipotentiary authority over
the C drive are FDISK, disk check, and system restore.

On my system, to run FDISK or system restore I always
have to boot up into a different operating system, and
to run disk check I usually boot up into a different
operating system.  So I never need my regular operating
system to grant anything plenipotentiary authority over
the C drive.

 > Users could have a POLA desktop and never need to make
 > a trust decision if the OS vendor has already done so
 > for them. However, they would never be able to run new
 > software, or better yet, write their own.

Sure they could - they could write and run their own
editor, or their own solitaire game, they could write
but not easily run their own FDISK.

Long, long ago, I did write my own fdisk equivalent -
and I would never have dreamed of running it under the
environment where I compiled it.  Rather, I created a
special disk, wrote it to that special disk, then booted
off that disk.

I envisage that anything installed as the system restore
utility automatically gets the necessary system restore
privileges from the package manager at install time -
but it is not even recognized as a system restore
utility unless signed as such by some key that the
package manager recognizes, and the kernel recognizes
the key that signs the package manger.

 >> - and when a user *does* need to make a hard
 >> decision, it should be "Do you trust so and so?", not
 >> "do you trust some incomprehensible something that
 >> you would never understand if we explained it a
 >> hundred times over, so we won't even bother
 >> explaining it."

Toby Murray wrote:
 > This would probably help, but I think it might be
 > missing something.

In my proposed method, if you want to modify your system
restore program you edit your public key into a kernel
source file called
"trusted_public_keys_for_package_manager.cpp, and
recompile the kernel, then reboot into the new kernel.

You then edit another of your public keys into a package
manager source file called
"trusted_public_keys_for_system_restore.cpp, recompile
the package manager, digitally sign it, and install it
using the existing package manager.

You can then edit the system restore program, recompile
it, sign it, and install it using the new package
manager, which automatically believes the assertion that
this is a valid system restore program, and on install
grants it the authority and privileges that a system
restore program needs.

And you never get told what authority and privileges a
system restore program needs, let alone asked to grant
them, and if you want to find out, you will need to
examine the package manager source code.


More information about the cap-talk mailing list