Hi Jakub,
so you were saying you didn't like that H.P.S. added a new security control
mechanism and would prefer something 'capability based'.
I had a quick read through GENODE Operating System Framework 17.05 sections
3.1 and 3.2 as you suggested. However, I've had no epiphany. OK, it's a nice
description of a capability system. What it can do is quite similar to what
you can do in HelenOS with phones.
How do you propose the security mechanisms could work differently? Because I
don't quite see it. So if I wanted to, say prevent the clipboard server from
talking to the network, how would I define that policy and how would I
enforce it?
Best regards,
Jiri
---------- Původní e-mail ----------
Od: Jiří Zárevúcky <[email protected]>
Komu: HelenOS development mailing list <[email protected]>
Datum: 25. 9. 2017 18:28:38
Předmět: Re: [HelenOS-devel] Hierarchical Privilege System
">> 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).
>
The way I see it, named privileges could be used as an additional way
to grant a capability, without restricting the ability to pass
capabilities themselves.
I.e. the permissions as such would describe a subset of what can be
accessed, but just like raw capabilities, they couldn't describe what
should be inaccessible.
For an example of how that would be useful, imagine that a task has a
capability to talk to a service, but the service crashes and is
restarted. You want the client to be able to reconnect to the new
instance of the service, without user intervention if possible. If the
capability in question refers directly to the service task, then it is
now orphaned and useless. On the other hand, if the capability itself
refers to the service symbolically by name, then every call to the
service would have to go through the indirection reconnect to the
service task anew. The middle ground here is for the held capability
to directly address the server task, but also have the ability to
recover the connection by name in the case the capability becomes
invalid.
_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/listinfo/helenos-devel
"
_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/listinfo/helenos-devel
