[Authentication] Spec review (part 1)

[Stef Walter]

On 2010-09-18 11:24, Michael Leupold wrote:
> Hi Eckhart,
> 
> sorry for taking a while to review your ideas. Life has been busy for
> me during the last two weeks.
> 
> 2010/9/9 Eckhart Wörner <ewoerner at kde.org>:
>> 1) I talked to the D-Bus people and we agreed on that there's no use for
>> encryption on D-Bus at all. As soon as you've the possibility to eavesdrop the
>> D-Bus communication, you're also able to do a man-in-the-middle attack.
>> My proposal here is to get rid of encryption completely. This makes
>> implementation of client libraries much easier.
> 
> I've thought about it again. I'm not sure a man-in-the-middle attack
> is actually possible. Of course our applications don't carry
> certificates or similar to authenticate to each other, but talking
> over D-Bus at least the service can check who the client is using its
> pid. As I understand it a possible attacker who successfully manages
> to convince the client that he's the real service would afterwards
> still have to convince the service that he's the actual client. This
> can be avoided using ACLs (the same the service would implement to
> only allow trusted applications to access its secrets).

That may be the case. But I don't think we should make any promises
about this just yet. The user's linux desktop session just isn't
designed for security between applications (yet?).

But to summarize, the session negotiation is:

 * Currently useful to keep passwords out of the page file and
   other caches.
 * In the future, would work well with a 'hardened' linux desktop
   without changing the specification.

> The other direction might be simpler to attack unless the client uses
> the service's pid to check if it's really the service. We should
> probably think about whether this should be implemented as well.

In the current linux desktop this doesn't buy us much. Even if we lookup
the pid, and then the application binary, and try to only talk to a
single binary (and have no interop), then there's stuff like LD_PRELOAD
which just takes us away.

To accomplish this goal I think someone needs to spend time on
integrating things like SELinux or AppArmor and running the service
daemon in a different security context.

Certainly possible and the API is flexible enough to accommodate this
once implemented.

> I think session encryption provides additional security and thus don't
> want to get rid of it.

I agree. Both now and in the future. But, as mentioned in the spec, it's
optional for clients to implement encryption.

>> 2) On the other hand, encryption introduces a lot of ugliness. Secrets are put
>> on the bus as byte arrays, at the moment it isn't even specified how
>> (decrypted) byte arrays translate to strings afterwards. Getting rid of
>> encryption allows to use the D-Bus type system. Two possibilities:
>> a) secrets are D-Bus variants ("v")
>> b) overloading for several common types (like "s", "ay" and "a{ss}")
> 
> I agree that this is a bit of a mess and an oversight on my part. I
> think we should specify how those secrets are encoded. I see two ways:
> 
> 1. Add an extra property to detail how the secret of an item is
> encoded. Possible values and encodings have to be specified.
> 
> 2. Specify that the decrypted secret IS a D-Bus variant.

So this would be like a 'content-type' sort of property on the secret?

>> 3) Since the spec says that items can be locked / unlocked individually, a
>> "Locked" property for the collection makes no sense.
> 
> We talked about this and I'm actually not really sure about what this
> means either.
> 
> @Stef: Was this supposed to mean that all items in the collection are
> unlocked or that the collection itself is ready for change (adding
> items/changing properties)? How did you implement it?

You're right. I implemented it so that when all the items are unlocked,
the collection becomes unlocked. But I can see why it might be confusing.

We specifically want the spec to treat items on their own as far as
locking and unlocking, even if the daemon unlocks everything in a
collection as a side effect of unlocking one item.

This is because in the future when we have support for identifying
applications securely (see above about security contexts), then we can
unlock certain items for certain apps. Apps that don't have access to an
item, would see it as locked, while another app can see that same item
as unlocked.

>> 5) Unlocking of the secret storage might take some time without ever creating
>> a prompt (e.g. hardware needed takes some time to initialize, etc). I suggest
>> to rename Prompt to Job.
> 
> I don't think renaming it is worth it, even if it might make sense
> semantically. After all there's already software out there which uses
> the spec.

Out of interest, how many implementations are there that you know of?

Cheers,

Stef