A common VFS and a Common conf-system [Part II]
alexl at redhat.com
Thu Mar 3 18:52:50 EET 2005
On Thu, 2005-03-03 at 11:18 -0500, Sean Middleditch wrote:
> On Thu, 2005-03-03 at 17:12 +0100, Alexander Larsson wrote:
> >On Thu, 2005-03-03 at 10:04 -0500, Sean Middleditch wrote:
> >> 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.
> This is mostly relevant to local file system access, yes? Where
> authentication isn't even an issue. How does gnome-vfs handle this now?
It handles it by doing all local file system access in the same process
as the app, so any selinux limitations the app has is enforced by the
> I fully admit to being rather ignorant on the SELinux development
> interface, but that sort of behavior is possible, is it not? Would it
> also be possible to make the daemon utilize the client application's
> context for file access (similar to the fsuid in Linux) ?
I know you can pass around selinux contexts. I'm not sure you can do i/o
in a specific context though. I don't really know much about selinux.
Alexander Larsson Red Hat, Inc
alexl at redhat.com alla at lysator.liu.se
He's an immortal guerilla stage actor who hides his scarred face behind a
mask. She's a radical goth safe cracker on her way to prison for a murder she
didn't commit. They fight crime!
More information about the xdg