[cap-talk] MinorFs & ssh secret keys

Rob Meijer capibara at xs4all.nl
Wed Jul 9 01:16:46 CDT 2008


On Wed, July 9, 2008 00:41, James A. Donald wrote:
> Rob Meijer wrote:
>> Possibly an example of MinorFs and 2rulethemall would be usefull in
>> order
>> for you all to understand the practical use and usage.
>
> This seems an example of the unix error and an example of the
> cryptographic tool error.
>
> You have the end users directly managing keys through a command line
> interface.  End users are never going to manage keys, let alone through
> a command line interface.

Hmm, the example shows use of ssh-keygen and management of the keys in a
way pretty similar to the way users normaly manage their ssh keys, so I am
a bit confused as to the scope of your comment here.

Or are you referring to the usage of the strong paths?

> The Unix error is to provide an incomprehensible command line interface
> that requires inordinate user effort to memorize and use.

At the risk of sparking off an OS flame, I strongly disagree with this
point. In my view Unix command line tools and the base philosophy of 'do
one thing, do one thing right' building block type of tools has been shown
to be the right approach over and over again over the last few decades.
Next to this, I feel that POLA lies in the extended path of this philosophy.
I feel that the mileage and interface consistency of many of the Unix
tools shows by itself the non existence of such a 'Unix error'.

Now to place it in the context of the only command line tool provided with
MinorFs. The tool '2rulethemall' has no commandline options, it is there
(in the unix tool philosofy) with one simple task, to protect a high
privilege password capability style strong path, and to delegate this
strong path to the user. If you know of a more friendly way to delegate
this path to
the user, I would be interested to learn. Giving a highly privileged
strong path to a GUI application IMO reduces flexibility, usability and
security, but I guess you will disagree on that. If you do, the high
privilege is currently given to the executable under the
/usr/local/bin/2rulethemall path, so replacing this executable with a GUI
version would be trivial.

> The cryptographic tool error is to provide a cryptographic tool to end
> users is that there is no demand for cryptographic tools by end users.
> People naively think that what they do is secure, and they want the
> existing tools that accomplish their purposes to magically have the
> security properties that they naively expect them to have.  Thus, for
> example, Skype encrypts all skype to skype communications without the
> user ever knowing or thinking about cryptography.

Are you talking about ssh and ssh-keygen? I am using these as example for
the reason that many people seem to be interested in the particular usage
of MinorFs, that is logging in to a server with ssh without providing any
passphrase, and without risking the confidentiality of the key.

I wrote (and am writing) MinorFs more with programmers in mind, and with a
stronger focus on delegation, that is as a tool to allow programmers to
write programs that through MinorFs can:

1) Keep their data safe from any other ptogram run by the user.
2) Delegate dir and file access to other processes, regardless of the uid
   that process is running under.

If I tell people about this, very few people seem to be interested, when I
tell them they could also use it to log in with ssh without providing a
password or pass phrase, this seems to spark much more interest.

Previously before the change in design sparked by Ivan's and Jed's
comments on the legitimate needs for the 'owner' (as in user that owns the
data) to administer its data, the ssh example would not have been possible
without changing the ssh program code to be MinorFs aware.

MinorFs now shields and proxies a directory tree with the following low
level structure:

   user/$UID/$PPEXEID/inst$INSTANCEID
                       /meta.xml

The path /mnt/minorfs/priv/home is a symbolic link to the strong path of a
private persistent directory of the pseudo persistent process accessing
the filesystem, this link will thus be different for each running instance
of each executable.

MinorFs gives the /usr/local/bin/2rulethemall binary a special high
privilege strong path that points to:

  user/$UID

/usr/local/bin/2rulethemall delegates this strong path to the user on
entry of a password provided by the user for this purpose.
The files: user/$UID/$PPEXEID/meta.xml holds all metadata relevant for
identifying the proper process. It midht be usefull to build a parsing
tool (or an other filesystem abstraction ?) that takes the user/$UID
strongpath and provides a more friendly representation of the information
in this file, with links to the strong paths of the relevant subpaths.

Rob











More information about the cap-talk mailing list