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
>>
>
>
>
