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

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!