Re: Code trust by reverse authentication

[Carl Fredrik Hammar]

Hi,

On Thu, Jul 16, 2009 at 05:23:11AM +0200, olafBuddenhagen@gmx.net wrote:
> As I already said on IRC, I do see some merit in the idea of reverse
> authentication, i.e. file objects authenticating against clients. It
> makes sense to consider files as active objects, which have access to
> certain user IDs. (The fact that a file system usually provides a whole
> bunch of individual objects, is just an implementation detail.)
> 
> The funny thing is that while there is no standard interface to expose
> the authority information, file systems nodes can indirectly prove they
> have access to certain user IDs, by starting a translator on the node.
> This is what your code blesser makes use of. It is rather hackish
> though, creating some practical problems -- if we ever mean to use
> reverse authentication seriously, we better provide a proper interface
> in the filesystems themselfs.
> 
> Anyways, while I see some merit in reverse authentication of files, I
> still don't think it is terribly useful for the migration framework.
> Having to explicitely bless every module is unrealistic; so in the
> standard case, we should just let the sender provide the authentication;
> and reserve explicit code blessing for the few cases where the sender
> can't, if at all.

Unrealistic?  Most likely the blessing would only require some changing
to a makefile's install rule.

Though in my experience mucking about with makefiles can easily turn
into a lot of work with little gain, so I'd rather postpone it as much
as possible.  So for this reason I will put the reverse authentication
in the sender for now.

The actual protocol will probably not need changing, except in name
only perhaps.  Now that I think about it the sender can probably forward
the request to a code blesser, I don't think it would even require any
additional RPCs than the original protocol.

I would say that it is inefficient to have so many separate translators,
but this could be alleviated using a translator that blesses all files
(or symlinks) under a directory.  This might even be more convenient,
just install the module under /hurd/modules and your set to go.

> In almost all cases, the sender itself is trusted. As I have said
> before, I don't think it's terribly likely that users really want to
> access servers run by other, untrusted users.  And the case that a user
> we don't trust runs a server which we want to access, but using modules
> we have blessed, *and* still really really needing migration, is even
> less likely -- I tend to consider it purely academical. Certainly not
> worth complicating the framework for it...

Well, ioctl handlers always require migration...

It is unlikely that another user uses a module blessed by one self.
However, it is likely that the user uses a module blessed by root,
especially if that user wants other users to be able to make use
of a service.

Also consider servers that drops authority for security reasons.
We could simply require that the server retain its authority is needed
to implement the server, but it seems like an unnecessary restriction.

Regards,
  Fredrik