- 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!
"no justification why kernel must be modified to cache the tickets being used by a task"
ReplyDeleteThe caching was to optimize the permission verification process (see 6.2 chapter first paragraph).
"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"
ReplyDeleteI was advised not to go into further details of UNIX file permission model due to the overall text length.
"interestingly there is actually no proposal for security containers in HelenOS"
ReplyDeleteThe users, roles, etc. can be separated using frames. When the running task is not in the global frame it can use only the subset of the users, roles, etc. which are in the task's frame. (see 4.1.5 and 8.1 second point)
"many types of tickets - it's not clear whether they are useful for anything and how one would choose among them"
ReplyDeleteYou can set the validity period of each individual ticket. For example when you remove the permission from the RBAC the running task can have the permission for a while. Than the ticket shall be refreshed and permission revoked.
I agree that there are too many types of tickets. Perhaps eternal and timeout should be enough.
"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."
ReplyDeletePoint taken. The discussion is missing.
"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)"
ReplyDeleteEach virtual folder and each record of the virtual folder belong to the object group. Access to this object group is restricted via RBAC.
If a user want's to create a permission he needs to have a write access into the permission folder, read permission to object group folder and write permission for the object group record.
So if a user creates his own object group and of course has the write access the object group record). He can assign a permissions for this object group. If he doesn't have the write permission for the object group record he can't assign permission to the object group.
Of course if an 'admin' gives away privilege to object group 'manage_admin', he can be harshly punished. But that's not the flaw of the system.
"in the implementation, environment variables are introduced and used (without thought) for the sake of determining the default OGID for newly created files"
ReplyDeleteYes, but perhaps some bdsh modification would do the trick. But again these modifications and even the implementation of env variables wasn't the scope of my work.
"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"
ReplyDeleteYes, he can see the one of the previous comments.
"no way to enforce or even suggest permissions for files/directories under a subtree (cf. default ACLs)"
ReplyDeleteSound like an idea for an interesting feature. But where would you store such information? You would probably need to set it for each subtree of the file system, which is quite demanding...
"single OGID for a file might be inflexible, especially if object groups can only be created/permissions set by the almighty administrator"
ReplyDeleteSee the previous comment. Users can create object groups.
By adding and an extra object group to the file, you would create another access channel to the file and it is harder to monitor two channels than one.
Maybe it would've been more interesting to consider the AND approach. E.g. for accessing this file you need the read permission from GROUP1 and the read permission from GROUP2.
"might make it slishtly easier for an admin to assign permissions to a user"
ReplyDelete"does not seem to allow any better delegation than the standard UNIX model"
Yes it does. Imagine that you have two groups of users and you want to give rw permission for the first and r for the second.
You can't do it in standard UNIX model (without using extended file attributes which are limited).
In my model, you need to have two roles. Link the first with rw permission and the second with r permission and you're done.
"introduces a new type of kernel resource with no obvious return value"
ReplyDelete"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)"
The return value is security.
The tasks need to have a trusted reliable entity which can be used for interaction. So the communication with the kernel is necessary (but can be optimized).
Otherwise you would need to rely on some signing protocol. Which is IMHO not very good idea since the calculations would be more extensive. Moreover you'd need to solve the problems related to the exchange of the keys.
Anyways, thank you for your comments.
ReplyDeleteIt's a pity that you didn't make them earlier when there was still a time for some remedy. But now it seems that that ship has sailed a long ago.