[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: "user" and "network layer" security mechanisms.
> > 2) NFS. Most implementations of the NFS client operate with a fixed pool
> > of endpoints dedicated to the service. As a further complication, for
>
> NFS is inherently node-to-node as currently *implemented*, not
> user-to-server. You can not do user level security associations with currently
> implemented NFS. I suggest you look at AFS. I do not know enough about
> Sprite's file sharing to comment where it would stand.
> I wish NFS would go away, but I do not have a better solution yet. Further,
> NFS doesn't have be implemented the way it is: we *could* push a user-server
> SA down the through the vnode interface.
Actually, you don't need to change the vnode interface at all. All
the hair lives below the vnode layer, either in the transport layer
(which needs to carry around security associations in about the same
way that carries around IP addresses), in the filesystem itself, and
in the interfaces between the filesystem, the transport, and the IP
layer.
To nitpick (I have substantial familiarity with the innards of AFS and
DCE/DFS, and once had similar familiarity with NFS):
There's already a "credentials" structure pointer in the vnode
interface; traditionally, this contains just the effective, real, and
saved user-id and group-id set. AFS extends this to also include a
"pointer" of sorts to the user's cryptographic credentials.
This cred structure can be passed around within the kernel between
different kernel threads/processes; in fact, it has to be, because of
UNIX permission semantics... file descriptors are capabilities, and
the credentials you use for I/O are the ones which were effective at
the time open() was called, not the ones which are currently in effect
in the current process.
Under the vnode layer, this cred pointer can find its way to your
"RPC" layer, which can use it to pick the outgoing SA and thus the
outbound SPI to use for the request.
While SPI's are unidirectional, the key management protocols tend to
create them in pairs. A security association thus has *two* SPI's:
one inbound, and one outbound.
On the server end, the inbound SPI can be used to look up the "real"
credentials to use; those credentials are then passed to the vnode ops
on the server. The response to the client is sent using the outbound
SPI which is paired with the inbound SPI over which the request was
received.
If you're operating over TCP, this *probably* means that you need
separate connection for each user -- but doing this will be a
relatively simple change considering the magnitude of other changes
needed.
If you're operating over UDP, you can probably continue to use the
same endpoint for all users, but you need to make sure that the
inbound SPI's are carried along with each packet and checked by the
receiver.
- Bill
Follow-Ups:
References: