On 8/23/12, Jiří Zárevúcky <[email protected]> wrote: > On 23 August 2012 18:51, Matt Rice <[email protected]> wrote: >> On 8/23/12, Jiří Zárevúcky <[email protected]> wrote: >>> [...] >> >> hi, i'm not really involved in helenos at all, just my thoughts on the >> approach. >> > > Thanks, I appreciate it. > >> It's interesting in that you seem to have come to some of the same >> ideas found in capability systems (e.g. the lack of filesystem >> permissions, that having merely access to a file grants the permission >> to do something with it), > > Not surprising, it's a real-life metaphor. > >> but maintain the use of filenames which >> would seem to open the door to ambient authority[1] and the confused >> deputy problem[1] which capabilities were invented to fix. > > The filenames themselves are local to the namespace, and there are in > fact no global names for any file. I.e. communicating a filename to a > task running with different namespace (and by extension, different > permissions) is pointless, as it's relative to something the task > doesn't have access to at all. Doesn't that solve the problems you are > referring to?
not exactly, one thing still of concern is the opposite, e.g. accepting a local filename from a task running in a different namespace, couple this with giving a local filename to a task running in a different namespace and you have a directory server, but the directory server is not reflected in the security model. so looking at the namespaces themselves won't show that one task has access, but it does. the theory is that the filenames themselves are divisible from the file, and can be given without just giving the file itself via the model absent the mechanism that is also external to verify permissions. thus in the capability model, a capability is an atomic unit there is nothing to split the name from the capability, you just give them the file. names then are kept closely guarded e.g. the shell/user interaction deal has them, and it does the lookup, and passes files directly. the tasks themselves just work with e.g. file descriptors and don't need a namespace. >> Capability >> systems in general tend to do away with filesystems all together, as >> much discussed in many threads e.g. 'Explicit Persistence Considered >> Harmful'[3], but it would be good to consider how your VFS reacts to >> the confused deputy problem in particular when a program serves 2 >> masters. >> > > What exactly do you mean by "serving two masters"? i'll try and use the terms from your concept document and apply them to the confused deputy problem, but what I mean is lets say a user has a source/build namespace, and the compiler in addition to the source/build namespace has an extra billing namespace that the user does not have access to. thus the users permissions are only a subset of the compilers permissions, thus the concern here is of keeping the 2 sets of permissions separate instead of running the compiler with the union of permissions from both sets. so by 'serving two masters' I mean, running with multiple sets of permissions and avoiding mixing of them (in ways which was not intended.) hopefully this doesn't come off as evangelism, not really my intent I just wanted to point it out since the ideas appear to be somewhat related, nor am I any real authority on the subject _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
