Re: gnome-keyring Question about ACL per storage item

[Anders Rundgren <anders rundgren telia com>]

On 2011-10-25 14:57, Elena Reshetova wrote:
> Anders,
> 
> I don't think we have a use case with issuing credentials online from
> providers.
>  It is more than we have a user of a device, which want to decide locally
> what application
> should be able to access them. Use case with a bank application that you
> mentioned
> it absolutely valid, but I don't think we have strong requirements to go
> that side yet.
> We do trust our users or remote configuration of devices (security policy)
> and can control access via
> that means. Personally I do think that your use case and project is very
> interesting, but we just don't
> have such requirements and needs yet.


This is IMO a market issue.
Linux desktop has 1-2% market share.
Security geeks in that lot is at best 20%.
That means that you address < 0.5% of the users.

Linux servers have >50% of the server market and needs a better key-ring
that doesn't require password configuration.

Android has 25% market share and bank apps are coming strong.

But it is free world so if the Linux community prefer leaving the
real stuff to Apple, Microsoft and Google that's their choice, not mine.

I would check with RedHat just to be sure :-)

Anders


> 
> Best Regards,
> Elena.
> 
> On Mon, Oct 24, 2011 at 4:40 PM, Anders Rundgren
> <anders rundgren telia com>wrote:
> 
>> Elena,
>>
>> If you are looking on "my" use-case: providers that issue
>> credentials on-line to non-security savvy consumers, one major
>> hurdle seems to be identifying the application in a generic way.
>>
>> I could think of things like "Firefox" but also "System browser"
>> as well as specific applications such as "com.mybank.payment"
>> using a particular signature certificate.
>>
>> The *other* use-case I find useful would be in servers where you
>> would like to tie a key to a user AND an application.  By
>> doing this we might get away from the gazillion of *configured
>> passwords* that you typically find in an advanced Linux server.
>>
>> Anders
>>
>> On 2011-10-24 12:29, Elena Reshetova wrote:
>>> Hi,
>>>
>>>> Interesting, I'll do more reading about that. But I'm not looking
>>>> forward to the selinux - apparmor - smack debates.
>>>
>>> Nobody is looking forward for such debates, they tend to be long :)
>>> I think it is more like each LSM is welcome
>>>  to add their support to Gnome Keyring in order to make it more secure
>> and
>>> extend the feature set.
>>> Smack can be just the first one to do it.
>>> Moreover, do we actually need to have a tight connection with a
>> particular
>>> LSM?
>>> Can it be done generic enough by having an application identifier field
>>> (even simply as a string)
>>> and then let each LSM enforce its own security context separation based
>> on
>>> this field.
>>> SELinux will enforce it in one way, Smack in other and etc. So, all what
>> I
>>> am saying is that I think
>>> keyring should not worry how applications are identified/isolated and
>> etc.
>>> It can just have means
>>> to enforce ACL on credential items and let OS do the hard job of
>> separating
>>> the apps.
>>>
>>> Best Regards,
>>> Elena.
>>>
>>> On Mon, Oct 24, 2011 at 12:10 PM, Stef Walter <stefw collabora co uk>
>> wrote:
>>>
>>>> On 2011-10-24 10:58, Elena Reshetova wrote:
>>>>> Thank you for the reply and explanations!
>>>>>  I fully agree that making ACL for applications without a reliable way
>>>>> to identify an application
>>>>>  (that maybe a collection of binaries, libraries and etc.) is
>> pointless.
>>>>> However, I think current
>>>>> Linux already have mechanisms in place for doing this. Mainstream LSMs
>>>>> allow you to group
>>>>> applications to separate security contexts and therefore being able to
>>>>> distinguish between
>>>>>  them in a secure and reliable way. We are using Smack as our AC module
>>>>> and group applications
>>>>> in certain AC domains. In a run-time the smack label of a process
>>>>> defines the security context of this
>>>>> process. This is smth you can reply upon. Even if all applications are
>>>>> ruining with user session uid/gids,
>>>>> smack labels can be different and allow you to separate between
>>>>> applications. Also, update case is
>>>>> handled: updated application will get to run in the same domain, and
>>>>> therefore can access to the
>>>>> same set of security credentials/keys and etc.
>>>>
>>>> Interesting, I'll do more reading about that. But I'm not looking
>>>> forward to the selinux - apparmor - smack debates.
>>>>
>>>>> Handing shared libraries and plug-ins is smth really interesting, but
>>>>> can be solved for example
>>>>> via additional checks on mmap (LD_PRELOAD and similar mechanism are
>>>>> still going through
>>>>> the same mmap hook). There are other alternatives to solve a problem of
>>>>> loading untrusted code
>>>>>  to trusted applications, too.
>>>>>
>>>>> Now about the X session. This maybe the only one actual current
>> problem.
>>>>> However, if you run
>>>>> gnome-keyring-daemon with a separate smack label, things may become
>>>> easier.
>>>>> I know that Casey has recently looked inside X server and he might have
>>>>> better suggestions on
>>>>> solving this problem.
>>>>
>>>> Right, not an unsolveable problem, but one that needs a lot of work :)
>>>>
>>>> Cheers,
>>>>
>>>> Stef
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> gnome-keyring-list mailing list
>>> gnome-keyring-list gnome org
>>> http://mail.gnome.org/mailman/listinfo/gnome-keyring-list
>>
>>
>