A common VFS and a Common conf-system [Part II]

Alexander Larsson alexl at redhat.com
Thu Mar 3 18:12:35 EET 2005

On Thu, 2005-03-03 at 10:04 -0500, Sean Middleditch wrote:
> On Thu, 2005-03-03 at 15:57 +0100, Alexander Larsson wrote:
> >On Thu, 2005-03-03 at 09:03 -0500, Sean Middleditch wrote:
> >> 
> >> I would argue then that the daemon can forward the information about
> >> the process to the keyring, or that they keyring can tie in better to
> >> the daemon.  My plan was to make the daemon talk to an external helper
> >> over D-BUS (or a more direct protocol if necessary for security -
> >> haven't looked at that in depth yet), so gnome could provide such a
> >> helper that used the keyring.  Making sure that the actual
> >> applications never touch the authentication information is something
> >> I'm rather keen on - it really can eliminate an entire class of
> >> security holes and information leaks.
> >
> >There are things you can't easily forward though, such as a selinux
> >contexts. 
> I really do think that, in the case of the VFS, it is better to not be
> tied down to the existing keyring implementation.  Again, quite frankly,
> having the application communicate the authentication information
> directly is a pretty bad idea.  Rather defeats the whole purpose of even
> using SELinux, which is in a large part about controlling data
> flow.  ;-)

This is not related to gnome-keyring design though. The selinux context
is a piece of data related to the original application managed by the
kernel. If all i/o of all processes go through a common daemon, then you
can't have different selinux context for the i/o of different apps.
Essentially all apps get the same security context for i/o, and you've
made selinux useless.

 Alexander Larsson                                            Red Hat, Inc 
                   alexl at redhat.com    alla at lysator.liu.se 
He's a scarfaced native American messiah with no name. She's a virginal 
hip-hop doctor from a secret island of warrior women. They fight crime! 

More information about the xdg mailing list