Hi Jiří,
""
"I disagree with this interpretation. Capabilities in principle don't
mandate how
privileges are managed. I.e. even with capabilities, it's still
necessary to invent
a way to describe which task is supposed to have which capabilities. Fully
implicit system (privileges only being represented by code working with
capabilities) is a possibility, but it would risk devolving into a chaotic
mess
that's incomprehensible to a human user. "
OK. Obviously I'm not trying to conspire against my own brainchild ;-) It's
just that I want to be open-minded. Jakub suggested looking at an alternate
approach and since I haven't studied the capability-based approaches enough,
I don't want to judge, yet. I'd like to study the Genode book and then I can
think about this better.
Of course I would be delighted if anyone else proposed another solution
(capability based or not) or even provided some very specific explanation
why capabilities alone won't work.
"In this sense, H.P.S. used as a complementary mechanism for naming
privileges
on top of capabilities seems like a reasonable thing to try in my opinion. "
There are actually some interesting implications when you do something like
this. For example, let's say you did the privilege checking for talking to a
service in the location service. If a service A that can talk to service B
is subverted by an attacker X, the attacker cannot steal the privilege to
talk to B (because privileges cannot be given away even willingly to an
unrelated task). However X can force service A can to give away the *
connection* (capability) to B, thus 'circumventing' the security policy.
(Note: even if that wasn't possible, X can force A to forward arbitrary
messages to B, thus having an indirect channel).
" allow fs:/a/b/c/d
deny fs:/a/b/c
allow fs:/a/b
deny * "
Yes, I thought of something like that for display/user input. The tree was
just for internal representation.
""
Still, it is much more difficult to see what the task can do than with
simple privilege sets.
Thanks for your comments.
Cheers,
Jiri
_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/listinfo/helenos-devel
