Thursday, May 10, 2012

no justification why kernel must be modified to cache the tickets being used by a task

does not properly analyse UNIX file permission model and how it allows delegation of administration - no discussion of who and when can change owner and mode, s{u|g}id, sticky bit

interestingly there is actually no proposal for security containers in HelenOS

many types of tickets - it's not clear whether they are useful for anything and how one would choose among them

no real analysis/discussion of how the file permissions should be implemented and how it would (dis)allow common tasks such as sharing files, giving away files, (not) enforce users to follow some administrator-given rules for setting file permissions, etc.

it claims administration can be delegated thanks to the permissions on the individual RBAC virtual folders, but that's not true, these are too low-level and any useful permission given away will necessarily lead to privilege escalation (or at least no (counter)example is presented)

in the implementation, environment variables are introduced and used (without thought) for the sake of determining the default OGID for newly created files

some more thoughts/ideas:

not only that the almighty administrator cannot delegate his privileges, an ordinary user cannot delegate his privileges either (just like in UNIX) - no hierarchical principals

no way to enforce or even suggest permissions for files/directories under a subtree (cf. default ACLs)

single OGID for a file might be inflexible, especially if object groups can only be created/permissions set by the almighty administrator

In summary, the proposal:

might make it slishtly easier for an admin to assign permissions to a user

does not seem to allow any better delegation than the standard UNIX model

does not make proper analysis of what the model actually allows/ensures w.r.t operations on files and directories

introduces a new type of kernel resource with no obvious return value

makes it necessary to make a system call which queries the tickets (i.e. communicates with) a foreign task for any authorization operation, making it a communication-intesive operation (despite that IPC as such is not used)