Thursday, May 17, 2012

On Limits

Past experience has shown that for any number N, and for almost any object O, the statement "we'll never need more than N of O" is invariably untrue.
Casper Dik

Thursday, May 10, 2012

Assessment of Stepan Henek's thesis Security containers and access rights in HelenOS

  • 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)
Back to the drawing board, I say!