Re: gnome-keyring Question about ACL per storage item

[Anders Rundgren <anders rundgren telia com>]

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