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

[Sean Middleditch]

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 is going to be necessary that the daemon be aware of SELinux and take
appropriate actions.  If the administrator says,for example, that a
certain context cannot access the company SMB shares, the daemon should
enforce that.

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


>
>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 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! 
>
>
-- 
Sean Middleditch <elanthis at awesomeplay.com>