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