[cap-talk] Boebert's quote, Beobert attack on DVH, conspiring communicators
Eric Jacobs
eric at theeric.com
Thu Jul 20 17:23:00 EDT 2006
On Thu, 20 Jul 2006 12:41:21 -0700
Jed at Webstart <donnelley1 at webstart.com> wrote:
> In our initial conditions we have:
>
> 1. A capability RW_low_file stored in low_c-list, and
>
> 2. Our Trojan Horse with capabilities to R_low_c-list and R_high_file.
> (allowed by the MLS "oracle" - presumably any MLS policy)
>
> The Trojan Horse then simply:
>
> A. Fetches RW_low_file from it's R_low_c-list,
>
> B. Reads data from R_high_file, and
>
> C. Writes data to RW_low_file
>
> thereby violating the so-called star property (write down).
>
> Of course once the High Trojan Horse is able to get ahold of
> the RW_low_file capability (fetching it as it does from the
> R_low_c-list) the deed is done.
>
> There is nothing relating to capabilities as data in the above.
> As far as I understand this attack succeeds or fails exactly the
> same in capabilities as data and capabilities as descriptor systems.
I agree that the "capabilities-as-data" and "capabilities-as-bits"
metaphors are misleading here. All capabilities are representable as
binary data in form of bits (at least, to the extent that our discussion
is limited to digital computing systems.)
The key issue is not whether the capabilities are data but whether the
representation of those capabilities occurs in a local or global
namespace. If Alice's representation of a cap is specific to her
protection domain, and she wants to communicate it to Bob, then she must
necessarily rely on some supervisory entity that knows how to translate
it into Bob's local namespace. The cap cannot be hidden from the
supervisor, otherwise Bob will receive a meaningless piece of data.
Therefore, because the supervisor's involvement is mandatory, the
supervisor is in theory capable of implementing security policies
regarding the transfer of capabilities. A policy such as "a HIGH process
cannot receive a cap that was written by a LOW process" is meaningful
and enforcable.
If the representation of capabilities is global, however, it becomes
infeasible for any entity to supervise the exchange of capabilties
because the conspirators in this case can simply pass off the
caps as opaque data. This is where * and ss become unenforcable.
...
> However, the argument assumes that
> subjects can transmit capabilities anywhere they can
> transmit data, which is not the case in most capability
> systems.
> ________________________________________________________
>
> As I argue above it does not. It merely assumes that
> the rules for reading and writing capabilities follows
> along the lines of the rules for reading and writing data.
The critical point then, is the degree to which those rules can be
modified, and hence make that assumption invalid. The answer to that
depends on whether the caps are represented globally or locally.
-Eric
More information about the cap-talk
mailing list