Google's Fuscia OS, a "Capability based OS", Begins Rolling Out Today
98 views
Skip to first unread message
Dan Finlay
May 25, 2021, 12:21:28 PM5/25/21
to cap-talk
Today Google began rolling its new OS "Fuscia" out to first-gen Google Nest devices.
Fuscia is built on their "Zircon Kernel", which is based on "Little Kernel" by Travis Geiselbrecht.
The OS is going to be rolling out slowly on Nest devices for now, but is claimed to be built to run on basically anything, from laptops to traffic lights.
Seems pretty relevant to this group that a new capability-based OS might be coming out. Is anyone here familiar with it? Is this a true "object-capability" operating system? Will it have any notion of remotable objects? Lots of questions, I'll be reading up on it a bit today.
- Dan Finlay
Dan Finlay
May 25, 2021, 12:34:53 PM5/25/21
to cap-talk
Here is the Fuchsia page on their security principles. It manages authority by passing unforgeable objects as authority, not names, so it is passing my initial confused-deputy-resilience smell tests: https://fuchsia.dev/fuchsia-src/concepts/principles/secure
Christopher Lemmer Webber
May 25, 2021, 3:43:46 PM5/25/21
to cap-...@googlegroups.com, Dan Finlay
It definitely *sounds* like they're doing many things right.
I'm very interested in looking at it, even trying it if it's possible.
Time of course is a constraint, but...
Looks like the right place to start is here:
https://fuchsia.dev/fuchsia-src/get-started
Has anyone tried it yet? What do you think?
Dan Finlay writes:
> Here is the Fuchsia page on their security principles. It manages authority
> by passing unforgeable objects as authority, not names, so it is passing my
> initial confused-deputy-resilience smell tests:
> https://fuchsia.dev/fuchsia-src/concepts/principles/secure
>
> On Tuesday, May 25, 2021 at 9:21:28 AM UTC-7 Dan Finlay wrote:
>
>>
>> Today Google began rolling its new OS "Fuscia" out
>> <https://www.theverge.com/2021/5/25/22452620/google-fuchsia-os-nest-hub-smart-display-update-operating-system-linux-kernal>
>> "Little Kernel" by Travis Geiselbrecht <https://tkgeisel.com/>.
I'm very interested in looking at it, even trying it if it's possible.
Time of course is a constraint, but...
Looks like the right place to start is here:
https://fuchsia.dev/fuchsia-src/get-started
Has anyone tried it yet? What do you think?
Dan Finlay writes:
> Here is the Fuchsia page on their security principles. It manages authority
> by passing unforgeable objects as authority, not names, so it is passing my
> initial confused-deputy-resilience smell tests:
> https://fuchsia.dev/fuchsia-src/concepts/principles/secure
>
> On Tuesday, May 25, 2021 at 9:21:28 AM UTC-7 Dan Finlay wrote:
>
>>
>> Today Google began rolling its new OS "Fuscia" out
>> to first-gen Google Nest devices.
>>
>> Fuscia is built on their "Zircon Kernel
>> <https://en.wikipedia.org/wiki/Google_Fuchsia#Kernel>", which is based on
>>
>> Fuscia is built on their "Zircon Kernel
>> "Little Kernel" by Travis Geiselbrecht <https://tkgeisel.com/>.
Dan Connolly
May 25, 2021, 4:56:25 PM5/25/21
to cap-...@googlegroups.com
On Tue, May 25, 2021 at 2:43 PM Christopher Lemmer Webber <cwe...@dustycloud.org> wrote:
Has anyone tried it yet? What do you think?
haven't managed to try it yet, but...
Dan Finlay writes:
> Here is the Fuchsia page on their security principles. It manages authority
> by passing unforgeable objects as authority, not names, so it is passing my
> initial confused-deputy-resilience smell tests:
> https://fuchsia.dev/fuchsia-src/concepts/principles/secure
For that reason, I've been tracking it in https://github.com/dckc/awesome-ocap#os since the 2020-06-09 release.
Dan Connolly
John Kemp
May 25, 2021, 5:50:32 PM5/25/21
to cap-...@googlegroups.com
"The integer that represents a handle is only meaningful for that
process. The same number in another process might not map to any
handle or it might map to a handle pointing to a completely
different kernel object.”
- johnk
--
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/CAD2Yiva-CRvFB8EAE1xqFO2s%3D904QQK5_TpWK9HN4wtfnW7W9A%40mail.gmail.com.
Raoul Duke
May 25, 2021, 6:16:15 PM5/25/21
to cap-...@googlegroups.com
> "The integer that represents a handle is only meaningful for that process. The same number in another process might not map to any handle or it might map to a handle pointing to a completely different kernel object.”
?? soooo... generate & test, then?
John Kemp
May 25, 2021, 6:19:24 PM5/25/21
to cap-...@googlegroups.com
> On May 25, 2021, at 6:16 PM, Raoul Duke <rao...@gmail.com> wrote:
>
>> "The integer that represents a handle is only meaningful for that process. The same number in another process might not map to any handle or it might map to a handle pointing to a completely different kernel object.”
>
> ?? soooo... generate & test, then?
Denial of Operating System you mean?
>
>> "The integer that represents a handle is only meaningful for that process. The same number in another process might not map to any handle or it might map to a handle pointing to a completely different kernel object.”
>
> ?? soooo... generate & test, then?
- johnk
>
> --
> 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.
Mark S. Miller
May 25, 2021, 7:33:23 PM5/25/21
to cap-talk
I'm sure I'm missing context. But without that context, the quoted text
The integer that represents a handle is only meaningful for that process. The same number in another process might not map to any handle or it might map to a handle pointing to a completely different kernel object.
sounds like a normal c-list index which is exactly what we want for a secure OS. The secure OSes we respect (KeyKOS...EROS...Coyotos...seL4) all used clist indexes matching this description.
The key thing is that a process can only name capabilities it legitimately holds. No others should be in its clist. There is no generate & test or guessability issue involved. Is that the case here?
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/85AFD469-005F-4B27-9DDB-45BA7879ED17%40gmail.com.
Cheers,
--MarkM
--MarkM
William ML Leslie
May 25, 2021, 7:44:30 PM5/25/21
to cap-talk
Notably, Venkatesh Srinivas of Coyotos fame is a regular Fuchsia contributor.
Finally, some real security for IoT devices!
John Kemp
May 25, 2021, 7:52:21 PM5/25/21
to cap-...@googlegroups.com
> On May 25, 2021, at 7:33 PM, Mark S. Miller <eri...@gmail.com> wrote:
>
> I'm sure I'm missing context. But without that context, the quoted text
>
> The integer that represents a handle is only meaningful for that process. The same number in another process might not map to any handle or it might map to a handle pointing to a completely different kernel object.
>
> sounds like a normal c-list index which is exactly what we want for a secure OS. The secure OSes we respect (KeyKOS...EROS...Coyotos...seL4) all used clist indexes matching this description.
>
> The key thing is that a process can only name capabilities it legitimately holds. No others should be in its clist. There is no generate & test or guessability issue involved. Is that the case here?
The documentation is sparse, but AFAICT, a handle is a 32-bit integer. If one makes a syscall, a handle may be passed in. One result of a syscall might be ZX_ERR_BAD_HANDLE, presumably because the calling process does not in fact have the rights to use that handle, or has guessed a handle that does not exist at all.
>
> I'm sure I'm missing context. But without that context, the quoted text
>
> The integer that represents a handle is only meaningful for that process. The same number in another process might not map to any handle or it might map to a handle pointing to a completely different kernel object.
>
> sounds like a normal c-list index which is exactly what we want for a secure OS. The secure OSes we respect (KeyKOS...EROS...Coyotos...seL4) all used clist indexes matching this description.
>
> The key thing is that a process can only name capabilities it legitimately holds. No others should be in its clist. There is no generate & test or guessability issue involved. Is that the case here?
I’m sure the process is prevented from using a handle to which it has no rights.
But what is to stop a process from guessing and passing 32-bit integers into syscalls (unless there is some kind of additional security mechanism like rate limiting?)
- johnk
>
>
>
> On Tue, May 25, 2021 at 3:19 PM John Kemp <stable.p...@gmail.com> wrote:
> > On May 25, 2021, at 6:16 PM, Raoul Duke <rao...@gmail.com> wrote:
> >
> >> "The integer that represents a handle is only meaningful for that process. The same number in another process might not map to any handle or it might map to a handle pointing to a completely different kernel object.”
> >
> > ?? soooo... generate & test, then?
>
> Denial of Operating System you mean?
>
> - johnk
>
> >
> > --
> > 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/CAJ7XQb5acsmLUNd_%2Bw9g_BN1HL_cmz1%3DFSQufDD96sQz5MXH9w%40mail.gmail.com.
>
> --
> 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/85AFD469-005F-4B27-9DDB-45BA7879ED17%40gmail.com.
>
>
> --
> Cheers,
> --MarkM
>
> --
> 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.
Raoul Duke
May 25, 2021, 7:54:39 PM5/25/21
to cap-...@googlegroups.com
> Finally, some real security for IoT devices!
except perhaps for all the side channel timing attacks?
William ML Leslie
May 25, 2021, 8:18:06 PM5/25/21
to cap-talk
On Wed, 26 May 2021, 9:54 am Raoul Duke, <rao...@gmail.com> wrote:
> Finally, some real security for IoT devices!except perhaps for all the side channel timing attacks?
There are people for whom exfiltration is the problem they are trying to defend against. I just want to be able to run a program knowing I'll still be able to use my computer afterwards.
William ML Leslie
May 25, 2021, 8:36:20 PM5/25/21
to cap-talk
On Wed, 26 May 2021, 9:52 am John Kemp, <stable.p...@gmail.com> wrote:
> The key thing is that a process can only name capabilities it legitimately holds. No others should be in its clist. There is no generate & test or guessability issue involved. Is that the case here?
The documentation is sparse, but AFAICT, a handle is a 32-bit integer. If one makes a syscall, a handle may be passed in. One result of a syscall might be ZX_ERR_BAD_HANDLE, presumably because the calling process does not in fact have the rights to use that handle, or has guessed a handle that does not exist at all.
I’m sure the process is prevented from using a handle to which it has no rights.
But what is to stop a process from guessing and passing 32-bit integers into syscalls (unless there is some kind of additional security mechanism like rate limiting?)
"What's to stop a process using capabilities it holds?"
Mark S. Miller
May 25, 2021, 8:53:42 PM5/25/21
to cap-...@googlegroups.com
Thanks William.
Jack, William exactly captures what I don't understand about your question.
--
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/CAHgd1hEpoTqesNPckdxwtM_-vzoJ0SBFcM20i_zE4Qf08w2MWA%40mail.gmail.com.
William ML Leslie
May 25, 2021, 9:40:22 PM5/25/21
to cap-talk
There is one thing worth unpacking, I guess.
Normally, we freak out about Remote Code Execution. RCE against a
non-capability OS is effectively game over. Even on a multi-user
system like GNU/Linux, if you don't have a privelage escalation bug
handy, you could install a keylogger and LD_PRELOAD it into the
terminal and listen for `su -l root` or gksu or whatever the kids are
using these days and then emit the appropriate keystrokes. However, in
an object built with Object-Capabilities, this isn't so serious. If
the process only has access to the things it is supposed to have
access to, it can't create quite the same mess. You'd need to exploit
many other processes in the system to gain any useful authority.
This isn't to say that we should completely ignore memory-safety
issues on Capability systems, not at all. But it does mean that the
security of the system does not depend on every application you use
being written correctly.
We really are under a constant RCE, in some sense. I run many
applications that I don't really trust that much, made by people that
I don't think want to be trusted with some of the authority these
applications receive. Systems that are secure in the face of
misbehaving applications are possible and that is a laudable goal,
even if there are other improvements that can be made.
By the way, to get an idea of how capabilities as integers work (at
least in Coyotos), capabilities hold locations in your address space.
The addresses aren't mapped by the hardware page table, on systems
that have one, and so you can't examine their content, not even by
using Meltdown. However, you can pass these addresses to the kernel
and it will understand what they are. It's a crude way to have memory
safety for references and yet still support native executables.
Should a program protect its capabilities by using a memory safe
language? Yes, by all means. However, that's an additional step on
top of the security that the system itself provides.
The security world has focussed for so long on "mitigations", which
should really be the last 5%. These are really what to do when your
lines of defence have been broken. But the first step should be
building strong, flexible lines of defense in the first place, and
making that the substrate on which the system is built.
--
William Leslie
Q: What is your boss's password?
A: "Authentication", clearly
Notice:
Likely much of this email is, by the nature of copyright, covered
under copyright law. You absolutely MAY reproduce any part of it in
accordance with the copyright law of the nation you are reading this
in. Any attempt to DENY YOU THOSE RIGHTS would be illegal without
prior contractual agreement.
Normally, we freak out about Remote Code Execution. RCE against a
non-capability OS is effectively game over. Even on a multi-user
system like GNU/Linux, if you don't have a privelage escalation bug
handy, you could install a keylogger and LD_PRELOAD it into the
terminal and listen for `su -l root` or gksu or whatever the kids are
using these days and then emit the appropriate keystrokes. However, in
an object built with Object-Capabilities, this isn't so serious. If
the process only has access to the things it is supposed to have
access to, it can't create quite the same mess. You'd need to exploit
many other processes in the system to gain any useful authority.
This isn't to say that we should completely ignore memory-safety
issues on Capability systems, not at all. But it does mean that the
security of the system does not depend on every application you use
being written correctly.
We really are under a constant RCE, in some sense. I run many
applications that I don't really trust that much, made by people that
I don't think want to be trusted with some of the authority these
applications receive. Systems that are secure in the face of
misbehaving applications are possible and that is a laudable goal,
even if there are other improvements that can be made.
By the way, to get an idea of how capabilities as integers work (at
least in Coyotos), capabilities hold locations in your address space.
The addresses aren't mapped by the hardware page table, on systems
that have one, and so you can't examine their content, not even by
using Meltdown. However, you can pass these addresses to the kernel
and it will understand what they are. It's a crude way to have memory
safety for references and yet still support native executables.
Should a program protect its capabilities by using a memory safe
language? Yes, by all means. However, that's an additional step on
top of the security that the system itself provides.
The security world has focussed for so long on "mitigations", which
should really be the last 5%. These are really what to do when your
lines of defence have been broken. But the first step should be
building strong, flexible lines of defense in the first place, and
making that the substrate on which the system is built.
--
William Leslie
Q: What is your boss's password?
A: "Authentication", clearly
Notice:
Likely much of this email is, by the nature of copyright, covered
under copyright law. You absolutely MAY reproduce any part of it in
accordance with the copyright law of the nation you are reading this
in. Any attempt to DENY YOU THOSE RIGHTS would be illegal without
prior contractual agreement.
Mark S. Miller
May 25, 2021, 9:53:43 PM5/25/21
to cap-...@googlegroups.com
William, I love and agree with all the rest of your message. However, this one I don't get. *Given* the ability to measure duration, which is assumed for any Meltdown attack, why cannot the contents of kernel memory be read by Meltdown on these systems? Given the invariant obeyed by all the good ocap OSes, that integrity should never depend on confidentiality, there's not much to be gained by reading that memory. But I don't see anything that prevents it from being read by Meltdown-like side channels, without substantial additional mechanism that has not yet been explained.
However, you can pass these addresses to the kernel
and it will understand what they are. It's a crude way to have memory
safety for references and yet still support native executables.
Should a program protect its capabilities by using a memory safe
language? Yes, by all means. However, that's an additional step on
top of the security that the system itself provides.
The security world has focussed for so long on "mitigations", which
should really be the last 5%. These are really what to do when your
lines of defence have been broken. But the first step should be
building strong, flexible lines of defense in the first place, and
making that the substrate on which the system is built.
--
William Leslie
Q: What is your boss's password?
A: "Authentication", clearly
Notice:
Likely much of this email is, by the nature of copyright, covered
under copyright law. You absolutely MAY reproduce any part of it in
accordance with the copyright law of the nation you are reading this
in. Any attempt to DENY YOU THOSE RIGHTS would be illegal without
prior contractual agreement.
--
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/CAHgd1hEJBOpCcR6ES91jTc7GpFnivgA%3DSuyysBC%2BQQTVpis38Q%40mail.gmail.com.
William ML Leslie
May 25, 2021, 10:09:07 PM5/25/21
to cap-talk
On Wed, 26 May 2021 at 11:53, Mark S. Miller <ma...@agoric.com> wrote:
>
> On Tue, May 25, 2021 at 6:40 PM William ML Leslie <william.l...@gmail.com> wrote:
>>
>> By the way, to get an idea of how capabilities as integers work (at
>> least in Coyotos), capabilities hold locations in your address space.
>> The addresses aren't mapped by the hardware page table, on systems
>> that have one, and so you can't examine their content, not even by
>> using Meltdown.
>
>
> William, I love and agree with all the rest of your message. However, this one I don't get. *Given* the ability to measure duration, which is assumed for any Meltdown attack, why cannot the contents of kernel memory be read by Meltdown on these systems? Given the invariant obeyed by all the good ocap OSes, that integrity should never depend on confidentiality, there's not much to be gained by reading that memory. But I don't see anything that prevents it from being read by Meltdown-like side channels, without substantial additional mechanism that has not yet been explained.
>
Meltdown, at least in its original form, is a race between a virtual
>
> On Tue, May 25, 2021 at 6:40 PM William ML Leslie <william.l...@gmail.com> wrote:
>>
>> By the way, to get an idea of how capabilities as integers work (at
>> least in Coyotos), capabilities hold locations in your address space.
>> The addresses aren't mapped by the hardware page table, on systems
>> that have one, and so you can't examine their content, not even by
>> using Meltdown.
>
>
> William, I love and agree with all the rest of your message. However, this one I don't get. *Given* the ability to measure duration, which is assumed for any Meltdown attack, why cannot the contents of kernel memory be read by Meltdown on these systems? Given the invariant obeyed by all the good ocap OSes, that integrity should never depend on confidentiality, there's not much to be gained by reading that memory. But I don't see anything that prevents it from being read by Meltdown-like side channels, without substantial additional mechanism that has not yet been explained.
>
memory access to a mapped page and a test of the permissions of the
mapping. It can't read pages that haven't been mapped into the
virtual address space. The problem was that many operating systems
kept kernel pages (with no permission bits set) mapped high in the
address space of every process for performance reasons.
Mark S. Miller
May 25, 2021, 10:22:44 PM5/25/21
to cap-...@googlegroups.com
Ok then. How about Meltdown-like side channels? Or more to the point, micro-architectural side channels?
--
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/CAHgd1hEdC0CBWa0%2BVtr0sA%3DORChZnkqYseKohHGpV3TJMmZvgA%40mail.gmail.com.
William ML Leslie
May 25, 2021, 10:47:15 PM5/25/21
to cap-talk
On Wed, 26 May 2021 at 12:22, Mark S. Miller <ma...@agoric.com> wrote:
>
> Ok then. How about Meltdown-like side channels? Or more to the point, micro-architectural side channels?
>
If you want to be resistant to that sort of thing at an OS-level, seL4
>
> Ok then. How about Meltdown-like side channels? Or more to the point, micro-architectural side channels?
>
is still your only option, as far as I'm aware. They have made
amazing strides at eliminating any impact from hardware timing
channels. I think Shap had originally planned to be resilient to that
sort of thing in Coyotos, but I haven't looked that closely.
I'm in a bit of a no-mans land right now, with regard to that sort of
thing. If you wanted to be safe from those sort of hardware bugs in
the past, you just used Itanium. In the future, I guess that will be
RISC-V. Given that custom silicon is out of my reach and my last
Itanium machine has died, for the moment I'm all about making the most
of what I've got, which means I'm mostly ignoring hardware bugs to
focus on getting the software I need running on Coyotos in the cloud
and on mobile. I will likely have to port some of the Spectre
mitigations to Coyotos, though.
William ML Leslie
May 25, 2021, 10:50:59 PM5/25/21
to cap-talk
On Wed, 26 May 2021 at 22:47, William ML Leslie
<william.l...@gmail.com> wrote:
> but I haven't looked that closely.
>
Oh, and I guess the Fuchsia team are looking at that sort of thing
<william.l...@gmail.com> wrote:
> but I haven't looked that closely.
>
closely but haven't read anything specifically on it.
Bakul Shah
May 25, 2021, 11:00:18 PM5/25/21
to cap-talk
On May 26, 2021, at 5:47 AM, William ML Leslie <william.l...@gmail.com> wrote:
>
> I'm in a bit of a no-mans land right now, with regard to that sort of
> thing. If you wanted to be safe from those sort of hardware bugs in
> the past, you just used Itanium. In the future, I guess that will be
> RISC-V. Given that custom silicon is out of my reach and my last
> Itanium machine has died, for the moment I'm all about making the most
> of what I've got, which means I'm mostly ignoring hardware bugs to
> focus on getting the software I need running on Coyotos in the cloud
> and on mobile. I will likely have to port some of the Spectre
> mitigations to Coyotos, though.
I assume you have you looked at CHERI RISC-V ISA / ARM's Morello arch.
>
> I'm in a bit of a no-mans land right now, with regard to that sort of
> thing. If you wanted to be safe from those sort of hardware bugs in
> the past, you just used Itanium. In the future, I guess that will be
> RISC-V. Given that custom silicon is out of my reach and my last
> Itanium machine has died, for the moment I'm all about making the most
> of what I've got, which means I'm mostly ignoring hardware bugs to
> focus on getting the software I need running on Coyotos in the cloud
> and on mobile. I will likely have to port some of the Spectre
> mitigations to Coyotos, though.
How does that deal with this sort of problem?
-- Bakul
Bill Frantz
May 25, 2021, 11:04:14 PM5/25/21
to cap-...@googlegroups.com
On 5/26/21 at 7:40 AM, william.l...@gmail.com (William ML
Also, multiple layers of protection within applications. People
who don't understand this idea should study the structure of
Postfix. If I remember correctly, it is built with the
assumption that we, as programmers, can't write programs that
parse textual input without introducing security bugs. If those
programs don't have any meaningful authority, the resulting
system is much safer. It is a bit of PITA to structure a
collection of Unix processes to accomplish this kind of
protection, but it is possible.
Cheers - Bill
-----------------------------------------------------------------------
Bill Frantz | Can't fix stupid, but | Periwinkle
(408)348-7900 | duct tape can muffle the| 150 Rivermead
Road #235
www.pwpconsult.com | sound... - Bill Liebman | Peterborough, NY 03458
Leslie) wrote:
>The security world has focussed for so long on "mitigations", which
>should really be the last 5%. These are really what to do when your
>lines of defence have been broken. But the first step should be
>building strong, flexible lines of defense in the first place, and
>making that the substrate on which the system is built.
Agreed.
>The security world has focussed for so long on "mitigations", which
>should really be the last 5%. These are really what to do when your
>lines of defence have been broken. But the first step should be
>building strong, flexible lines of defense in the first place, and
>making that the substrate on which the system is built.
Also, multiple layers of protection within applications. People
who don't understand this idea should study the structure of
Postfix. If I remember correctly, it is built with the
assumption that we, as programmers, can't write programs that
parse textual input without introducing security bugs. If those
programs don't have any meaningful authority, the resulting
system is much safer. It is a bit of PITA to structure a
collection of Unix processes to accomplish this kind of
protection, but it is possible.
Cheers - Bill
-----------------------------------------------------------------------
Bill Frantz | Can't fix stupid, but | Periwinkle
(408)348-7900 | duct tape can muffle the| 150 Rivermead
Road #235
www.pwpconsult.com | sound... - Bill Liebman | Peterborough, NY 03458
Mark S. Miller
May 25, 2021, 11:14:27 PM5/25/21
to cap-...@googlegroups.com
Multiple layers indeed!
is a 15 minute talk on the multiplicative benefit of doing so simultaneously at every scale of composition.
The expanded 90 minute talk, for those sufficiently curious ;)
--
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/r480Ps-10146i-1A32498DBB0340209B02CFB448504787%40Williams-MacBook-Pro.local.
William ML Leslie
May 25, 2021, 11:18:01 PM5/25/21
to cap-talk
On Wed, 26 May 2021 at 13:00, Bakul Shah <ba...@iitbombay.org> wrote:
>
> On May 26, 2021, at 5:47 AM, William ML Leslie <william.l...@gmail.com> wrote:
> > If you wanted to be safe from those sort of hardware bugs
>
>
> On May 26, 2021, at 5:47 AM, William ML Leslie <william.l...@gmail.com> wrote:
> > If you wanted to be safe from those sort of hardware bugs
>
> I assume you have you looked at CHERI RISC-V ISA / ARM's Morello arch.
> How does that deal with this sort of problem?
>
With hardware timing channels leaking private information? It's not
> How does that deal with this sort of problem?
>
really an ISA thing but a microarchitectural thing. So you could have
CHERI implementations with those bugs, and CHERI implementations
without those bugs. Of course, just having a system that supports
capabilities natively is a huge improvement.
Some of the bugs we have (especially in Intel hardware) are deliberate
design decisions, and so it's easy enough not to make that same
mistake. Others are accidental. Thankfully, we are getting to the
point where we can have formally verified silicon (especially, where
we can verify no timing dependence on the state of other threads),
with bluespec system verilog now being free software. I'm no expert
in that space though.
Bakul Shah
May 25, 2021, 11:31:52 PM5/25/21
to cap-talk
On May 26, 2021, at 6:17 AM, William ML Leslie <william.l...@gmail.com> wrote:
>
> On Wed, 26 May 2021 at 13:00, Bakul Shah <ba...@iitbombay.org> wrote:
>>
>> On May 26, 2021, at 5:47 AM, William ML Leslie <william.l...@gmail.com> wrote:
>>> If you wanted to be safe from those sort of hardware bugs
>>
>> I assume you have you looked at CHERI RISC-V ISA / ARM's Morello arch.
>> How does that deal with this sort of problem?
>>
>
> With hardware timing channels leaking private information? It's not
> really an ISA thing but a microarchitectural thing. So you could have
> CHERI implementations with those bugs, and CHERI implementations
> without those bugs. Of course, just having a system that supports
> capabilities natively is a huge improvement.
I was thinking that you'd still need some constraints at the h/w or arch.
>
> On Wed, 26 May 2021 at 13:00, Bakul Shah <ba...@iitbombay.org> wrote:
>>
>> On May 26, 2021, at 5:47 AM, William ML Leslie <william.l...@gmail.com> wrote:
>>> If you wanted to be safe from those sort of hardware bugs
>>
>> I assume you have you looked at CHERI RISC-V ISA / ARM's Morello arch.
>> How does that deal with this sort of problem?
>>
>
> With hardware timing channels leaking private information? It's not
> really an ISA thing but a microarchitectural thing. So you could have
> CHERI implementations with those bugs, and CHERI implementations
> without those bugs. Of course, just having a system that supports
> capabilities natively is a huge improvement.
leve to prevent such leaky timing channels. For example, any process that
gets access to a real clock must run in a constrained way so as to not
leak information. Or some such.
-- Bakul
William ML Leslie
May 25, 2021, 11:47:38 PM5/25/21
to cap-talk
On Wed, 26 May 2021 at 13:31, Bakul Shah <ba...@iitbombay.org> wrote:
>
> I was thinking that you'd still need some constraints at the h/w or arch.
> leve to prevent such leaky timing channels. For example, any process that
> gets access to a real clock must run in a constrained way so as to not
> leak information. Or some such.
>
Like the intel profiling registers? I'm not too sure. On Mach, at
>
> I was thinking that you'd still need some constraints at the h/w or arch.
> leve to prevent such leaky timing channels. For example, any process that
> gets access to a real clock must run in a constrained way so as to not
> leak information. Or some such.
>
least, there was an endpoint you had to talk to in order to get access
to these, but maybe these are userspace-accessible now.
William ML Leslie
May 25, 2021, 11:51:14 PM5/25/21
to cap-talk
On Wed, 26 May 2021 at 23:47, William ML Leslie
<william.l...@gmail.com> wrote:
>
> On Wed, 26 May 2021 at 13:31, Bakul Shah <ba...@iitbombay.org> wrote:
> >
> > I was thinking that you'd still need some constraints at the h/w or arch.
> > leve to prevent such leaky timing channels. For example, any process that
> > gets access to a real clock must run in a constrained way so as to not
> > leak information. Or some such.
> >
>
> Like the intel profiling registers? I'm not too sure. On Mach, at
> least, there was an endpoint you had to talk to in order to get access
> to these, but maybe these are userspace-accessible now.
>
But yes, that's a good point, just like in virtualisation, having an
<william.l...@gmail.com> wrote:
>
> On Wed, 26 May 2021 at 13:31, Bakul Shah <ba...@iitbombay.org> wrote:
> >
> > I was thinking that you'd still need some constraints at the h/w or arch.
> > leve to prevent such leaky timing channels. For example, any process that
> > gets access to a real clock must run in a constrained way so as to not
> > leak information. Or some such.
> >
>
> Like the intel profiling registers? I'm not too sure. On Mach, at
> least, there was an endpoint you had to talk to in order to get access
> to these, but maybe these are userspace-accessible now.
>
ISA deliberately designed for encapsulation helps.
Alan Karp
May 25, 2021, 11:51:36 PM5/25/21
to cap-...@googlegroups.com
I asked Peter Neumann about that a year or more ago. At that time he said Cheri was vulnerable. I don't know if anything has changed.
--------------
Alan Karp
Venkatesh Srinivas
May 26, 2021, 11:14:25 AM5/26/21
to cap-talk
On Tuesday, May 25, 2021 at 8:47:38 PM UTC-7 william.l...@gmail.com wrote:
>On Wed, 26 May 2021 at 13:31, Bakul Shah <ba...@iitbombay.org> wrote:
>>
>> I was thinking that you'd still need some constraints at the h/w or arch.
>> leve to prevent such leaky timing channels. For example, any process that
>> gets access to a real clock must run in a constrained way so as to not
>> leak information. Or some such.
It is very difficult to prevent or even enumerate all such channels, at any level. >On Wed, 26 May 2021 at 13:31, Bakul Shah <ba...@iitbombay.org> wrote:
>>
>> I was thinking that you'd still need some constraints at the h/w or arch.
>> leve to prevent such leaky timing channels. For example, any process that
>> gets access to a real clock must run in a constrained way so as to not
>> leak information. Or some such.
> Like the intel profiling registers? I'm not too sure. On Mach, at
> least, there was an endpoint you had to talk to in order to get access
> to these, but maybe these are userspace-accessible now.
a supervisor configures this (CR4.PCE), via the RDPMC instruction.
Ditto for RDPRU (AMD only), which is keyed off of CR4.TSD. Many OSes
require rendezvous with an endpoint to access them, though that endpoint
may be kernel-implemented.
HTH,
-- vs;
Venkatesh Srinivas
May 26, 2021, 11:16:30 AM5/26/21
to cap-talk
On Tuesday, May 25, 2021 at 7:50:59 PM UTC-7 william.l...@gmail.com wrote:
>>On Wed, 26 May 2021 at 22:47, William ML Leslie
>> <william.l...@gmail.com> wrote:
>> but I haven't looked that closely.
>>
> Oh, and I guess the Fuchsia team are looking at that sort of thing
> closely but haven't read anything specifically on it.
At the minute, Fuchsia does not attempt to innovate in defending>>On Wed, 26 May 2021 at 22:47, William ML Leslie
>> <william.l...@gmail.com> wrote:
>> but I haven't looked that closely.
>>
> Oh, and I guess the Fuchsia team are looking at that sort of thing
> closely but haven't read anything specifically on it.
against speculative execution info-leaks. (This is a good thing!)
The implications of similar defaults may be different on systems
with a different environment, however.
Couple of very minor differences:
Couple of very minor differences:
- Different defaults for when IBPBs (scrub indirect branch predictors)
are issued vs. other operating systems. Fuchsia issues on every
address space switch by default (compare opt-in on Linux), except
to or from kernel threads.
- Against the "LVI" type of attack, we pre-mark all kernel PTEs as A/D; this, coupled with the lack of SIMD instructions and LFENCE brackets
around user accesses, protects the kernel 'for free'.
Couple of observations:
- A kernel's scheduler choices shape the impacts of mitigations.
This sounds obvious, but it's worth examining in some detail.
For example, Fuchsia's current scheduler policies tend to not
co-schedule threads where other OS schedulers do. This meant
fewer cross-context scrubs may be required and the perf.
impact of more frequent scrubs is teneble.
- MDS was a very painful class of attack to mitigate, particularly for
systems with frequent kernel calls.
HTH,
-- vs;
Bill Frantz
May 26, 2021, 1:10:02 PM5/26/21
to cap-...@googlegroups.com
On 5/25/21 at 9:53 PM, ma...@agoric.com (Mark S. Miller) wrote:
>... However, this
I'm not sure I agree that ocap OSes are safe if you can read the
kernel memory. A short thought experiment, using the 370 version
of KeyKOS as an example:
The KeyKOS kernel ran using real (unmapped) addresses, so lets
postulate a function which reads any part of real memory. With
this facility, the attacker could trace the capability links
between running domains. S/he could also read any page of a
running program that is mapped into real memory, including
encryption keys, passwords, and the codes for missle launch. Not good.
I'm not sure that running the kernel in mapped mode helps. It
depends on what you can read with your timing attack.
Cheers - Bill
----------------------------------------------------
Bill Frantz | Art is how we decorate space,
408-348-7900 | music is how we decorate time.
www.pwpconsult.com | -Jean-Michel Basquiat
>... However, this
>one I don't get. *Given* the ability to measure duration, which is assumed
>for any Meltdown attack, why cannot the contents of kernel memory be read
>by Meltdown on these systems? Given the invariant obeyed by all the good
>ocap OSes, that integrity should never depend on confidentiality, there's
>not much to be gained by reading that memory. ...
>for any Meltdown attack, why cannot the contents of kernel memory be read
>by Meltdown on these systems? Given the invariant obeyed by all the good
>ocap OSes, that integrity should never depend on confidentiality, there's
I'm not sure I agree that ocap OSes are safe if you can read the
kernel memory. A short thought experiment, using the 370 version
of KeyKOS as an example:
The KeyKOS kernel ran using real (unmapped) addresses, so lets
postulate a function which reads any part of real memory. With
this facility, the attacker could trace the capability links
between running domains. S/he could also read any page of a
running program that is mapped into real memory, including
encryption keys, passwords, and the codes for missle launch. Not good.
I'm not sure that running the kernel in mapped mode helps. It
depends on what you can read with your timing attack.
Cheers - Bill
----------------------------------------------------
Bill Frantz | Art is how we decorate space,
408-348-7900 | music is how we decorate time.
www.pwpconsult.com | -Jean-Michel Basquiat
Mark S. Miller
May 26, 2021, 1:51:12 PM5/26/21
to cap-...@googlegroups.com
I agree with Bill. I'll retreat towards tautologies that are nevertheless useful to point out:
Aside from crypto (broadly defined), we can generally build systems where integrity does not depend on confidentiality. Given that we build systems that way, a loss of confidentiality does not threaten those forms of integrity. The broad definition of "crypto" would then need to include "codes for missile launch".
The extreme example that shows this separation is meaningful: Computations on public blockchains like Ethereum cannot keep secrets. They nevertheless have strong integrity properties.
--
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/r480Ps-10146i-49B2C6D4F3AC4D1D9916D32B6FE167C7%40Williams-MacBook-Pro.local.
Matt Rice
May 30, 2021, 12:13:39 PM5/30/21
to cap-talk
I haven't tried it yet, but i'm a bit apprehensive towards it, somewhat by the number of system calls https://fuchsia.dev/fuchsia-src/reference/syscalls,
but mostly by the idea of a per-process filesystem/namespace. https://fuchsia.dev/fuchsia-src/concepts/process/namespaces
They at least did 2 things right with the namespaces by not implicitly inheriting between parent and child processes and the obvious lack of a global filesystem...
Now if I could take the opportunity to paraphrase Christopher to Christopher,
At some point there was a discussion on how to introduce a confused deputy problem within a capability system.
which is something like a 2 step process, throw a bunch of capabilities into a bucket of some sort, and delegate access to that bucket with multiple people of diverging security context.
The typical response is that this is somewhat unnatural in a capability system, you have to introduce both buckets, and a mechanism for delegating them, which works in a different way than every other process shares
on top of a perfectly good mechanism for sharing. Thus you have to go out of your way, and jump through some hoops in order to introduce confused deputy problems.
Typically when I look towards a capability OS I imagine something where we can keep filesystems and directory objects closely guarded to the shell, giving directory objects to non-shell processes should be the outlier rather than the
modus operandi... Anyhow it feels to me like they are 1/2 way to a confused deputy such that all you need to add is delegation of the namespace, because they've normalized "putting capabilities into buckets", ...
It seems delegation is not the expected mechanism to use but namespace transfer instead...
uncertain on a couple of points like if it's possible to have multiple namespaces for a process, or if it is limited to a single namespace...
Anyhow it seems like it is certainly possible to write programs with no confused deputy problems on it, which is something,
but it seems to me an awfully thin margins in that you might not have to stray too far off the rails from the typical behavior while still being able to introduce one...
That said I haven't used it, or programmed for it, these are just the initial impressions I get from looking at the documentation...
On Tue, May 25, 2021 at 7:43 PM Christopher Lemmer Webber <cwe...@dustycloud.org> wrote:
It definitely *sounds* like they're doing many things right.
I'm very interested in looking at it, even trying it if it's possible.
Time of course is a constraint, but...
Looks like the right place to start is here:
https://fuchsia.dev/fuchsia-src/get-started
Has anyone tried it yet? What do you think?
Dan Finlay writes:
> Here is the Fuchsia page on their security principles. It manages authority
> by passing unforgeable objects as authority, not names, so it is passing my
> initial confused-deputy-resilience smell tests:
> https://fuchsia.dev/fuchsia-src/concepts/principles/secure
>
> On Tuesday, May 25, 2021 at 9:21:28 AM UTC-7 Dan Finlay wrote:
>
>>
>> Today Google began rolling its new OS "Fuscia" out
>> to first-gen Google Nest devices.
>>
>> Fuscia is built on their "Zircon Kernel
>> <https://en.wikipedia.org/wiki/Google_Fuchsia#Kernel>", which is based on
>> "Little Kernel" by Travis Geiselbrecht <https://tkgeisel.com/>.
>>
>> The OS is going to be rolling out slowly on Nest devices for now, but is
>> claimed to be built to run on basically anything, from laptops to traffic
>> lights.
>>
>> Seems pretty relevant to this group that a new capability-based OS might
>> be coming out. Is anyone here familiar with it? Is this a true
>> "object-capability" operating system? Will it have any notion of remotable
>> objects? Lots of questions, I'll be reading up on it a bit today.
>>
>> - Dan Finlay
>>
--
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/871r9uzjim.fsf%40dustycloud.org.
Alan Karp
May 31, 2021, 12:27:56 AM5/31/21
to cap-...@googlegroups.com
On Sun, May 30, 2021 at 9:13 AM Matt Rice <rat...@gmail.com> wrote:
At some point there was a discussion on how to introduce a confused deputy problem within a capability system.
The capability confused deputy involved sealed boxes. You avoid it by choosing a specific unsealer and not looking for any unsealer that happened to match.
--------------
Alan Karp
Alan Karp
Matt Rice
May 31, 2021, 1:59:29 AM5/31/21
to cap-talk
Sure, but I think it could be argued that sealers/unsealers are just an opaque form of indexing although that may be obscured by some implementation details of some kinds sealer/unsealer implementations,
And I can't recall a capability OS which used them, as they typically have some other mechanism available...
any unsealer is also bad for other reasons, an unsealer may manipulate the data, multiple unsealers may unseal the same sealed box to different values, may even unseal to something random even though it cannot know what is in the box,
in which case which one is the right one, but that is kind of beside the point on a tangent...
Carl Hewitt Twitter: ProfCarlHewitt
May 31, 2021, 9:32:40 AM5/31/21
to cap-talk
Since an Actor can protect itself,
why is the Sealer/Unsealer construct needed?
Regards,
Mark S. Miller
May 31, 2021, 11:51:54 AM5/31/21
to cap-...@googlegroups.com
Do the MintMaker without it
On Sun, May 30, 2021 at 10:59 PM Matt Rice <rat...@gmail.com> wrote:
--
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/CACTLOFoPYMbqkP3wotbAcrZAZhoSnJnwuChJF2MPmHuPYX0BxQ%40mail.gmail.com.
Cheers,
--MarkM
--MarkM
Mark S. Miller
May 31, 2021, 11:52:26 AM5/31/21
to cap-...@googlegroups.com
Do the MintMaker without it
--
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/CA%2BymXc3%2BAjPFOce3CSZBv_Gh-Oqkb_rYixt-68P8dxV5T%3Dxvsw%40mail.gmail.com.
Cheers,
--MarkM
--MarkM
Christopher Lemmer Webber
May 31, 2021, 12:00:54 PM5/31/21
to cap-...@googlegroups.com, Carl Hewitt Twitter: ProfCarlHewitt
Hey Carl, you're right that actors have the ability to protect
themselves... the problem comes in when we want to introduce
~"asymmetric authority" to a shared and known actor (for behavior or
information storage).
Sealers/unsealers are appropriate any time you want either information
or additional capabilities attached to something that may be seen by
many but only used by a few. It's not unlike encryption in that way,
but sealers/unsealers can be constructed in terms of object references.
There are three uses of sealers/unsealers:
- To obscure information (encryption-like)
- To obscure more authority (rights amplification)
- As authentication: I might have a sealer only I have access to, but I
advertise that here is the corresponding unsealer. Thus if I publish
a message claiming it's from me, but the message is sealed, and you
try to unseal it, you will know it did not come from me because the
unsealing fails. This can be introduced more directly as
trademarks/brands as a simple predicate check but unsealers can be
used.
My favorite example of the use of sealers/unsealers is the teachers and
students example from:
https://www.uni-weimar.de/fileadmin/user/fak/medien/professuren/Virtual_Reality/documents/publications/capsec_vr2008_preprint.pdf
tl;dr, imagine a classroom with a teacher and with room-specific student
proxies. The students speak to the room through these proxies, and can
message each other, and can view each others' profiles. But the teacher
has the authority to silence any of those students' ability to speak in
the room if they misbehave, even though the students cannot silence each
other.
Another useful example I like to think about is an editor of a blog.
That editor sees a blogpost and, right from that page, wants to click
and edit the blogpost. Since not everyone has the right to edit every
blogpost, in a "pure" ocap system *without* unsealers or `eq?` there is
no solution; from this read-only page there is no way to know whether or
not to edit it. With eq?, the editor would have to map somewhere every
read-only blogpost reference with an associated editor-capable reference
in some table somewhere, but this is a lot to keep track of and falls
apart when the editor wasn't told about some page they had the authority
to edit in advance (introducing something akin to a publish-subscribe
requirement). Sealers/unsealers solve the problem for us because we can
attach a property to the blogpost... imagine some getter of an "edit"
capability, but the edit capability is sealed. Now the editor can
edit the blogpost right from the page.
The rights amplification analogue in ACLs would be ACL groups. The key
place where we might want them then is where you and I both have access
to, and can talk about, some object, but one of us may have more power
or different powers than the other.
But this dramatically underplays how different the things are; tofu is
sometimes called a meat analogue in that it fills a similar protein
space, but if you drop-in a 1:1 replacement of tofu you're going to have
a bad time (techniques and application are quite different).
By the say, I said "sealers/unsealers can be constructed in terms of
object references", but now let me contradict myself. I think that
sealers/unsealers always bottom out in something eq-like; maps (via
hashtables and association lists) are a common implementation, which use
object identity, and even the protected-dynamic-struct version I posted
here not a long time ago uses something eq-ish under the hood arguably.
Identifier/address/reference comparison isn't necessarily a part of an
actor or ocap system, which is disturbing.
Sealers/unsealers (and rights amplification built on them) blur the line
of the ocap mantra of "only connectivity begets connectivity".
Technically it's still true, but now we have a scenario where I might
have access something that you don't, so you might want to trick me by
mentioning the thing and getting me to do something on your behalf you
shouldn't have been able to do. Oops! (Pop culture is full of these
examples... how many times is someone trying to trick a security guard
into doing something on their behalf? No wonder Barney Fife became the
mascot of confused deputies!)
And I will argue: rights amplification is a problem, but we can't escape
it and have a complete system (or, any other solution will also be
eq-like). The reason is that we can't escape identifiers and identity,
for the very reasons we also have human language. Sometimes we might
both want to *talk about* something, and both of us have an idea of what
that thing is, even though we might not have the same authority over it.
We can't escape rights amplification for the same reasons that you and I
both talk about things even though we might not have the same authority
over them. I might link a blogpost to you and point out a typo because
you're an editor of that page and I am not. This is normal behavior and
interaction, and there is no solution to situations like them in an
eq?-free or sealer/unsealer free system.
But we have to proceed with great care. An example of the "hunting in a
bucket" problem is Norm's original confused deputy example... if I could
hand the compiler a sealed reference I encoutnered to write to a file I
could not otherwise get to, I could get it to overrite the billing
information while doing a compile for me if the compiler simply said
"hm, let me see if I have an unsealer for that... sure, looks like I do,
guess I'll unseal and write to this!" No good.
I liked what Alan said earlier in the thread:
> The capability confused deputy involved sealed boxes. You avoid it by
> choosing a specific unsealer and not looking for any unsealer that
> happened to match.
Ocap languages have a clean solution to this then, and it's called
"lexical scope": the closure of code can already have the right unsealer
sitting and waiting. It's of course possible to port this idea to other
ocap systems that aren't programming languages but I think one is likely
to get programming languages ocaps more correctly here. (This is one
reason why I've started thinking that starting with ocap languages
before talking about other ocap systems, such as certificates, is a good
idea.)
- Chris
Carl Hewitt writes:
> Since an Actor can protect itself,
> why is the Sealer/Unsealer construct needed?
>
> Regards,
> Carl
> *https://professorhewitt.blogspot.com/*
themselves... the problem comes in when we want to introduce
~"asymmetric authority" to a shared and known actor (for behavior or
information storage).
Sealers/unsealers are appropriate any time you want either information
or additional capabilities attached to something that may be seen by
many but only used by a few. It's not unlike encryption in that way,
but sealers/unsealers can be constructed in terms of object references.
There are three uses of sealers/unsealers:
- To obscure information (encryption-like)
- To obscure more authority (rights amplification)
- As authentication: I might have a sealer only I have access to, but I
advertise that here is the corresponding unsealer. Thus if I publish
a message claiming it's from me, but the message is sealed, and you
try to unseal it, you will know it did not come from me because the
unsealing fails. This can be introduced more directly as
trademarks/brands as a simple predicate check but unsealers can be
used.
My favorite example of the use of sealers/unsealers is the teachers and
students example from:
https://www.uni-weimar.de/fileadmin/user/fak/medien/professuren/Virtual_Reality/documents/publications/capsec_vr2008_preprint.pdf
tl;dr, imagine a classroom with a teacher and with room-specific student
proxies. The students speak to the room through these proxies, and can
message each other, and can view each others' profiles. But the teacher
has the authority to silence any of those students' ability to speak in
the room if they misbehave, even though the students cannot silence each
other.
Another useful example I like to think about is an editor of a blog.
That editor sees a blogpost and, right from that page, wants to click
and edit the blogpost. Since not everyone has the right to edit every
blogpost, in a "pure" ocap system *without* unsealers or `eq?` there is
no solution; from this read-only page there is no way to know whether or
not to edit it. With eq?, the editor would have to map somewhere every
read-only blogpost reference with an associated editor-capable reference
in some table somewhere, but this is a lot to keep track of and falls
apart when the editor wasn't told about some page they had the authority
to edit in advance (introducing something akin to a publish-subscribe
requirement). Sealers/unsealers solve the problem for us because we can
attach a property to the blogpost... imagine some getter of an "edit"
capability, but the edit capability is sealed. Now the editor can
edit the blogpost right from the page.
The rights amplification analogue in ACLs would be ACL groups. The key
place where we might want them then is where you and I both have access
to, and can talk about, some object, but one of us may have more power
or different powers than the other.
But this dramatically underplays how different the things are; tofu is
sometimes called a meat analogue in that it fills a similar protein
space, but if you drop-in a 1:1 replacement of tofu you're going to have
a bad time (techniques and application are quite different).
By the say, I said "sealers/unsealers can be constructed in terms of
object references", but now let me contradict myself. I think that
sealers/unsealers always bottom out in something eq-like; maps (via
hashtables and association lists) are a common implementation, which use
object identity, and even the protected-dynamic-struct version I posted
here not a long time ago uses something eq-ish under the hood arguably.
Identifier/address/reference comparison isn't necessarily a part of an
actor or ocap system, which is disturbing.
Sealers/unsealers (and rights amplification built on them) blur the line
of the ocap mantra of "only connectivity begets connectivity".
Technically it's still true, but now we have a scenario where I might
have access something that you don't, so you might want to trick me by
mentioning the thing and getting me to do something on your behalf you
shouldn't have been able to do. Oops! (Pop culture is full of these
examples... how many times is someone trying to trick a security guard
into doing something on their behalf? No wonder Barney Fife became the
mascot of confused deputies!)
And I will argue: rights amplification is a problem, but we can't escape
it and have a complete system (or, any other solution will also be
eq-like). The reason is that we can't escape identifiers and identity,
for the very reasons we also have human language. Sometimes we might
both want to *talk about* something, and both of us have an idea of what
that thing is, even though we might not have the same authority over it.
We can't escape rights amplification for the same reasons that you and I
both talk about things even though we might not have the same authority
over them. I might link a blogpost to you and point out a typo because
you're an editor of that page and I am not. This is normal behavior and
interaction, and there is no solution to situations like them in an
eq?-free or sealer/unsealer free system.
But we have to proceed with great care. An example of the "hunting in a
bucket" problem is Norm's original confused deputy example... if I could
hand the compiler a sealed reference I encoutnered to write to a file I
could not otherwise get to, I could get it to overrite the billing
information while doing a compile for me if the compiler simply said
"hm, let me see if I have an unsealer for that... sure, looks like I do,
guess I'll unseal and write to this!" No good.
I liked what Alan said earlier in the thread:
> The capability confused deputy involved sealed boxes. You avoid it by
> choosing a specific unsealer and not looking for any unsealer that
> happened to match.
"lexical scope": the closure of code can already have the right unsealer
sitting and waiting. It's of course possible to port this idea to other
ocap systems that aren't programming languages but I think one is likely
to get programming languages ocaps more correctly here. (This is one
reason why I've started thinking that starting with ocap languages
before talking about other ocap systems, such as certificates, is a good
idea.)
- Chris
Carl Hewitt writes:
> Since an Actor can protect itself,
> why is the Sealer/Unsealer construct needed?
>
> Regards,
> Carl
Alan Karp
May 31, 2021, 12:04:49 PM5/31/21
to cap-...@googlegroups.com
The usual reason for sealing a capability is to pass it through an actor you don't want to use it.
--------------
Alan Karp
--------------
Alan Karp
On Mon, May 31, 2021 at 6:32 AM Carl Hewitt Twitter: ProfCarlHewitt <carl.e...@gmail.com> wrote:
--
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/CA%2BymXc3%2BAjPFOce3CSZBv_Gh-Oqkb_rYixt-68P8dxV5T%3Dxvsw%40mail.gmail.com.
Carl Hewitt Twitter: ProfCarlHewitt
May 31, 2021, 12:11:55 PM5/31/21
to cap-talk
Why not just use facets?
A facet for an Actor x can withheld from those Actors which can use x.
Also, an Actor x can be withheld from those Actors which can use one of its facets.
Cheers,
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z2UM%3Dd65PAnUoHY9ggqQ3-C-2i4-2-0oPcoXrAvqXqyzg%40mail.gmail.com.
Mark S. Miller
May 31, 2021, 12:20:52 PM5/31/21
to cap-...@googlegroups.com
Do the MintMaker using facets
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CA%2BymXc1zcYEzY_GhCNKxdt%3DY2aRcQoMwSFt0LW7T%2BxXNoQpP9w%40mail.gmail.com.
Alan Karp
May 31, 2021, 1:55:56 PM5/31/21
to cap-...@googlegroups.com
Imagine that Actor A wants to send a message to Actor C via Actor B, an intermediary they don't trust with the contents of the message. (B might be a notary certifying delivery.) Actor A sends Actor C half of a key pair. Now, A can encrypt a message and hand it to B for delivery to C. C can read the message, but B cannot.
Now imagine the same scenario in which A wishes to send a capability to Actor C via B. Actor A creates a sealer/unsealer pair, and gives the unsealer to Actor C. Now, A can seal the capability in a box and hand it to B for delivery to C. C can extract the capability, but B cannot. How do you do this example with facets?
--------------
Alan Karp
Alan Karp
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CA%2BymXc1zcYEzY_GhCNKxdt%3DY2aRcQoMwSFt0LW7T%2BxXNoQpP9w%40mail.gmail.com.
Matt Rice
May 31, 2021, 2:12:28 PM5/31/21
to cap-talk
Thanks for pointing this out Chris, one thing in Norm's original confused deputy example is that
All parties had direct connectivity to the confused deputy, nobody was attempting to pass secrets through the compiler
between the developer and the accounting department, nobody was trying to authenticate anybody,
nobody was trying to obscure the compiler output or the billing information, and input was given to the compiler plainly.
Given that there were 3 unidirectional communications channels used Developer -> Compiler, Compiler -> Developer, Compiler -> Accounting
I don't see the point at which any of the sealing and unsealing operations are in any way necessary to produce the problem.
I would agree they are sources of confusion but not the only sources, at the same time though knowing that the solution
which allows for secure indirect communication does not actually offer any solution to the confused deputy problem is good to know but perhaps beside the point i was trying to make...
I guess one could argue it really goes Developer -> Compiler -> Accounting and there is your indirect communication but it seems more of a side-effect of the compiler than an actual communication .
anyhow I fear the thread has somewhat run away from the point I was trying to make which is it is interesting that I still fear confused deputies in applications fuchsia's design in particular more than other capability systems I've viewed,
and at the same time I don't see any explicit violations of capability discipline by the kernel itself, but sometimes that is the way threads go.
So if came across as discounting sealers/unsealers it wasn't intended in general, as it is much like discounting any encryption or privacy itself, just not seeing the relevance for this specific case...
--
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/87eedmriyy.fsf%40dustycloud.org.
William ML Leslie
Jun 1, 2021, 4:52:08 AM6/1/21
to cap-talk
On Mon, 31 May 2021 at 02:13, Matt Rice <rat...@gmail.com> wrote:
>
> I haven't tried it yet, but i'm a bit apprehensive towards it, somewhat by the number of system calls https://fuchsia.dev/fuchsia-src/reference/syscalls,
> but mostly by the idea of a per-process filesystem/namespace. https://fuchsia.dev/fuchsia-src/concepts/process/namespaces
> They at least did 2 things right with the namespaces by not implicitly inheriting between parent and child processes and the obvious lack of a global filesystem...
> Now if I could take the opportunity to paraphrase Christopher to Christopher,
>
> At some point there was a discussion on how to introduce a confused deputy problem within a capability system.
> which is something like a 2 step process, throw a bunch of capabilities into a bucket of some sort, and delegate access to that bucket with multiple people of diverging security context.
> The typical response is that this is somewhat unnatural in a capability system, you have to introduce both buckets, and a mechanism for delegating them, which works in a different way than every other process shares
> on top of a perfectly good mechanism for sharing. Thus you have to go out of your way, and jump through some hoops in order to introduce confused deputy problems.
>
> Typically when I look towards a capability OS I imagine something where we can keep filesystems and directory objects closely guarded to the shell, giving directory objects to non-shell processes should be the outlier rather than the
> modus operandi... Anyhow it feels to me like they are 1/2 way to a confused deputy such that all you need to add is delegation of the namespace, because they've normalized "putting capabilities into buckets", ...
> It seems delegation is not the expected mechanism to use but namespace transfer instead...
>
It would be great if we could remove the need to provide a (unixesque)
>
> I haven't tried it yet, but i'm a bit apprehensive towards it, somewhat by the number of system calls https://fuchsia.dev/fuchsia-src/reference/syscalls,
> but mostly by the idea of a per-process filesystem/namespace. https://fuchsia.dev/fuchsia-src/concepts/process/namespaces
> They at least did 2 things right with the namespaces by not implicitly inheriting between parent and child processes and the obvious lack of a global filesystem...
> Now if I could take the opportunity to paraphrase Christopher to Christopher,
>
> At some point there was a discussion on how to introduce a confused deputy problem within a capability system.
> which is something like a 2 step process, throw a bunch of capabilities into a bucket of some sort, and delegate access to that bucket with multiple people of diverging security context.
> The typical response is that this is somewhat unnatural in a capability system, you have to introduce both buckets, and a mechanism for delegating them, which works in a different way than every other process shares
> on top of a perfectly good mechanism for sharing. Thus you have to go out of your way, and jump through some hoops in order to introduce confused deputy problems.
>
> Typically when I look towards a capability OS I imagine something where we can keep filesystems and directory objects closely guarded to the shell, giving directory objects to non-shell processes should be the outlier rather than the
> modus operandi... Anyhow it feels to me like they are 1/2 way to a confused deputy such that all you need to add is delegation of the namespace, because they've normalized "putting capabilities into buckets", ...
> It seems delegation is not the expected mechanism to use but namespace transfer instead...
>
filesystem to a process, but if you want to support Android
applications, you've got to give them something. Additionally,
everything from ld.so to python expects to load the components of the
program from a filesystem, to say nothing of Recent Files and User
Preferences.
I agree that ideally the only thing that should have access to /the/
filesystem is the shell, however, that also assumes you're willing to
boil the ocean. Lots of tools just expect to be handed a path and
expect to be able to use it. Or maybe you could get far by
translating that path into the processes local filesystem and
disallowing .. ? That would be fun.
> uncertain on a couple of points like if it's possible to have multiple namespaces for a process, or if it is limited to a single namespace...
> Anyhow it seems like it is certainly possible to write programs with no confused deputy problems on it, which is something,
> but it seems to me an awfully thin margins in that you might not have to stray too far off the rails from the typical behavior while still being able to introduce one...
>
the filesystem root, and a reference to use as the current working
directory, and they don't have to be related. These are inherited on
fork, and are normally preserved by exec, unless the target program is
setuid on a system-trusted filesystem, in which case the setuid
program gets the system defaults. It would be interesting to pass
these additional directory objects as extra descriptors so that the
setuid programs can access them with the user's authority.
[actually exec currently thwarts this, but it seems clear that is a mistake]
I guess that Fuchsia doesn't need to support old setuid binaries, but
yeah, multiple namespaces.
Carl Hewitt Twitter: ProfCarlHewitt
Jun 1, 2021, 10:25:19 AM6/1/21
to cap-talk
Imagine that Actor A wants to send aMessage of type the private type aMessageType
to Actor C via Actor B, an intermediary on another machine that A does not trust with the contents of the message.
(B might be a notary certifying delivery.)
A can send aMessage to B, which B cannot read because it does not have aMessageType.
However, C can read aMessage that it has received from B because A has sent C the type Actor aMessageType.
Less trivial examples can make use of facets, for example in revocation.
Regards,
On Mon, May 31, 2021 at 10:55 AM Alan Karp <alan...@gmail.com> wrote:
Imagine that Actor A wants to send a message to Actor C via Actor B, an intermediary they don't trust with the contents of the message. (B might be a notary certifying delivery.) Actor A sends Actor C half of a key pair. Now, A can encrypt a message and hand it to B for delivery to C. C can read the message, but B cannot.
Alan Karp
Jun 1, 2021, 11:57:35 AM6/1/21
to cap-...@googlegroups.com
That doesn't sound like a facet to me. Instead, the type Actor aMessage is acting as both a sealer and the corresponding unsealer. Unlike the sealer/unsealer pattern, in which only Actor A can create the sealed box, in your pattern Actor C necessarily has the ability to not only read aMessage but also to create one. The analogy is the difference between asymmetric and symmetric encryption.
--------------
Alan Karp
--------------
Alan Karp
--
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/CA%2BymXc29yaDt4hOBNYuFFu7uctenSj2GvrU85YW-paLN_7uzVw%40mail.gmail.com.
Carl Hewitt Twitter: ProfCarlHewitt
Jun 1, 2021, 12:34:14 PM6/1/21
to cap-talk
The particular problem under discussion is so simple that a facet is not required ;-)
C could be restricted from creating actors of type aMessageType by
sending C the Actor (aMessageType restricted decrypt->Nullable<aMessage>)
instead of sending C the Actor aMessageType.
In this way, an application programmer does not have to be
concerned with creating and using a sealer/unsealer pair.
Cheers,
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z0oFjpiUpos%3D2su2rryknM%2B9eUY%2BpBDRmF-3_5wef73fw%40mail.gmail.com.
Mark S. Miller
Jun 1, 2021, 12:50:03 PM6/1/21
to cap-...@googlegroups.com
Do the MintMaker
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CA%2BymXc2cGXVGZHzG%3D4tC3U_fOUAWpnUuBAA03vvP6MWm7ExaDw%40mail.gmail.com.
Carl Hewitt Twitter: ProfCarlHewitt
Jun 1, 2021, 1:01:00 PM6/1/21
to cap-talk
What extra does the mintmaker require?
Here is revocation with a facet:
RevocationManager◁aType:Type▷:[aType] constructs interface revokable → aType ⦶ revoke → void♢ ~
[anActor] construct // constructor with the single argument anActor
revoked := false♢
revocable ↦ revocableFacet⦶
upgrade[revocationManagerConstructor] ↦ // upgrade to next version using revocationManagerConstructor
become revocationManagerConstructor[revoked]♢ // become next version passing along revoked
facet revocableFacet implements aType
aMessage ↦ revoked cases true ↠ throw Revoked[ ]⦶
false ↠ anActor.aMessage♢♢▮
Cheers
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAK-_AD6anCBtk%2BkHTiqnEWzJ6wUOx5jGMbvC3_gYwGmEQdceUA%40mail.gmail.com.
Alan Karp
Jun 1, 2021, 1:39:12 PM6/1/21
to cap-...@googlegroups.com
An Actor wishing to use this communication pattern must create a type Actor specifically for such messages and a restricted version of it. Is that really so much easier than making a sealer/unsealer pair? I can imagine syntactic sugar that makes one look like the other to the programmer.
--------------
Alan Karp
--------------
Alan Karp
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CA%2BymXc2cGXVGZHzG%3D4tC3U_fOUAWpnUuBAA03vvP6MWm7ExaDw%40mail.gmail.com.
Mark S. Miller
Jun 1, 2021, 1:53:25 PM6/1/21
to cap-talk
"require"? I don't know. That's why I'm asking you to code it up, to see if you can do it with only the primitives you have in mind.
If Alan's analogy holds, then the MintMaker is actually not a rich enough challenge for the full question. The MintMaker can probably be done with rights amplification analogous to symmetric-key encryption, whereas either weakmaps or sealer/unsealer pairs provide rights amplification analogous to asymmetric-key encryption.
But, in any case, the MintMaker is a good first challenge. I'll be curious to see how you write it, if someone would translate your solution into a programming language notation I can read.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CA%2BymXc2ZRkjuK0up8RxqADjdYcJAPoCjSUk9%2BotkQXbZKGvyeQ%40mail.gmail.com.
Cheers,
--MarkM
--MarkM
Matt Rice
Jun 1, 2021, 2:33:51 PM6/1/21
to cap-talk
On Tue, Jun 1, 2021 at 8:52 AM William ML Leslie <william.l...@gmail.com> wrote:
On Mon, 31 May 2021 at 02:13, Matt Rice <rat...@gmail.com> wrote:
>
> I haven't tried it yet, but i'm a bit apprehensive towards it, somewhat by the number of system calls https://fuchsia.dev/fuchsia-src/reference/syscalls,
> but mostly by the idea of a per-process filesystem/namespace. https://fuchsia.dev/fuchsia-src/concepts/process/namespaces
> They at least did 2 things right with the namespaces by not implicitly inheriting between parent and child processes and the obvious lack of a global filesystem...
> Now if I could take the opportunity to paraphrase Christopher to Christopher,
>
> At some point there was a discussion on how to introduce a confused deputy problem within a capability system.
> which is something like a 2 step process, throw a bunch of capabilities into a bucket of some sort, and delegate access to that bucket with multiple people of diverging security context.
> The typical response is that this is somewhat unnatural in a capability system, you have to introduce both buckets, and a mechanism for delegating them, which works in a different way than every other process shares
> on top of a perfectly good mechanism for sharing. Thus you have to go out of your way, and jump through some hoops in order to introduce confused deputy problems.
>
> Typically when I look towards a capability OS I imagine something where we can keep filesystems and directory objects closely guarded to the shell, giving directory objects to non-shell processes should be the outlier rather than the
> modus operandi... Anyhow it feels to me like they are 1/2 way to a confused deputy such that all you need to add is delegation of the namespace, because they've normalized "putting capabilities into buckets", ...
> It seems delegation is not the expected mechanism to use but namespace transfer instead...
>
It would be great if we could remove the need to provide a (unixesque)
filesystem to a process, but if you want to support Android
applications, you've got to give them something.
Not much to say other than i'd rather see this relegated to emulation, If what I was seeing was described as an interim or incremental step towards
a capability system rather than an end goal, I'd be overjoyed, as you know there was posix emulation for keykos and eros,
I would certainly consider this an improvement since it has less warts than posix.
Additionally, everything from ld.so to python expects to load the components of the
In the case of ld.so I think it isn't without consequence, ld.so responsible for loading libc (thus malloc), and running in the address space of the process to be,
needs to allocate a string (substring of LD_LIBRARY_PATH + DT_NEEDED length) as such it uses alloca I'm not sure how anyone can do that without scowling.
Python however is a relatively interesting example, since before python there was ABC which Guido wrote, and ran on the Amoeba distributed capability system,
I'm sure some filesystem stuff has probably crept in since then (I don't really follow python), but IIUC a lot of the impetus for writing ABC in the first place was
the awkward of porting traditional languages to capability systems...
(Sorry for somewhat irrelevant random trivia)
--
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/CAHgd1hFSUuTugcZTN2wL1ESOOsvkS0At%3D5E8LL-5EG5qG_gsnA%40mail.gmail.com.
Carl Hewitt Twitter: ProfCarlHewitt
Jun 1, 2021, 4:28:20 PM6/1/21
to cap-talk
It's easy to create a new type as follows:
myPrivateMessageType extends myMessageType
Then send (myPrivateMessageType restricted decrypt[myPrivateMessageType]->Nullable<myPrivateMessageType>) to other parties.
In any case, application programmers need to learn about manifesting and abstracting types ;-)
Type Actors are a powerful generally useful mechanism unlike the seal/unseal protocol.
Regards,
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z2gnpOrvAHXPx9_bn%3DdBmqetwFTBZaGT0dgMV%2BZTz%3D4Rw%40mail.gmail.com.
Carl Hewitt Twitter: ProfCarlHewitt
Jun 1, 2021, 4:33:58 PM6/1/21
to cap-talk
A great thing about Alan's contribution was that
he was able to identify a fundamental principle.
We need more focus on fundamental principles and general mechanisms.
Mark: Do you have a better example than MintMaker?
Regards,
PS. I agree with Mark that it can be difficult to understand programming language notation.
Mark S. Miller
Jun 1, 2021, 4:37:40 PM6/1/21
to cap-...@googlegroups.com
On Tue, Jun 1, 2021 at 1:28 PM Carl Hewitt Twitter: ProfCarlHewitt <carl.e...@gmail.com> wrote:
It's easy to create a new type as follows:myPrivateMessageType extends myMessageTypeThen send (myPrivateMessageType restricted decrypt[myPrivateMessageType]->Nullable<myPrivateMessageType>) to other parties.In any case, application programmers need to learn about manifesting and abstracting types ;-)Type Actors are a powerful generally useful mechanism unlike the seal/unseal protocol.
"powerful generally useful mechanism unlike the seal/unseal protocol." ? I call bullshit.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CA%2BymXc22HODWHga6JgTEwEAWyEWaC8gUdy98Y4p75wqAo9hBYA%40mail.gmail.com.
Mark S. Miller
Jun 1, 2021, 4:40:28 PM6/1/21
to cap-...@googlegroups.com
On Tue, Jun 1, 2021 at 1:33 PM Carl Hewitt Twitter: ProfCarlHewitt <carl.e...@gmail.com> wrote:
A great thing about Alan's contribution was thathe was able to identify a fundamental principle.We need more focus on fundamental principles and general mechanisms.Mark: Do you have a better example than MintMaker?
Better in what sense? In any case, it is a good example.
Regards,PS. I agree with Mark that it can be difficult to understand programming language notation.
I have little problem with much conventional programming language notation. However, from recent experience I anticipate having problems interpreting Carl's solution to the MintMaker, which is why I asked for someone to translate it.
--
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/CA%2BymXc1d25x%3DxDdFZnm1ubz8vbC3FeJ9zd1kJz3nj6h%3DHBm8ng%40mail.gmail.com.
Carl Hewitt Twitter: ProfCarlHewitt
Jun 1, 2021, 5:02:29 PM6/1/21
to cap-talk
Carl Hewitt Twitter: ProfCarlHewitt
Jun 1, 2021, 5:07:02 PM6/1/21
to cap-talk
Mark: You indicated that the MintMaker example might not illustrate the full power of the Seal/Unseal protocol.
A better example might provide more insight.
Mark S. Miller
Jun 1, 2021, 5:10:31 PM6/1/21
to cap-talk
Why the claim that the seal/unseal protocol is not a powerful generally useful mechanism? Sorry for the expletive. I'll retract that. But my point is that is an assertion that is both wrong, and one you are making in ignorance and without any evidence.
--
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/CA%2BymXc0EH%2B4QBdW_Fxdw9W5p%2BcpdXqLhZ61DH9aacrRJuyZzNg%40mail.gmail.com.
Cheers,
--MarkM
--MarkM
Mark S. Miller
Jun 1, 2021, 5:14:04 PM6/1/21
to cap-talk
On Tue, Jun 1, 2021 at 2:07 PM Carl Hewitt Twitter: ProfCarlHewitt <carl.e...@gmail.com> wrote:
Mark: You indicated that the MintMaker example might not illustrate the full power of the Seal/Unseal protocol.A better example might provide more insight.
This is true. I'll try to find a good clear simple example that demonstrates the power of the asymmetric nature of seal/unseal. But until then, the MintMaker challenge is certainly a fine first example.
If anyone has a suggested small simple challenge that illustrates the power of the asymmetric nature of seal/unseal, please post! Thanks.
On Tue, Jun 1, 2021 at 1:40 PM 'Mark S. Miller' via cap-talk <cap-...@googlegroups.com> wrote:On Tue, Jun 1, 2021 at 1:33 PM Carl Hewitt Twitter: ProfCarlHewitt <carl.e...@gmail.com> wrote:A great thing about Alan's contribution was thathe was able to identify a fundamental principle.We need more focus on fundamental principles and general mechanisms.Mark: Do you have a better example than MintMaker?Better in what sense? In any case, it is a good example.
--
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/CA%2BymXc0_26YtTXo00gupi9zxD3nWjbZuKPARfJtS2Af%3D9_Yeeg%40mail.gmail.com.
Cheers,
--MarkM
--MarkM
Matt Rice
Jun 1, 2021, 5:30:57 PM6/1/21
to cap-talk
On Tue, Jun 1, 2021 at 9:14 PM Mark S. Miller <eri...@gmail.com> wrote:
On Tue, Jun 1, 2021 at 2:07 PM Carl Hewitt Twitter: ProfCarlHewitt <carl.e...@gmail.com> wrote:Mark: You indicated that the MintMaker example might not illustrate the full power of the Seal/Unseal protocol.A better example might provide more insight.This is true. I'll try to find a good clear simple example that demonstrates the power of the asymmetric nature of seal/unseal. But until then, the MintMaker challenge is certainly a fine first example.If anyone has a suggested small simple challenge that illustrates the power of the asymmetric nature of seal/unseal, please post! Thanks.
I'm not sure, off the top of my head I can think of some asymmetric uses of seal/unseal i've toyed with but these were somewhat reliant on confinement,
in particular a gift purchase/delivery agent which doesn't reveal the shipping address to the purchaser or the shop (So you cannot obtain the delivery address by starting a shop, only by starting a delivery agent).
similarly the delivery agent wasn't able to unseal the package I'd done this in the context of using typed communications channels between shop -> delivery agent... where the delivery agent was restricted to receiving sealed packages,
only the shipping destination could unseal, the shop could merely seal these packages and produce the sealed gift. Anyhow it had 4 participants shop, delivery agent, receiver and purchaser... maybe something like this could work...
----On Tue, Jun 1, 2021 at 1:40 PM 'Mark S. Miller' via cap-talk <cap-...@googlegroups.com> wrote:On Tue, Jun 1, 2021 at 1:33 PM Carl Hewitt Twitter: ProfCarlHewitt <carl.e...@gmail.com> wrote:A great thing about Alan's contribution was thathe was able to identify a fundamental principle.We need more focus on fundamental principles and general mechanisms.Mark: Do you have a better example than MintMaker?Better in what sense? In any case, it is a good example.
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/CA%2BymXc0_26YtTXo00gupi9zxD3nWjbZuKPARfJtS2Af%3D9_Yeeg%40mail.gmail.com.
--Cheers,
--MarkM
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/CAK5yZYjhYxuVtJ3iUK9PHHSmvDhgYVEiK%2BZo%3D91gNSq1uTXVig%40mail.gmail.com.
Mark S. Miller
Jun 1, 2021, 5:48:47 PM6/1/21
to cap-talk
Thanks Matt, this reminds me of two more things. The invention of sealer/unsealer by James Morris in the extraordinary 1973 6 page paper "Protection in Programming Languages" http://www.erights.org/history/morris73.pdf
The use I make of sealer/unsealer in Horton http://www.erights.org/elib/capability/horton/index.html inherently relies on its asymmetric nature.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CACTLOFq3vYBYsy4DmOZXVTzvxS7bmLGctb%2BtCi%2B%2BGT6QhxM1%2Bg%40mail.gmail.com.
Cheers,
--MarkM
--MarkM
Carl Hewitt Twitter: ProfCarlHewitt
Jun 1, 2021, 5:53:50 PM6/1/21
to cap-talk
From what I have seen so far, the seal/unseal protocol seems very special purpose.
It would be interesting to see a formal analysis of the relative power of seal/unseal versus using type Actors and facets.
Regards,
Carl Hewitt Twitter: ProfCarlHewitt
Jun 1, 2021, 5:56:56 PM6/1/21
to cap-talk
Thanks Matt!
It would be great to see your examples worked out.
Cheers,
Chip Morningstar
Jun 1, 2021, 6:02:19 PM6/1/21
to cap-...@googlegroups.com
On Jun 1, 2021, at 2:53 PM, Carl Hewitt Twitter: ProfCarlHewitt <carl.e...@gmail.com> wrote:From what I have seen so far, the seal/unseal protocol seems very special purpose.
How can you call it special purpose? It’s basically asymmetric cryptography (known to be generally useful) without the cryptography.
Carl Hewitt Twitter: ProfCarlHewitt
Jun 1, 2021, 6:11:47 PM6/1/21
to cap-talk
Thanks Chip!
Cryptography is indeed a general purpose mechanism.
However, this doesn't mean that application programmers should be required to
surface encryption keys and specific crypto algorithms.
Suitable abstractions can often get a job done without having to surface implementation machinery.
Regards,
Mark S. Miller
Jun 1, 2021, 6:28:55 PM6/1/21
to cap-...@googlegroups.com
Carl, what do you think Chip meant by "without the cryptography"?
What abstraction do you think we're talking about? What implementation machinery? Are we in the same conversation?
In any case, to see how well seal/unseal can be hidden, let's see you write the MintMaker without seal/unseal. Then we can proceed to the other examples.
--
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/CA%2BymXc0%3DjfOkboFo4-gU2i0S6ZZgdiLgjD%2BTfSN09VJQQ3__SQ%40mail.gmail.com.
Carl Hewitt Twitter: ProfCarlHewitt
Jun 1, 2021, 6:46:17 PM6/1/21
to cap-talk
Sorry! Because of bad formatting on my computer I missed Chip's tail end phrase "without cryptography".
But my points about the value of abstraction and the value of general purpose programming language constructs still stands.
The sealer/unsealer primitive still seems low level, awkward, special purpose, and superfluous.
Why do you think that type Actors and facets can't do the MintMaker?
I am personally more interested in looking at Matt's examples, which sound like they may be of practical importance.
Regards,
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAK-_AD4mCbLPThciHpC-oKKFBLr%2B1fhCpL_4Sf9UadYoFbo%3DbQ%40mail.gmail.com.
Mark S. Miller
Jun 1, 2021, 6:59:41 PM6/1/21
to cap-...@googlegroups.com
On Tue, Jun 1, 2021 at 3:46 PM Carl Hewitt Twitter: ProfCarlHewitt <carl.e...@gmail.com> wrote:
Sorry! Because of bad formatting on my computer I missed Chip's tail end phrase "without cryptography".But my points about the value of abstraction and the value of general purpose programming language constructs still stands.The sealer/unsealer primitive still seems low level, awkward, special purpose, and superfluous.Why do you think that type Actors and facets can't do the MintMaker?
Because even after repeated challenges, you have not shown how it can.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CA%2BymXc34fAwroXSjbUJZ85KO2UR-d-0Z0pqbq3ei%3Dbxn-EhCKA%40mail.gmail.com.
Carl Hewitt Twitter: ProfCarlHewitt
Jun 1, 2021, 8:28:08 PM6/1/21
to cap-talk
Here is an implementation of
SealedUnsealer using facets:
SealedUnsealer◁aType:Type▷:[aType] constructs interface getSealed → NoMessages ⦶ getUnsealer→ Unsealer◁aType▷ ♢ ~
[anActor] construct // constructor with the single argument anActor
aSealerUnsealer <-
SealedUnsealer◁aType▷[x]
Now,
Regards,
---------- Forwarded message ---------
From: Carl Hewitt Twitter: ProfCarlHewitt <carl.e...@gmail.com>
Date: Tue, Jun 1, 2021 at 10:00 AM
Subject: Re: Sealer/Unsealer is superfluous?
To: cap-talk <cap-...@googlegroups.com>
From: Carl Hewitt Twitter: ProfCarlHewitt <carl.e...@gmail.com>
Date: Tue, Jun 1, 2021 at 10:00 AM
Subject: Re: Sealer/Unsealer is superfluous?
To: cap-talk <cap-...@googlegroups.com>
What extra does the Mintmaker require?
Mark S. Miller
Jun 1, 2021, 9:00:08 PM6/1/21
to cap-...@googlegroups.com
Thank you! Demonstrating that facets are adequate to implement seal/unseal would indeed suffice to demonstrate that facets are adequate to implement the MintMaker. (assuming no other surprises, but I'm not expecting any)
Now, can someone else translate this into programming language notation I can understand? Thanks.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CA%2BymXc07xDPu-4cKWHg36Tr2qzCGwAGKZs2r9X3f2tZqCsVP0Q%40mail.gmail.com.
Alan Karp
Jun 1, 2021, 10:53:58 PM6/1/21
to cap-...@googlegroups.com
Does Carl's code implement a facet? My understanding is that an attenuating facet forwards a subset of the messages the underlying object can handle. I'm no better at reading ActorScript than you are, but I don't see any forwarding.
--------------
Alan Karp
--------------
Alan Karp
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAK-_AD7niR5H3NF-X5KB8Xp%2BBZuw%2B-wAVkFM4Qek4ipFUVL0_g%40mail.gmail.com.
Mark S. Miller
Jun 1, 2021, 10:57:11 PM6/1/21
to cap-...@googlegroups.com
Alan, that is not what I mean by "facet". But I won't elaborate now, because the current issue hinges on what Carl means.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z0gR%2BPaBxjN1%3DuZnsO%3DS1tfjUWFJJ3wpFF3CwEU77DRCw%40mail.gmail.com.
Chris Hibbert
Jun 1, 2021, 11:09:48 PM6/1/21
to cap-...@googlegroups.com, Mark S. Miller
On 6/1/21 2:13 PM, Mark S. Miller wrote:
>
>
> On Tue, Jun 1, 2021 at 2:07 PM Carl Hewitt Twitter: ProfCarlHewitt
> <carl.e...@gmail.com <mailto:carl.e...@gmail.com>> wrote:
>
> Mark: You indicated that the MintMaker example might not illustrate
> the full power of the Seal/Unseal protocol.
> A better example might provide more insight.
>
>
> This is true. I'll try to find a good clear simple example that
> demonstrates the power of the asymmetric nature of seal/unseal. But
> until then, the MintMaker challenge is certainly a fine first example.
>
> If anyone has a suggested small simple challenge that illustrates the
> power of the asymmetric nature of seal/unseal, please post! Thanks.
>
One of the virtues of the mintMaker as an example challenge is that
>
>
> On Tue, Jun 1, 2021 at 2:07 PM Carl Hewitt Twitter: ProfCarlHewitt
> <carl.e...@gmail.com <mailto:carl.e...@gmail.com>> wrote:
>
> Mark: You indicated that the MintMaker example might not illustrate
> the full power of the Seal/Unseal protocol.
> A better example might provide more insight.
>
>
> This is true. I'll try to find a good clear simple example that
> demonstrates the power of the asymmetric nature of seal/unseal. But
> until then, the MintMaker challenge is certainly a fine first example.
>
> If anyone has a suggested small simple challenge that illustrates the
> power of the asymmetric nature of seal/unseal, please post! Thanks.
>
we've written it in at least a half-dozen different languages, and I
suspect fellow-travelers in OCaps have written a half-dozen more that I
haven't seen. The main challenge of the mintMaker is that it requires
synergy, and is just complex enough to require a few classes to
interact. We've achieved synergy with sealer-unsealer, crypto, weakmaps,
lexical variables (I think), and other approaches. Seeing how this is
done in a different paradigm is usually instructive.
Chris
--
Rationality is about drawing correct inferences from limited,
confusing, contradictory, or maliciously doctored facts.
-- Scott Alexander
Chris Hibbert
hib...@mydruthers.com
Blog: http://www.pancrit.org
Twitter: C_Hibbert_reads
http://mydruthers.com
Carl Hewitt Twitter: ProfCarlHewitt
Jun 2, 2021, 6:40:26 AM6/2/21
to cap-talk
Here is a better-suited implementation of
SealedUnsealer using facets:
SealedUnsealer◁aType:Type▷:[aType] constructs interface getSealed→Sealed ⦶ getUnsealer→Unsealer◁aType▷ ♢ ~
facet sealedFacet implements Sealed
facet unsealFacet implements
Unsealer◁aType▷ using
- aSealed can be given out as the sealed x
Regards,
Carl Hewitt Twitter: ProfCarlHewitt
Jun 2, 2021, 6:43:19 AM6/2/21
to cap-talk
Thanks Alan!
A facet is allowed to implement any interface whatsoever.
See what you think of the updated implementation that I just sent out.
Cheers,
On Tue, Jun 1, 2021 at 7:53 PM Alan Karp <alan...@gmail.com> wrote:
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z0gR%2BPaBxjN1%3DuZnsO%3DS1tfjUWFJJ3wpFF3CwEU77DRCw%40mail.gmail.com.
Carl Hewitt Twitter: ProfCarlHewitt
Jun 2, 2021, 6:46:47 AM6/2/21
to cap-talk, Mark S. Miller
Thanks Chris!
It would be interesting to see implementations of SealedUnsealer in other systems.
Regards,
--
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/0f5c6a1e-2cbe-f099-180a-dc7ae194b3f5%40mydruthers.com.
Ken Kahn
Jun 2, 2021, 10:30:08 AM6/2/21
to cap-talk
Carl, I wonder if you can add comments to every line of your example. I often feel I have a partial understanding of your programs.
Mike Stay
Jun 2, 2021, 12:17:32 PM6/2/21
to cap-...@googlegroups.com
Here's my guess at a TypeScript implementation:
interface NoMessages {}
interface U<A> {
unseal: (x: NoMessages) => A
}
interface SU<A> {
getSealed: () => NoMessages;
getUnsealer: () => U<A>
}
let makeSealedUnsealer = function <A>(a: A): SU<A> {
class Sealed implements NoMessages {}
class Unsealer implements U<A> {
unseal(x: NoMessages): A {
if (x instanceof Sealed) {
return a;
}
else throw(new TypeError())
}
}
class SealedUnsealer implements SU<A> {
getSealed() {
// In TypeScript and JavaScript,
// there's no getting around instances
// leaking the constructor class.
// ActorScript probably uses a WeakMap
// for its implementation of the
// instanceof check in unseal(x).
return new Sealed();
}
getUnsealer(): U<A> {
return new Unsealer();
}
}
return new SealedUnsealer();
}
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CA%2BymXc0RZ58-aUvqOD65sMiS2H6CsHXWXR66kQJOAOVNob6Brw%40mail.gmail.com.
Mike Stay
Jun 2, 2021, 1:21:59 PM6/2/21
to cap-...@googlegroups.com
Hmm, I got that translation wrong. Carl's code checks equality with sealedFacet, not that x is an instance of Sealed. So I think this is probably a better translation:
interface S {}
interface U<A> {
unseal: (x: S) => A
}
interface SU<A> {
getSealed: () => S;
getUnsealer: () => U<A>
}
function makeSealedUnsealer<A>(a: A): SU<A> {
class Sealed implements S {}
let sealed = new Sealed();
class Unsealer implements U<A> {
unseal(x: S): A {
if (x == sealed) {
return a;
}
else throw(new TypeError())
}
}
class SealedUnsealer implements SU<A> {
getSealed() {
return sealed;
}
getUnsealer(): U<A> {
return new Unsealer();
}
}
return new SealedUnsealer();
}
Mike Stay
Jun 2, 2021, 1:32:49 PM6/2/21
to cap-...@googlegroups.com
Carl, your code works for a single x, but the point of a sealer/unsealer pair is that just as with public & private keys, they can be reused. Anything sealed with the sealer should be retrievable using the unsealer and only with the unsealer.
Carl Hewitt Twitter: ProfCarlHewitt
Jun 3, 2021, 8:37:25 AM6/3/21
to cap-talk
Ken:
Thanks for the suggestion!
Since the situation is evolving,
I suggest that SealerUnsealer be a possible topic Friday at FriAM.
Cheers,
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/39b27352-ef54-4a4b-a368-d187bbfcfb25n%40googlegroups.com.
Carl Hewitt Twitter: ProfCarlHewitt
Jun 3, 2021, 9:15:24 AM6/3/21
to cap-talk
Mike,
You are correct!
A improved version is below.
Thanks!
Here is an implementation of
SealerUnsealer using facets:
SealerUnsealer◁aType:Type▷:[aType]
→
interface
getSealer→Sealer
◁aType▷
getUnsealer→Unsealer◁aType▷
[ ] ↦ // constructor with no arguments
getSealer ↦ sealerFacet
getUnsealer ↦ unsealerFacet
facet sealerFacet implements Sealer◁aType▷
using
seal[y] ↦ implementation Sealed◁aType▷ using
get[z]
↦
z cases
unsealerFacet
↠ y
facet unsealerFacet implements
Unsealer◁aType▷ using
unseal[y] ↦ y.get[unsealerFacet]
aSealerUnsealer
←
SealerUnsealer◁aType▷.[ ]
aSealer
←
aSealerUnsealer.getSealer
On Wed, Jun 2, 2021 at 10:32 AM Mike Stay <meta...@gmail.com> wrote:
Carl, your code works for a single x, but the point of a sealer/unsealer pair is that just as with public & private keys, they can be reused. Anything sealed with the sealer should be retrievable using the unsealer and only with the unsealer.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAKQgqTaduU3NqYZKmZCKceNVm8j%3DNqEHK3s7zB5Tm5XWd1S-nQ%40mail.gmail.com.
Mark S. Miller
Jun 3, 2021, 12:40:22 PM6/3/21
to cap-talk
Hi Mike, can you translate Carl's latest? That would help a lot. Thanks!
--
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/CA%2BymXc1b5zW4D_Kqisnm4v1TOWysdc56-7bVoZyspn5BX1%2BOUQ%40mail.gmail.com.
Cheers,
--MarkM
--MarkM
Mike Stay
Jun 3, 2021, 2:10:05 PM6/3/21
to cap-...@googlegroups.com
I think this is the right translation, but I might be missing something subtle in the way Carl's using types.
let makeSealerUnsealer = () => {
let unseal = y => y.get(unseal);
let seal = (y) => ({
'get': (unsealer) => {
if (unsealer == unseal) {
return y;
}
throw new TypeError();
}
});
return {seal, unseal};
};
The obvious attack is to provide a y to unseal() that steals the reference to unseal(). Since Sealer<aType> is just an interface for an actor providing a seal method that returns an actor providing a get method that either returns an aType or throws, I think it's possible to implement such a thieving actor in Carl's framework.
--
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/CA%2BymXc1b5zW4D_Kqisnm4v1TOWysdc56-7bVoZyspn5BX1%2BOUQ%40mail.gmail.com.
Mark S. Miller
Jun 3, 2021, 3:33:00 PM6/3/21
to cap-...@googlegroups.com
That particular vulnerability has a long history. Carl, at least you're far from the first to make that particular mistake.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAKQgqTZO%3D4s6GYxyw-i4YbVoyL_PN69%3DByiYkPW0JexOyZeN%2BA%40mail.gmail.com.
Mike Stay
Jun 3, 2021, 4:02:53 PM6/3/21
to cap-...@googlegroups.com
Oops! That should be ===; otherwise you could supply a string and get them to compare equal.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAK-_AD5S0y1ACdcLMbJZi_vX62qX5S4mY0wKAqnpfFBfV-NTBg%40mail.gmail.com.
Carl Hewitt Twitter: ProfCarlHewitt
Jun 3, 2021, 6:59:17 PM6/3/21
to cap-talk
Illustrate perils of not using strong-enough-typing ;-)
Also illustrates perils of not providing complete implementations.
Regards,
Here is a more-fleshed-out and more-strongly-typed implementation of
SealerUnsealer using facets:
Sealed◁aType:Type▷:[aType,
Unsealer◁aType▷]→interface get[Unsealer◁aType▷]→aType
[y, anUnsealerFacet]
↦
get[z]
↦
z cases
anUnsealerFacet
↠ y
Unsealer◁aType▷
interface unseal[Sealed]→aType
SealerUnsealer◁aType:Type▷
interface unseal[Sealed]→aType
seal[y] ↦ Sealed◁aType▷.[y, unsealerFacet]
aSealerUnsealer
←
SealerUnsealer◁aType▷.[ ]
aSealer
←
aSealerUnsealer.getSealer
Now,
- aSealed can be given out as the sealed x,
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAK-_AD5S0y1ACdcLMbJZi_vX62qX5S4mY0wKAqnpfFBfV-NTBg%40mail.gmail.com.
Mike Stay
Jun 3, 2021, 8:01:24 PM6/3/21
to cap-...@googlegroups.com
I don't see how the type information prevents me from deriving from Sealed and overriding get[] with an implementation that steals unsealerFacet.
Does ActorScript, like Rust, not support inheritance? If so, then I think this might work. The unseal method requires a parameter of type Sealed, so there must be some kind of check (static or runtime) that the "box" provided to the unsealer is an instance of Sealed. This is effectively the same as using the WeakMap to prove that it has been branded. Since (by my assumption above) Sealed cannot be subclassed, the unsealerFacet parameter cannot be intercepted.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CA%2BymXc1nfMxgFAJgDw6sJqb05UU%2BjjXToiq_v4SYbw4rbhN8eA%40mail.gmail.com.
Carl Hewitt Twitter: ProfCarlHewitt
Jun 3, 2021, 9:07:29 PM6/3/21
to cap-talk
Thanks for picking up on the "branding" issue, Mike!
Constructions in ActorScript can be used by other constructions but there is no way to impersonate a construction using something like Simula "subclassing".
In other words, constructions are "branded".
Regards,
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAKQgqTbDogzZJ1u50mak5_3-tBtVC82s_Tn-A4VHA7_3VXNJ1A%40mail.gmail.com.
Carl Hewitt Twitter: ProfCarlHewitt
Jun 3, 2021, 10:06:36 PM6/3/21
to cap-talk
PS. Idea is to get the code sharing benefits of languages like C++ without
security vulnerabilities of impersonation using multiple inheritance.
Dan Connolly
Jun 5, 2021, 9:01:01 PM6/5/21
to cap-...@googlegroups.com, Mark S. Miller
On Wed, Jun 2, 2021 at 5:46 AM Carl Hewitt Twitter: ProfCarlHewitt <carl.e...@gmail.com> wrote:
It would be interesting to see implementations of SealedUnsealer in other systems.
Back in 2011, I wrote up Capability Security in E, coffescript, python, dart, and scala . Relevant excerpt:
For example, take a look at the simple money example in E and the underlying sealer/unsealer pattern.
I have been using these as an exercise to explore some of the recent programming language developments:
- money.coffee in August
- sealing.py in October
- money.dart November 10
- money.scala November 11
I can also throw in Rholang now: SealerUnsealer · dckc/awesome-ocap Wiki
Dan Connolly
Matt Rice
Jun 6, 2021, 1:43:08 AM6/6/21
to cap-talk
Unfortunately it hasn't been finished yet, I can give the sealer/unsealer/trademark, a trademarking sealer and some auxiliary multiparty trademarking implementations
These were the types the example was crafted to be able to leverage, but the language lacks a number of things to finish the complete example.
the first practical limitation is that it lacks a primitive reference type or state monad, and the 2nd limitation is the compiler lacks the ability to achieve confinement
A pure arrow (=>), imperative arrow (->) dichotomy isn't enough, So to do it as I would like requires one to be able to pass effect polymorphic functions by parameter...
The given implementations already use a ton of uncommon language features (applicative functors, generative functors, and curried and partially applied to boot),
as such there isn't really another language I can try and port this to afaik some I know have the effect polymorphism, but I don't know of any with all these features + effect polymorphism,
so finishing up the example still requires a bunch of compiler work.
The sealer/unsealer implementation in particular mostly resembles Christopher's racket implementation which IIUC generates a struct...
and it's all a bunch of statically typed nonsense, so not as dynamic as many you'll encounter.
Anyhow i've generally tried to leverage the static types and advanced typing to make everything as "misuse resistant" as possible it is somewhat commented in regard to that,
sorry for the delay in responding
On Tue, Jun 1, 2021 at 9:56 PM Carl Hewitt Twitter: ProfCarlHewitt <carl.e...@gmail.com> wrote:
Thanks Matt!It would be great to see your examples worked out.Cheers,On Tue, Jun 1, 2021 at 2:30 PM Matt Rice <rat...@gmail.com> wrote:
On Tue, Jun 1, 2021 at 2:07 PM Carl Hewitt Twitter: ProfCarlHewitt <carl.e...@gmail.com> wrote:Mark: You indicated that the MintMaker example might not illustrate the full power of the Seal/Unseal protocol.A better example might provide more insight.This is true. I'll try to find a good clear simple example that demonstrates the power of the asymmetric nature of seal/unseal. But until then, the MintMaker challenge is certainly a fine first example.If anyone has a suggested small simple challenge that illustrates the power of the asymmetric nature of seal/unseal, please post! Thanks.
I'm not sure, off the top of my head I can think of some asymmetric uses of seal/unseal i've toyed with but these were somewhat reliant on confinement,in particular a gift purchase/delivery agent which doesn't reveal the shipping address to the purchaser or the shop (So you cannot obtain the delivery address by starting a shop, only by starting a delivery agent).similarly the delivery agent wasn't able to unseal the package I'd done this in the context of using typed communications channels between shop -> delivery agent... where the delivery agent was restricted to receiving sealed packages,only the shipping destination could unseal, the shop could merely seal these packages and produce the sealed gift. Anyhow it had 4 participants shop, delivery agent, receiver and purchaser... maybe something like this could work...
--
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/CA%2BymXc1puhkY4Xme8OLdxZXi9i3Upigsayhx-ppRY4XjjHRJaQ%40mail.gmail.com.
Carl Hewitt Twitter: ProfCarlHewitt
Jun 6, 2021, 1:09:17 PM6/6/21
to cap-talk
Matt Rice
Jun 6, 2021, 4:05:47 PM6/6/21
to cap-talk
That example? No I don't believe so, others examples can leverage the additional complexity and mutual trust in the type system to move the barrier at which untrusted code can run...
In theory at least by moving the trust barrier you should be able to safely run an untrusted keykos factory pattern and compose factories and split domains recursively...
--
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/CA%2BymXc3gFgWK5AqGjJcsiHMTb6u-KKqYxaF46_bewt26Mr8sCQ%40mail.gmail.com.
Christopher Lemmer Webber
Jun 14, 2021, 11:35:02 AM6/14/21
to cap-...@googlegroups.com, Dan Finlay
There was a bit more written recently about Fuchsia's security
properties:
https://blog.cr0.org/2021/06/a-few-thoughts-on-fuchsia-security.html?m=1
As usual, HN comment threads tend to be a... mixed bag, but there's
some interesting stuff here:
https://news.ycombinator.com/item?id=27487465
It's curious to see how much more the HN threads seem to be focusing on
the Rust stuff than the ocaps stuff. Read what you will into the
zeitgeist there (I'm not saying it's bad by any means, memory safety is
obviously foundational); I do think ocaps are making inroads into the
public consciousness though. There's a large potential that Fuchsia
could be the thing that cracks it into the "well OBVIOUSLY" hype. How
long until people start giving talks about NoACL systems? ;)
I haven't tried Fuchsia yet still, but I'd like to. I guess I should
figure out how to get started. I wonder if we can get Julien / cr0 on
here or on Friam to talk with us more. It would be interesting to find
out more about where Fuchsia is going.
One of the surprises from looking at the Fuchsia page was reading about
BlobFS:
https://fuchsia.dev/fuchsia-src/concepts/filesystems/blobfs
Content-addressed storage as a foundation?! Interesting!
I guess I should spend more reading on this page:
https://fuchsia.dev/fuchsia-src/concepts
Maybe the right thing to load into my phone for some AFDesktop
reading...
- Chris
Side note, I've found it very hard to remember how to spell Fuchsia. I
notice that Dan made a typo to, but different than the ones I usually
make (Fushia, Fucia, etc). I guess that'll go away if Fuchsia gains
popularity.
properties:
https://blog.cr0.org/2021/06/a-few-thoughts-on-fuchsia-security.html?m=1
As usual, HN comment threads tend to be a... mixed bag, but there's
some interesting stuff here:
https://news.ycombinator.com/item?id=27487465
It's curious to see how much more the HN threads seem to be focusing on
the Rust stuff than the ocaps stuff. Read what you will into the
zeitgeist there (I'm not saying it's bad by any means, memory safety is
obviously foundational); I do think ocaps are making inroads into the
public consciousness though. There's a large potential that Fuchsia
could be the thing that cracks it into the "well OBVIOUSLY" hype. How
long until people start giving talks about NoACL systems? ;)
I haven't tried Fuchsia yet still, but I'd like to. I guess I should
figure out how to get started. I wonder if we can get Julien / cr0 on
here or on Friam to talk with us more. It would be interesting to find
out more about where Fuchsia is going.
One of the surprises from looking at the Fuchsia page was reading about
BlobFS:
https://fuchsia.dev/fuchsia-src/concepts/filesystems/blobfs
Content-addressed storage as a foundation?! Interesting!
I guess I should spend more reading on this page:
https://fuchsia.dev/fuchsia-src/concepts
Maybe the right thing to load into my phone for some AFDesktop
reading...
- Chris
Side note, I've found it very hard to remember how to spell Fuchsia. I
notice that Dan made a typo to, but different than the ones I usually
make (Fushia, Fucia, etc). I guess that'll go away if Fuchsia gains
popularity.
Mike Stay
Jun 14, 2021, 12:06:38 PM6/14/21
to cap-...@googlegroups.com, Dan Finlay
It's unfortunately crude, but the only mnemonic that works for me is
that the spelling of fuchsia really "fucks ya" over.
that the spelling of fuchsia really "fucks ya" over.
> --
> 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/87fsxkzcgr.fsf%40dustycloud.org.
> 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.
Valerio Bellizzomi
Jun 14, 2021, 12:30:11 PM6/14/21
to cap-talk
Not necessarily in-topic but the Intel Cloud Hypervisor is written in Rust, and they not only use Rust but also they contribute patches back to Rust repositories.
Christopher Lemmer Webber
Jun 14, 2021, 12:48:05 PM6/14/21
to cap-...@googlegroups.com, Dan Finlay, Mike Stay
Oh wow. That... is a crude mnemonic that works, you're right.
It is loading more messages.
0 new messages