This is the current high-level wish list of improvements that we are
investigating at MSFT. It is still unclear how many and when we'll be able to
implement them.
1. Add new Manifest format, more granular, as I proposed in the attached email.
- Also consider removing the support for the problematic 15.09
Manifest format
2. Add XML-based public methods for Policy, Manifest, Manifest Template.
- Consider removing the current public methods, if they are superseded by the
new methods
3. Add StartManagement + EndManagement methods, called by a Security Manager to
notify the target app that its Security settings are about to change.
4. Add public C APIs corresponding to the most useful public C++ methods.
5. Significant changes to the implementation of the Key Store - to address
ASACORE-2661, ASACORE-2664, and other shortcomings.
6. Make it easier to share a single Key Store between two processes running on
a single machine.
7. Add a new SPEKE auth mechanism - similar but better than the current PSK.
8. Introduce the concept of "Recommended Security Level". For example:
- Manufacturer of an "org.Contoso.GunSafe" device might want to recommend that
interface as accessible just to "Privileged" users
- Manufacturer of an "org.Contoso.WirelessSpeaker" device might want to
recommend that interface as "NonPrivileged"
- Manufacturer of an "org.Contoso.LightSwitch" device might want to recommend
that interface as "Unauthenticated"
9. Investigate the numerous active JIRA tickets related to Security and fix
those that the Core WG decides are important.
If anyone has questions or other kind of feedback, please speak up.
Dan
-----Original Message-----
From: Lioy, Marcello [mailto:[email protected]]
Sent: Thursday, February 4, 2016 11:39 AM
To: [email protected]; [email protected]
Cc: Daniel Mihai <[email protected]>
Subject: RE: [Allseen-core] Security 2.0 status
There are some changes being proposed, however, I think it is developer API
changes rather than the interface definitions on the wire. I have CC'ed Dan
Mihai who is driving the updates to Security 2.0. He can correct or elaborate
as appropriate.
-----Original Message-----
From:
[email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of
[email protected]<mailto:[email protected]>
Sent: Monday, January 25, 2016 2:08 AM
To:
[email protected]<mailto:[email protected]>
Subject: [Allseen-core] Security 2.0 status
Hi everyone,
Is it possible to release the latest 15.09(a)-related Security 2.0 HLD ? As
both the
https://na01.safelinks.protection.outlook.com/?url=allseenalliance.org&data=01%7c01%7cDaniel.Mihai%40microsoft.com%7c1761def47b9b40ff54da08d32d9adcb0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=8t3KSB3ksxrk%2fFOPp7gcPWW%2btMdZsmovppbK0g3%2fwzQ%3d
documentation and wiki seem to point to out-of-date documents.
Also, is the production-grade 16.04 Security 2.0 roadmap decided upon (e.g.
things like interface description servers and like) ?
Thanks,
Ondrej T
_______________________________________________
Allseen-core mailing list
[email protected]<mailto:[email protected]>
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2flists.allseenalliance.org%2fmailman%2flistinfo%2fallseen-core&data=01%7c01%7cDaniel.Mihai%40microsoft.com%7c1761def47b9b40ff54da08d32d9adcb0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=%2fZzxaUmnFC9opwKhE%2bnozXKB04TnGNL3Kxw%2bn3FtYtM%3d
--- Begin Message ---
Based on the email discussion so far, I have a +1 on these two ideas:
1. Standardize the “profile” in the object path, for example:
/profile/AllJoynTV”. Do not need to add another type to the rules. So, no
change to the permission enforcement. The profile definition is in
documentation only. The Security Manager can add restriction to the “profile”
by adding rules based on the object path and interface and method names.
2. Allow peer to send on-demand manifest based on the message. This will
reduce the size of the manifest. However, this will add more complexity to the
code and response time.
Phil
From: [email protected]
[mailto:[email protected]] On Behalf Of Daniel
Mihai
Sent: Monday, November 16, 2015 9:58 AM
To: Dave Thaler; Josh Spain; Gerrit Ruelens (QEO LLC)
Cc: [email protected]
Subject: Re: [Allseen-core] [Security 2.0] Device profiles
Gerrit, thanks for pointing out these problems and for investigating possible
solutions!
I like the idea of defining device Profiles, *but* my current thinking is:
1. Security Manager apps should use such Profiles to provide an
easy-enough UI for the Admins. For example:
a. If the Security Manager notices that a device implements all ~20
interfaces from the TV profile, it can show UI appropriate for managing a TV
device.
b. For devices that don’t fit a known Profile, it would still show the bad
UI you mentioned.
2. Maybe Certification should verify the profile and certify a device as
an “AllJoyn TV” for example.
3. About and Security manifests + policies are complex enough. *I hope we
can avoid adding another layer of complexity to them* (I hope we don’t really
have to make them aware of device Profiles).
4. My understanding is that a remote control Consumer app is currently
forced to pick one of these alternatives:
a. Use separate bus attachments for each type of target Producer
device/profile. This also forces the Admin to setup separate manifests and
policies for each of these bus attachments.
b. Use a single bus attachment – in which case the entire manifest will be
sent to all Producers. Sending to a Light Bulb device a manifest saying that
the Consumer app is allowed to access the Gun Safe device seems like an
unintended information disclosure.
5. I believe that a TV device should implement an interface similar to
org.alljoyn.TV.OnOff. It should never implement org.alljoyn.Oven.OnOff. Both
Security Manager and Consumer apps can use that interface name difference to
distinguish between the two types of devices – without the need to add another
Profile concept.
6. Are there examples of small devices needing large manifests and
policies for the interfaces they implement? As far as I know, the answer is: no.
7. I agree that larger devices/apps, implementing many interfaces, can end
up with large manifests and policies. But they should be able to handle/store
such large information.
What do you think about splitting the current manifests into multiple
mini-manifests, one mini-manifest for each interface? Could apps then send out
just the mini-manifests that are required, instead of sending all of them?
Hopefully even small devices will be able to handle these mini-manifests. This
way we would address the information disclosure problem I mentioned above too.
Thanks,
Dan
From:
[email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of Dave
Thaler
Sent: Friday, November 13, 2015 2:03 PM
To: Josh Spain <[email protected]<mailto:[email protected]>>
Cc:
[email protected]<mailto:[email protected]>
Subject: Re: [Allseen-core] [Security 2.0] Device profiles
Below
From: Josh Spain [mailto:[email protected]]
Sent: Friday, November 13, 2015 1:13 PM
To: Dave Thaler <[email protected]<mailto:[email protected]>>
Cc: Gerrit Ruelens (QEO LLC)
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>;
Lioy, Marcello <[email protected]<mailto:[email protected]>>
Subject: Re: [Allseen-core] [Security 2.0] Device profiles
Dave,
If I understand correctly you're saying that the OnOff interface is
unacceptable. However, if you look at the org.alljoyn.SmartSpaces.Operation
example that Gerrit referenced
(https://git.allseenalliance.org/gerrit/#/c/5125/<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit.allseenalliance.org%2fgerrit%2f%23%2fc%2f5125%2f&data=01%7c01%7cdthaler%40microsoft.com%7c5959639a44ff47a4076c08d2ec6f4217%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3Yz7BfWwF0j6SjZAXVrUBGufU9GZDB4RjAmLxLVN1ME%3d>)
this is exactly what is happening. If this is unacceptable then the entire set
of interfaces needs to be redesigned.
[DT] Well “Unacceptable” is perhaps too strong, since we “accept” legacy
interfaces that have bad design due to compat issues.
But “strongly discouraged “is more what I’m saying. And yes I believe that
OnOff is bad design and a violation of IRB guidelines.
The main issue here is one of usability with Security 2.0. Gerrit's profiles
provide a way to make Security 2.0 more usable by consumers. To me it sounds
similar to how Android treats security. They group a large set of related
concepts together into one permission group (e.g., the SMS permission group
includes send, receive, read, receive WAP push, receive MMS, and read cell
broadcasts permissions). I like the idea and agree it's sorely needed.
[DT] That’s what “interfaces” are for, and what “block of coherent”
functionality means (in my view) in the IRB guidelines.
We had a thread on the IRB mailing list about a month ago on this topic. Gerrit
had brought up the need to indicate when one interface depends upon another.
[DT] I do agree that a “depends” relationship makes sense in two cases that are
in line with the IRB guidelines:
1) You split the mandatory part and optional parts into separate
interfaces, where an optional interface depends on the mandatory interface.
For example, a well-designed lighting interface might have RGB functionality in
an optional interface where lights on/off might be mandatory.
2) A vendor has vendor-specific extensions to a standard interface, and
puts them in an interface with the vendor’s DNS name in the prefix, and the
vendor-specific interface depends on the standard one.
(Note that “OnOff” does not fall into either of the above categories.)
The last opinion on this was Marcello's and I'll quote it here:
In the case of Security (per Gerrit’s example) I believe the right way to
manage that scenario is to group the interfaces correctly in an object
hierarchy (not in the traditional OOO sense of inheritance, but in the
AllJoyn/D-Bus object path sense). So when designing a product with security in
mind one needs to make sure the object hierarchy, and interfaces they expose
are structured properly to allow the security granularity that provides the
appropriate level of usability and security.
[DT] I don’t agree that a “grouping” concept is the right way to handle the
“depends” relationships I mentioned above. Instead I’d recommend an XML
annotation for “dependsOn” some other interface. That annotation can be used
by things like UI so by default it could (for example) choose to not have
separate config for that interface, but duplicate it from the one it depends
on. That’s just a UI concept though, the security policy would still be per
interface as now, which keeps the complexity off the thin client.
Please correct me if I'm misunderstanding, but this suggestion seems to
imply that an end-user would see an object tree on their screen for which they
should decide to accept or deny access. Is that how Sec2 works? If so, this
might be an acceptable alternative to profiles if there were also a way to
annotate each node in the object path tree to be human readable and in a way
that i18n could be applied.
[DT] Hope above helps clarify my opinion.
-Josh
On Fri, Nov 13, 2015 at 12:38 PM, Dave Thaler
<[email protected]<mailto:[email protected]>> wrote:
Offhand, my feeling is that this is going in the wrong direction. Thanks
Gerrit for a nice writeup to help me
understand the issue and be able to articulate now what I don’t like ☺
The approved IRB guidelines say this:
Interface Granularity
An Interface must encapsulate a single, coherent block of information and
functionality.
Do not create everything-and-the-kitchen-sink Interfaces. Split the
functionality and data provided by the Interface into logical, coherent blocks.
This will facilitate reuse of your Interface by others with similar, but not
identical, use cases.
Don't overdo it either: it does not make sense to split every property,
signal and method off into its own separate Interface.
The last sentence above is key. Valid reasons to create a separate
interface are in the guidelines (following the quoted text above), as well as
in the talk I gave at the summit. They include
a) You *want* to ACL them differently because they’re intended for
different roles (admin vs non-admin for instance)
b) One is mandatory to implement and one is optional to implement.
And I’d add for clarity
c) You want to allow enumerating all devices that support a given
concept that means something to a user. This falls into the “coherent”
category of the bolded point quoted above.
From slide 1:
– Some Interfaces are too generic compared offered functionality
• OnOff interface vs TV. Turning on TV is ok, but turning on the oven
not
In my opinion, this is a prime example of “overdoing” it and violates IRB
guidance and should not be done.
An OnOff property fits into none of the (a-c) categories above and hence in
my view is harmful as it leads to unnecessary complexity (as correctly noted on
slide 1) and confusion.
A notion of device profile might make sense for logo/compliance purposes,
but in my opinion should not be encouraged for security 2.0, as it implies (in
my opinion) bad design. I see it as similar to the notion of having
member-granular (as opposed to interface-granular) security policies, which we
also think is a workaround for bad design. That led to the IRB guidance about
interface granularity. Security 2.0 supports member-granular policies not
because they’re a good idea, but because there’s legacy interfaces that need to
be supported even though we’d strongly prefer there be no such need. I claim
the same applies to this case. Furthermore, since this is really about less
granular policy, it’s just an optimization that adds extra complexity and code
footprint, and I’d propose not doing it. That helps provide sufficient
pushback against people “overdoing” it as the IRB guidelines warn against.
Dave
From:
[email protected]<mailto:[email protected]>
[mailto:[email protected]<mailto:[email protected]>]
On Behalf Of Gerrit Ruelens (QEO LLC)
Sent: Friday, November 13, 2015 6:31 AM
To:
[email protected]<mailto:[email protected]>;
Lioy, Marcello <[email protected]<mailto:[email protected]>>
Subject: [Allseen-core] [Security 2.0] Device profiles
Hi All,
We have been discussing interface granularity and how this impacts security
2.0. There are some risks involved and we need to address them.
We like to introduce a concept (Profiles) on top of interfaces. A profile
would for example describe which interfaces an AllJoyn compliant TV must
implement.
More details can be found in the presentation attached.
All feedback is welcome.
Marcello,
Shall we put this on the agenda of one the core conference calls?
Kr,
Gerrit
_______________________________________________
Allseen-core mailing list
[email protected]<mailto:[email protected]>
https://lists.allseenalliance.org/mailman/listinfo/allseen-core<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2flists.allseenalliance.org%2fmailman%2flistinfo%2fallseen-core&data=01%7c01%7cdthaler%40microsoft.com%7c5959639a44ff47a4076c08d2ec6f4217%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=%2bIaR3KhS2PHyX4pk%2bVGPWQLStE%2bykueMYdNRMbltufA%3d>
--- End Message ---
_______________________________________________
Allseen-core mailing list
[email protected]
https://lists.allseenalliance.org/mailman/listinfo/allseen-core
