Yes, that is basically what I was saying.
And you got me there - I do. I just get nervous when they are 1000
miles away and hacking indiscriminately. Those two are pretty creative
so I like to make sure we're on track. I'm sure this lively discussion
is just that - a sign of a good thing! :)
Rob Ross wrote:
Hi Walt,
Thanks for the explanation. So to make sure I understand how one would
differentiate between servers and clients (if that is importatn),
basically servers would never hand out a capability allowing someone to
perform an operation we didn't want clients to perform (e.g., a batch
create, if that's the solution chosen). Then only servers could perform
the operation, because they can create a capability for themselves that
allows them to do the operation (because they are trusted). Right?
I thought you liked it when the students ran off and started hacking on
their own :)? Or did you get tired of that after a while :)?
Rob
On Jun 25, 2009, at 12:33 AM, Walter Ligon wrote:
The short version goes like this - every request has a signed
capability included with it that states the request is authorized.
The capability is created by one of the servers, which we trust. We
don't need to know the source of any given message because we can
verify the source of the capability.
Now, as Rob surmised, the server that creates the capability normally
checks whatever permission is involved before creating it. In the
case of creating an object, this is generally inherent in the
permissions on the directory in which the final file (dir, symlink,
etc.) is going to be placed.
If the creation of files and such are moved to a server, then the
create-file request would normally include the handle of the parent
directory, on which permissions can be checked. The server-to-server
request to to create datafile objects and so on can be authorized by
the server doing the create. Normal users can be prevented from
running such a request by simply never giving them a capability for
that request.
I think the problem comes that where we used to have a request that
created one object, we now have a request that creates many objects,
and the current capability can limit which request you run, but not
the arguments to it, so a capability that allow you to create 1 allows
you to create many. If this request is only used server-to-server,
the we need not ever give a client a capability to use it, but if we
want to let a client run this request, we either have to risk a
malicious user chewing through handles, or we have to modify the
capabilities to be more flexible.
So one solution is to never allow clients to just create and object,
moving all creation routines to the servers. Another solution is to
have two requests a single create request and a bulk-create request
and only every allow clients to run the single. Still another is to
modify the create capability to specify how many objects can be created.
Oddly enough, the last might be the best approach - especially if we
find that this is the only case where we need to do that, and the only
options we need are 1 and many. In this case it becomes pretty easy.
Finally I might also point out that David and Nick did not consult
with me before deciding how to deal with this. I guess they figure
they don't need me any more.
Walt
Sam Lang wrote:
On Jun 24, 2009, at 3:55 PM, Sam Lang wrote:
It sounds like your approach to eliminating security holes is with
"security by obscurity". In other words, if the client (or some
rogue process acting as a client) does not know that the interface
is there, he can't abuse it. I don't think that's the right
approach, especially since PVFS is completely open source, and
anyone can just look at the code.
Rob points out that I don't really know about your security approach,
so my above comments may not be entirely appropriate. I guess what I
was trying to say is that it wasn't clear to me from a security
perspective that moving batch_create to the server would be helpful
for you. I'd be interested to hear about your security approach
though, and will refrain from making comments about it until I have a
better understanding of it. :-)
In a different context, Phil and I have discussed the issue of the
server knowing the source of a request. It turns out this isn't an
easy thing to do, at least for BMI tcp. Phil has added some code to
BMI tcp in a separate branch that provides the functionality
internally in BMI, and it shouldn't be hard to export the info
through a get_info call. Let us know if that's something you're
interested in!
-sam
_______________________________________________
Pvfs2-developers mailing list
Pvfs2-developers@beowulf-underground.org
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
_______________________________________________
Pvfs2-developers mailing list
Pvfs2-developers@beowulf-underground.org
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
_______________________________________________
Pvfs2-developers mailing list
Pvfs2-developers@beowulf-underground.org
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
