Creeper: a tool for detecting permission creep in file system access controls | Cybersecurity | Full Text

[Raoul Duke]

band aid but maybe useful nevertheless 

https://cybersecurity.springeropen.com/articles/10.1186/s42400-019-0031-1

[Alan Karp]

That tool might be even more important in a capability system where delegations are both easy to do and easy to forget that you did.

--------------
Alan Karp

On Wed, Jul 19, 2023 at 5:55 PM Raoul Duke <rao...@gmail.com> wrote:

band aid but maybe useful nevertheless 

https://cybersecurity.springeropen.com/articles/10.1186/s42400-019-0031-1

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAJ7XQb6x873JWcGyUjgGpiAT8MQZRaJG-dPmntAtKi%3D_jj64cQ%40mail.gmail.com.

[Mark S. Miller]

Let's not forget though that the real issue is authority creep. Permissions creep does help analyze authority creep, but it is useful *only* to the extent that it does so. Is there any other reason to care about permissions creep?

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z2-zb_i%3DCHjtj4YOoO7f35RSfzP2r62J0s8A3PgjZ3Fog%40mail.gmail.com.

--

  Cheers,
  --MarkM

[Kevin Reid]

On Thu, Jul 20, 2023 at 4:30 PM Mark S. Miller <eri...@gmail.com> wrote:

Let's not forget though that the real issue is authority creep. Permissions creep does help analyze authority creep, but it is useful *only* to the extent that it does so. Is there any other reason to care about permissions creep?

 

Suppose that accessing some resource requires two permissions. 

For example, in a file system such as the paper discusses, to read a file you typically need permission to read the file and also permission to search each directory in the path to the file. Or, files on Unix file systems are often made inappropriately “world readable”, but the world has no such authority because it cannot execute processes on that machine. In a capability system, this type of situation involves rights amplification.

In such a case, it is possible for some party to have one of the two permissions in a case when it should have neither. A tool which detects such cases (with a sufficiently low false positive rate) can prevent breaches — that is, prevent the authority from coming into being, by indicating the need to revoke one of the permissions before it is ever used.

[Mark S. Miller]

Yes. In the terminology of https://research.google/pubs/pub45570/ and my thesis, this would be reasoning about eventual permission (EP) in order to reason about eventual authority (EA).

--

You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CANkSj9UYdaGnOZq2aPVcX4nsVDEPBjBDmEXnh_2k0h5At8dVdw%40mail.gmail.com.

--

  Cheers,
  --MarkM

[Matt Rice]

One thing I would like to see, rather than post-grant authority
analysis, is analysis of the proposed or projected worlds/bounds
before a capability is actually granted so as to avoid rather than
respond to excess authority...

> To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAK5yZYjTYH3zz6kqtz9%3DK2wEmzhVWTMHjCSWa4vn3Erph5sDkw%40mail.gmail.com.

[Alan Karp]

On Sat, Jul 22, 2023 at 7:00 AM Matt Rice <rat...@gmail.com> wrote:

One thing I would like to see, rather than post-grant authority
analysis, is analysis of the proposed or projected worlds/bounds
before a capability is actually granted so as to avoid rather than
respond to excess authority...

I took a different approach in Client Utility.  I was concerned that an admin might accidentally give a powerful capability to a guest, so I introduced negative capabilities.  A negative capability for an object in your c-list would prevent you from invoking that object even if you had a capability to the object in your c-list.  The nice part is that you can delegate without worrying if you might be violating some policy.  You still need a way to express who gets which negative capabilities, but I believe this approach provides a mechanism to support your requirement. 

--------------
Alan Karp

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CACTLOFoJ_1b_tx55wm4efxT7GV4Wb9fCzv%3D2%3DrsJCvfecDm4EA%40mail.gmail.com.

[Matt Rice]

On Sat, Jul 22, 2023 at 10:27 PM Alan Karp <alan...@gmail.com> wrote:
>
> On Sat, Jul 22, 2023 at 7:00 AM Matt Rice <rat...@gmail.com> wrote:
>>
>> One thing I would like to see, rather than post-grant authority
>> analysis, is analysis of the proposed or projected worlds/bounds
>> before a capability is actually granted so as to avoid rather than
>> respond to excess authority...
>
>
> I took a different approach in Client Utility. I was concerned that an admin might accidentally give a powerful capability to a guest, so I introduced negative capabilities. A negative capability for an object in your c-list would prevent you from invoking that object even if you had a capability to the object in your c-list. The nice part is that you can delegate without worrying if you might be violating some policy. You still need a way to express who gets which negative capabilities, but I believe this approach provides a mechanism to support your requirement.
>

It is an interesting mechanism, I'm somewhat assuming that
capabilities can still be delegated to others who lack a negative
capability, this seems scary from a social engineering perspective,
but it also brings with it interesting useful interactions 'give this
capability to bob and he'll get you set up'... That said, there it
seems when negative capabilities negate interaction. Such as the
interaction between a confined/unforgeable space with a password
capability/guessable space if you have a negative capability on
invocation of password capabilities instead of the typical absence of
password capabilities within a topological confinement... Negative
capabilities do seem like curious tweak of the model.

One of the things discussed in the paper was "enabling logging
mechanisms that record when a user has been allocated permission.",
which is easily doable from a power box.
That is the basis which I was thinking of primarily because it also
reflects how permissions change over time, and viewing them as a
time-series data in retrospect. Neither the negative capabilties nor
how creeper works by building a model via enumerating permissions seem
to capture any point of reference naturally beyond the current one.

sorry for sort of straying off topic....

> To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z18HL3tKr9f96FgU%2Ba7LtMZNv1HssFLaA%2BSpg-p%3DFQTtA%40mail.gmail.com.