Tuesday, November 3, 2015

Fwd: [cap-talk] [friam] Re: UX resources for object capabilities



Sent from my iPhone

Begin forwarded message:

From: William ML Leslie <william.leslie.ttg@gmail.com>
Date: November 2, 2015 at 22:09:12 EST
To: "General discussions concerning capability systems." <cap-talk@mail.eros-os.org>
Subject: Re: [cap-talk] [friam] Re: UX resources for object capabilities
Reply-To: "General discussions concerning capability systems." <cap-talk@mail.eros-os.org>

"User driven access control: rethinking permission granting in modern
operating systems (Oakland 2012)" is a great place to start.  From
there, many of the cited papers are handy too.

You can get the paper from __apf__'s list here:

https://docs.google.com/document/d/1N5uTePbaHGGz70nX5zc28Cil026f80oR_ypAxo5ar40/edit

--
William Leslie

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.
_______________________________________________
cap-talk mailing list
cap-talk@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/cap-talk

Thursday, July 23, 2015

EXCLUSIVE: Entire US national security system possibly compromised by year-long cyber-assault

The prolonged hacking into the White House Office of Personnel Management, which put the personal information of at least some 21.5 million past and current federal employees in jeopardy, is only the beginning of the security threat to the Obama Administration and its successors, a number of top-level experts in cybersecurity have told Fox News.&#160;The attack has been frequently sourced as coming from China.

http://www.foxnews.com/politics/2015/07/23/entire-us-national-security-system-possibly-compromised-by-year-long-cyber/

Sent via the Fox News app for Android. Download the app here:

https://play.google.com/store/apps/details?id=com.foxnews.android

ken

Thursday, June 4, 2015

BBC News: US hit by 'massive data breach'

I saw this story on the BBC News iPhone App and thought you should see it:

US hit by 'massive data breach'

Chinese hackers are suspected of carrying out a "massive breach" affecting the personal data of millions of US government workers, officials said.

Read more:
http://www.bbc.co.uk/news/world-us-canada-33017310


** Disclaimer **
The BBC is not responsible for the content of this e-mail, and anything written in this e-mail does not necessarily reflect the BBC's views or opinions. Please note that neither the e-mail address nor name of the sender have been verified.


Sent from my iPhone

Wednesday, May 27, 2015

Monday, February 2, 2015

Fwd: [Caja] Understanding the difference between Google Caja and Secure ECMAScript (SES), and if SES is ready to use



Sent from my iPhone

Begin forwarded message:

From: "'Mark S. Miller' via Google Caja Discuss" <google-caja-discuss@googlegroups.com>
Date: February 2, 2015 at 1:29:23 EST
To: Jordan Last <jordan.michael.last@gmail.com>,  Google Caja Discuss <google-caja-discuss@googlegroups.com>
Subject: Fwd: [Caja] Understanding the difference between Google Caja and Secure ECMAScript (SES), and if SES is ready to use
Reply-To: google-caja-discuss@googlegroups.com

On Fri, Jan 30, 2015 at 5:37 PM, Jordan Last <jordan.michael.last@gmail.com> wrote:
I've been scouring the internet on various occasions for quite a while now trying to figure all of this stuff out. I'm creating a web app where I have users submit JavaScript that they have written to a database, and that JavaScript is then served up and run on the browsers of other users. Obviously the user-submitted JavaScript has the potential to be dangerous. To secure it I run it through Caja, which I know does a lot of fancy stuff including potentially rewriting the code. It is a lot of overhead that I wish could be simpler, but Caja is the best that I've been able to find for me to easily secure my code. I've also heard of SES, and I'm confused. There seems to be no source that explains this well.

Hi Jordan, glad to hear that Caja and SES and useful to you. To give a clearer answer, I'm going to introduce some further terminology and distinctions.

Caja is the package securing both the browser DOM API (together with html and css) as well as JavaScript. The portion dealing with JavaScript has gone through two recent major versions:
  * ES5/3 is a server-side translator from approximately the SES subset of 
     ES5 (EcmaScript 5) to ES3 that was necessary for old browsers.
  * SES is a pure client-side securing of JavaScript that be used on ES5 
     compatible browsers, which now includes all browsers in use today
     except for IE9 (if you care about that).
The portion dealing with the DOM API (together with html and css) is Domado. Domado has been carefully refactored to work with both ES5/3 and SES.

So "old" Caja is ES5/3 + Domado.
"new" Caja is SES + Domado.

If you are interested in running JavaScript in a confined manner, but do not need to give it access to the DOM API or other APIs specific to the browser, then you don't need Domado.

The page at <https://code.google.com/p/google-caja/wiki/SES> documents the differences between SES and ES5.

 
From what I've been able to gather, SES is what is produced after running initSES.js on some JavaScript code?

Yes.


 
Apparently the initSES.js process is much simpler than the Cajoling process, because ES5 strict mode code is much easier to secure.

Yes.

 
So, is there an official version of initSES.js that I can run on ES5 Strict Mode code that will make it completely secure?

After building Caja, you will find an initSES.js in ant-lib/com/google/caja/ses/initSES.js . For reference, I attach the one I just built, but you should endeavor to rebuild it yourself so you can stay up to date.

 
If not completely secure, how secure would it be?

At <https://code.google.com/p/google-caja/wiki/SecurityAdvisories> are all the security advisories for vulnerabilities that we have found and fixed, going back to 2009. In addition, <https://code.google.com/p/google-caja/issues/list?q=label:Security> are all the public open issues in our issue tracker tagged "Security". Of course, we cannot comment on possible undisclosed vulnerabilities, but these are representative of the issues we've had. SES accounts for a minority of these.

The paper at <http://research.google.com/pubs/pub37199.html> formally analyses the security of a subset of SES it calls SES-light.
<https://github.com/brownplt/LambdaS5/tree/master/tests/ses> ran initSES on a formal model of ES5 called LambdaS5, on which they verified that the resulting state had the security properties we claim.

During the entire history of the project, no vulnerability in Caja has ever led to any known actual compromise of any site it has protected.

 
Is anyone using SES code out in the wild? Some clarification would be nice.

Not much. ES7 will introduce a Realm and Loader API, providing more direct support for object-capability security within the JavaScript language. We expect that the direct support and increase in convenience will lead to better adoption.


If the above was confusing, then to put things more simply and to summarize: 

I would like to know if I can run user-submitted ES5 Strict Mode code through initSES.js and produce SES code, without the use of Caja.

Yes, absolutely!

 

Any clarification will be greatly appreciated, thanks!

You are very welcome. Please let us know more about what you're up to if you can. Thanks!
 

--
    Cheers,
    --MarkM

--

---
You received this message because you are subscribed to the Google Groups "Google Caja Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-caja-discuss+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Sunday, January 11, 2015

Fwd: [cap-talk] some capability queries



Sent from my iPhone

Begin forwarded message:

From: Marc Stiegler <marcs@skyhunter.com>
Date: January 9, 2015 at 13:55:29 EST
To: "General discussions concerning capability systems." <cap-talk@mail.eros-os.org>
Subject: Re: [cap-talk] some capability queries
Reply-To: "General discussions concerning capability systems." <cap-talk@mail.eros-os.org>

First, I want to clarify a point that is a little muddy in your initial writeup. You said, "where in the parent ambient
process creates a sandbox and grants it only the authorities (file
descriptors) it needs." This suggests it is a static grant at the beginning of the life of the object in the sandbox. Indeed, the term "sandbox" is used throughout the industry to specify something that is static. A big deal with capabilities is the dynamism of the grants: anyone with access (such as a client of the sandboxed object, as well as the parent) can grant an authority at any time and revoke it (using the caretaker pattern) at any future time. This is very different from conventional sandboxing.

This all becomes most relevant when you as the bigger question that security people tend to pay only lip service to. The big question is not, "How do I secure this object?". You can answer that simple question by just disconnecting the object from the network, as well as sticking it in a traditional sandbox. But this is not an interesting question to answer. The real question is, "how do I achieve secure cooperation?", at which point the achievement of least privilege is crucial: every participant must be allowed the access they need to the other participants, but no more. If you are as fierce about cooperation as you are about security, capabilities enable solutions so much simpler and cheaper, they become effectively the only choice.

Please take a look at "Rich Sharing for the Web", a short HP tech report about 6 key features of secure cooperation that are so routine and mundane in the physical world that we take them for granted, yet almost no application on the web integrates them successfully. You can find the paper at
http://www.hpl.hp.com/techreports/2009/HPL-2009-169.pdf

We have numerous examples of these features being implemented and integrated using capabilities. Take a look at the PubShare video at
https://www.youtube.com/watch?v=LJ8FPM1_uTA

Apps with rich sharing, when built atop a suitable capability-oriented web application framework, can be implemented in a few hundred lines of code.

--marcs

On Thu, Jan 8, 2015 at 10:34 AM, David Barbour <dmbarbour@gmail.com> wrote:
On Wed, Jan 7, 2015 at 9:55 PM, Jithu Joseph <jithu83@gmail.com> wrote:

4. using confinement(2) and controlled interactions(3) among
compartments - what do we really achieve or how are they different
from other access control models?

In my opinion, the biggest advantage of capabilities is this: I can do anything you can express or encode with capabilities. That is, I don't have some external agent saying: "What are you doing, Dave? You can't do that, Dave!" when my code attempts to do something. Instead, if I'm not authorized, I simply will lack the capabilities to express the behavior.

This simplifies my own ability, as an agent or programmer, to reason about what I can do. I don't need to concern myself with a whole class of permissions errors. The whole security apparatus becomes much more subtle and implicit. Meanwhile, I can similarly enforce a useful range of policies on any subprogram or service with which I interact.
 

5. Can we express anything (policies) more / differently using
capability systems than with other systems/ access control models ?

Another big advantages of capabilities: they are very compositional and support a clean separation of concerns between a grant of authority and the application of it. For example, if I'm playing a game, I might want to listen to some game music, so I authorize access to my speakers. But, rather than directly piping some game music over the same network connection, the game service might pass that authority off to some third party service to provide the music - i.e. enabling a composition of services that is difficult to securely express with identity-based access control.

When it comes to composition, capabilities are much more expressive than almost any authority system. And composition is inherently scalable. Modulo the difficulty of revoking capabilities if you didn't have the foresight to provide a revocable capability, capabilities are suitable for security policies in very large systems.


6. There is this really nice concept of delegation ... however in most
of recent systems , I have only seen the confinement / sandboxing of
this. Delegation is mostly between the ambient parent and the sandbox
. Can you point me to some systems which use delegation more
concretely among multi-parties so that i can understand this better.

For examples of delegation between parties, you might check the wikipedia article on OAuth. OAuth uses access tokens for delegation between web services.
 

1. I see that capabilities being used as unforgeable tokens of fine
grained authority. I have seen this  fact being used to reduce ambient
authority in systems like Capsicum, where in the parent ambient
process creates a sandbox and grants it only the authorities (file
descriptors) it needs. I understand this clearly and its value in
reducing the existing ambient authority existing by virtue of  the
global name space.

The other important aspect of capabilities is their explicit selection - e.g. you must choose which file descriptor you're using for a given action. While this seems obvious for the file descriptor use case, there are other security models involving unforgeable tokens of fine-grained authority such as bearer certificates. If we stretched the use case to bearer certificates (and it's quite a stretch) we might instead 'test' whether the given sandbox 'has' the right file descriptors (certificates) to perform some action on a given file.

The property of selecting which token of authority to use for each action is important from a security perspective. It addresses the confused deputy problem.


7. Can capabilities be as expressive as ABAC , which is said to be
used in medical systems [e.g. access to the patient record can be
restricted to specific cardiologists involved in that patient's care
as these doctor's attributes can be included in the ABAC policy of the
record]

Yes. You could either grant a capability to the physicians that need it, or you could model ABAC directly by granting capabilities to each cardiologist that filter views based on their identity.



8. In simple terms what is the advantage of capability systems .

As a policy maker, you can only express security policies you can implement. No illusions. As a user, you can do anything you can express. No permissions errors. As an architect, you can securely compose and mashup multiple services. No artificial constraints.


_______________________________________________
cap-talk mailing list
cap-talk@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/cap-talk


_______________________________________________
cap-talk mailing list
cap-talk@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/cap-talk