Re: gnome-keyring Question about ACL per storage item
- From: Elena Reshetova <elena reshetova gmail com>
- To: Stef Walter <stefw collabora co uk>
- Cc: Casey Schaufler <casey schaufler-ca com>, gnome-keyring-list gnome org
- Subject: Re: gnome-keyring Question about ACL per storage item
- Date: Mon, 24 Oct 2011 13:29:05 +0300
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]