fuse and selinux don't seem to work well together

fuse and selinux don't seem to work well together

[Xavier Toth]

I'm looking at building a fuse filesystem for polyinstantiated
directories which could be used as a alternative to pam_namespace.
I've noticed that my filesystem is never queried for the xattr
security.selinux and that the file contexts are defaulting to a fuse
file type. I've seen some list posting from 2004 related to this
subject but not much else. Is this a bug or a feature?

Ted

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: fuse and selinux don't seem to work well together

[David P. Quigley]

On Fri, 2010-07-23 at 12:14 -0500, Xavier Toth wrote:
> I'm looking at building a fuse filesystem for polyinstantiated
> directories which could be used as a alternative to pam_namespace.
> I've noticed that my filesystem is never queried for the xattr
> security.selinux and that the file contexts are defaulting to a fuse
> file type. I've seen some list posting from 2004 related to this
> subject but not much else. Is this a bug or a feature?
> 
> Ted
> 
> --
> This message was distributed to subscribers of the selinux mailing list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.

I think the first question here is what is the fs name when you mount a
fuse file system. We have an entry in policy that says fuse is genfscon
fuse / gen_context(system_u:object_r:fusefs_t,s0). If every fuse file
system appears to the kernel to be a fuse fs then you can't add a
genfscon statement to your particular FS telling it to use xattrs. This
might be a use for the native labeling file system code we've been
working on for labeled NFS.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: fuse and selinux don't seem to work well together

[David P. Quigley]

On Fri, 2010-07-23 at 12:14 -0500, Xavier Toth wrote:
> I'm looking at building a fuse filesystem for polyinstantiated
> directories which could be used as a alternative to pam_namespace.
> I've noticed that my filesystem is never queried for the xattr
> security.selinux and that the file contexts are defaulting to a fuse
> file type. I've seen some list posting from 2004 related to this
> subject but not much else. Is this a bug or a feature?
> 
> Ted
> 
> --
> This message was distributed to subscribers of the selinux mailing list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.

Since I'm unclear about the internals of fuse this might be a completely
wrong idea but another thing that could be tried is having mount take
the filesystem name from the fuse mount command (looks like its at the
beginning of the device portion of the fstab entry) and have SELinux
query the policy for that fs name and do labeling based on that. One
issue I can see with this is if fuse shares a single superblock for all
of the fuse mounts inside the kernel and relies on the userspace
component to actually do the separation of the requests this could be a
problem.

Dave


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: fuse and selinux don't seem to work well together

[David P. Quigley]

On Fri, 2010-07-23 at 12:14 -0500, Xavier Toth wrote:
> I'm looking at building a fuse filesystem for polyinstantiated
> directories which could be used as a alternative to pam_namespace.
> I've noticed that my filesystem is never queried for the xattr
> security.selinux and that the file contexts are defaulting to a fuse
> file type. I've seen some list posting from 2004 related to this
> subject but not much else. Is this a bug or a feature?
> 
> Ted
> 
> --
> This message was distributed to subscribers of the selinux mailing list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.

After a brief conversation with Steve more information has come up with
respect to this. A while back Eric Paris had developed a patch to
dynamically probe the file system's getxattr handler to determine if we
can use xattr support on the file system for SELinux labels. The major
stumbling block that Eric ran into was that he was experiencing
deadlocks when using the code. Apparently there were and still might be
locking issues between the fuse and SELinux code. I'm sure you could dig
up Eric's old patch and try to forward port it to see if those locking
issues still exist. 

Dave


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: fuse and selinux don't seem to work well together

[Xavier Toth]

On Fri, Jul 23, 2010 at 1:32 PM, David P. Quigley <dpquigl@tycho.nsa.gov> wrote:
> On Fri, 2010-07-23 at 12:14 -0500, Xavier Toth wrote:
>> I'm looking at building a fuse filesystem for polyinstantiated
>> directories which could be used as a alternative to pam_namespace.
>> I've noticed that my filesystem is never queried for the xattr
>> security.selinux and that the file contexts are defaulting to a fuse
>> file type. I've seen some list posting from 2004 related to this
>> subject but not much else. Is this a bug or a feature?
>>
>> Ted
>>
>> --
>> This message was distributed to subscribers of the selinux mailing list.
>> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
>> the words "unsubscribe selinux" without quotes as the message.
>
> After a brief conversation with Steve more information has come up with
> respect to this. A while back Eric Paris had developed a patch to
> dynamically probe the file system's getxattr handler to determine if we
> can use xattr support on the file system for SELinux labels. The major
> stumbling block that Eric ran into was that he was experiencing
> deadlocks when using the code. Apparently there were and still might be
> locking issues between the fuse and SELinux code. I'm sure you could dig
> up Eric's old patch and try to forward port it to see if those locking
> issues still exist.
>
> Dave
>
>

Thanks I'll try and run down the patch and contact Eric. I'll report
back if I can get this to work.

Ted

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: fuse and selinux don't seem to work well together

[Stephen Smalley]

On Fri, 2010-07-23 at 13:57 -0500, Xavier Toth wrote:
> On Fri, Jul 23, 2010 at 1:32 PM, David P. Quigley <dpquigl@tycho.nsa.gov> wrote:
> > On Fri, 2010-07-23 at 12:14 -0500, Xavier Toth wrote:
> >> I'm looking at building a fuse filesystem for polyinstantiated
> >> directories which could be used as a alternative to pam_namespace.
> >> I've noticed that my filesystem is never queried for the xattr
> >> security.selinux and that the file contexts are defaulting to a fuse
> >> file type. I've seen some list posting from 2004 related to this
> >> subject but not much else. Is this a bug or a feature?
> >>
> >> Ted
> >>
> >> --
> >> This message was distributed to subscribers of the selinux mailing list.
> >> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
> >> the words "unsubscribe selinux" without quotes as the message.
> >
> > After a brief conversation with Steve more information has come up with
> > respect to this. A while back Eric Paris had developed a patch to
> > dynamically probe the file system's getxattr handler to determine if we
> > can use xattr support on the file system for SELinux labels. The major
> > stumbling block that Eric ran into was that he was experiencing
> > deadlocks when using the code. Apparently there were and still might be
> > locking issues between the fuse and SELinux code. I'm sure you could dig
> > up Eric's old patch and try to forward port it to see if those locking
> > issues still exist.
> >
> > Dave
> >
> >
> 
> Thanks I'll try and run down the patch and contact Eric. I'll report
> back if I can get this to work.

Patch was posted here:
http://marc.info/?l=selinux&m=121379719014155&w=2

This bug is relevant:
https://bugzilla.redhat.com/show_bug.cgi?id=493565

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: fuse and selinux don't seem to work well together

[Xavier Toth]

On Fri, Jul 23, 2010 at 3:34 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On Fri, 2010-07-23 at 13:57 -0500, Xavier Toth wrote:
>> On Fri, Jul 23, 2010 at 1:32 PM, David P. Quigley <dpquigl@tycho.nsa.gov> wrote:
>> > On Fri, 2010-07-23 at 12:14 -0500, Xavier Toth wrote:
>> >> I'm looking at building a fuse filesystem for polyinstantiated
>> >> directories which could be used as a alternative to pam_namespace.
>> >> I've noticed that my filesystem is never queried for the xattr
>> >> security.selinux and that the file contexts are defaulting to a fuse
>> >> file type. I've seen some list posting from 2004 related to this
>> >> subject but not much else. Is this a bug or a feature?
>> >>
>> >> Ted
>> >>
>> >> --
>> >> This message was distributed to subscribers of the selinux mailing list.
>> >> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
>> >> the words "unsubscribe selinux" without quotes as the message.
>> >
>> > After a brief conversation with Steve more information has come up with
>> > respect to this. A while back Eric Paris had developed a patch to
>> > dynamically probe the file system's getxattr handler to determine if we
>> > can use xattr support on the file system for SELinux labels. The major
>> > stumbling block that Eric ran into was that he was experiencing
>> > deadlocks when using the code. Apparently there were and still might be
>> > locking issues between the fuse and SELinux code. I'm sure you could dig
>> > up Eric's old patch and try to forward port it to see if those locking
>> > issues still exist.
>> >
>> > Dave
>> >
>> >
>>
>> Thanks I'll try and run down the patch and contact Eric. I'll report
>> back if I can get this to work.
>
> Patch was posted here:
> http://marc.info/?l=selinux&m=121379719014155&w=2
>
> This bug is relevant:
> https://bugzilla.redhat.com/show_bug.cgi?id=493565
>
> --
> Stephen Smalley
> National Security Agency
>
>

I'm testing on FC13 which has equal to or greater than versions of the
packages referenced in the bug report.


For test purposes I patched my policy with:

fs_use_xattr fuse.bbfs gen_context(system_u:object_r:fs_t,s0);

Mount shows:
/home/tedx/Downloads/fuse-tutorial/src/bbfs on /home/tedx/test type
fuse.bbfs (rw,nosuid,nodev,user=tedx)

I'm runnning kernel-debug but I don't see a "SELinux: initialized (dev
" message for the fuse.bbfs type. Shouldn't the fusermount cause one
of these messages to be generated?

I do see fuse attempting to access the system.posix_acl_access and
system.posix_acl_default:
getxattr /Music system.posix_acl_access 0
   unique: 174, error: -61 (No data available), outsize: 16
unique: 175, opcode: GETXATTR (22), nodeid: 36, insize: 73
getxattr /Music system.posix_acl_default 0
   unique: 175, error: -61 (No data available), outsize: 16

So fuse seems to be able to deal with xattrs.

I'm pretty new to all of the pieces and could use a little help with
figuring out where to focus my investigation. Is the fuse mounts
superblock initializing its security structure properly?

Ted

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: fuse and selinux don't seem to work well together

[Eric Paris]

On Sun, Jul 25, 2010 at 11:14 AM, Xavier Toth <txtoth@gmail.com> wrote:
> On Fri, Jul 23, 2010 at 3:34 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>> On Fri, 2010-07-23 at 13:57 -0500, Xavier Toth wrote:
>>> On Fri, Jul 23, 2010 at 1:32 PM, David P. Quigley <dpquigl@tycho.nsa.gov> wrote:
>>> > On Fri, 2010-07-23 at 12:14 -0500, Xavier Toth wrote:
>>> >> I'm looking at building a fuse filesystem for polyinstantiated
>>> >> directories which could be used as a alternative to pam_namespace.
>>> >> I've noticed that my filesystem is never queried for the xattr
>>> >> security.selinux and that the file contexts are defaulting to a fuse
>>> >> file type. I've seen some list posting from 2004 related to this
>>> >> subject but not much else. Is this a bug or a feature?
>>> >>
>>> >> Ted
>>> >>
>>> >> --
>>> >> This message was distributed to subscribers of the selinux mailing list.
>>> >> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
>>> >> the words "unsubscribe selinux" without quotes as the message.
>>> >
>>> > After a brief conversation with Steve more information has come up with
>>> > respect to this. A while back Eric Paris had developed a patch to
>>> > dynamically probe the file system's getxattr handler to determine if we
>>> > can use xattr support on the file system for SELinux labels. The major
>>> > stumbling block that Eric ran into was that he was experiencing
>>> > deadlocks when using the code. Apparently there were and still might be
>>> > locking issues between the fuse and SELinux code. I'm sure you could dig
>>> > up Eric's old patch and try to forward port it to see if those locking
>>> > issues still exist.
>>> >
>>> > Dave
>>> >
>>> >
>>>
>>> Thanks I'll try and run down the patch and contact Eric. I'll report
>>> back if I can get this to work.
>>
>> Patch was posted here:
>> http://marc.info/?l=selinux&m=121379719014155&w=2
>>
>> This bug is relevant:
>> https://bugzilla.redhat.com/show_bug.cgi?id=493565
>>
>> --
>> Stephen Smalley
>> National Security Agency
>>
>>
>
> I'm testing on FC13 which has equal to or greater than versions of the
> packages referenced in the bug report.
>
>
> For test purposes I patched my policy with:
>
> fs_use_xattr fuse.bbfs gen_context(system_u:object_r:fs_t,s0);
>
> Mount shows:
> /home/tedx/Downloads/fuse-tutorial/src/bbfs on /home/tedx/test type
> fuse.bbfs (rw,nosuid,nodev,user=tedx)
>
> I'm runnning kernel-debug but I don't see a "SELinux: initialized (dev
> " message for the fuse.bbfs type. Shouldn't the fusermount cause one
> of these messages to be generated?
>
> I do see fuse attempting to access the system.posix_acl_access and
> system.posix_acl_default:
> getxattr /Music system.posix_acl_access 0
>   unique: 174, error: -61 (No data available), outsize: 16
> unique: 175, opcode: GETXATTR (22), nodeid: 36, insize: 73
> getxattr /Music system.posix_acl_default 0
>   unique: 175, error: -61 (No data available), outsize: 16
>
> So fuse seems to be able to deal with xattrs.
>
> I'm pretty new to all of the pieces and could use a little help with
> figuring out where to focus my investigation. Is the fuse mounts
> superblock initializing its security structure properly?

Fuse can deal with xattrs but only AFTER the fuse userspace program
believes the filesystem is mounted (and if the filesystem can handle
it).  My original patches didn't work, because I was calling getxattr
during the mount(2) syscall.  It gets even worse.  We had a 'bug' in
which the mount(8) program would call stat (or something like that) on
the root inode before it told the fuse userspace program the mount was
finished.  The audit system checked for file capabilities on the stat
call, which resulted in an xattr upcall, which resulted in a deadlock
because the fuse userspace wouldn't answer until the mount finished.
The 'fix' was to stop mount(8) from calling stat on fuse mounts.

The 'right' solution (I think) is going to be 2 parts.  First we need
to get more information in the superblock mounting.  I seem to recall
that the only information we had was that it was 'fuse.'  Not that is
was fuse mounting ntfs.  After that we need to fix the other bug you
pointed out (and other bug I half worked on and you might be able to
find the patch in the archives somewhere)

You cannot put fsuse in modules for a number of reasons today, but the
last problem i never solved was that of holding the genfs context in a
module.  We don't (as I recall) have a method to represent the MLS
portion of a label in a module.  Once that is done (and I think to do
it you actually have to store it as a string and then fix it up at
link time) you can better handle fuse.  I keep telling myself I'm
going to look at this stuff again, but people stopped harassing me in
bugzilla so I never did.....

-Eric


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: fuse and selinux don't seem to work well together

[merlin]

  On 7/25/2010 6:24 PM, Eric Paris wrote:
> On Sun, Jul 25, 2010 at 11:14 AM, Xavier Toth<txtoth@gmail.com>  wrote:
>> On Fri, Jul 23, 2010 at 3:34 PM, Stephen Smalley<sds@tycho.nsa.gov>  wrote:
>>> On Fri, 2010-07-23 at 13:57 -0500, Xavier Toth wrote:
>>>> On Fri, Jul 23, 2010 at 1:32 PM, David P. Quigley<dpquigl@tycho.nsa.gov>  wrote:
>>>>> On Fri, 2010-07-23 at 12:14 -0500, Xavier Toth wrote:
>>>>>> I'm looking at building a fuse filesystem for polyinstantiated
>>>>>> directories which could be used as a alternative to pam_namespace.
>>>>>> I've noticed that my filesystem is never queried for the xattr
>>>>>> security.selinux and that the file contexts are defaulting to a fuse
>>>>>> file type. I've seen some list posting from 2004 related to this
>>>>>> subject but not much else. Is this a bug or a feature?
>>>>>>
>>>>>> Ted
>>>>>>
>>>>>> --
>>>>>> This message was distributed to subscribers of the selinux mailing list.
>>>>>> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
>>>>>> the words "unsubscribe selinux" without quotes as the message.
>>>>> After a brief conversation with Steve more information has come up with
>>>>> respect to this. A while back Eric Paris had developed a patch to
>>>>> dynamically probe the file system's getxattr handler to determine if we
>>>>> can use xattr support on the file system for SELinux labels. The major
>>>>> stumbling block that Eric ran into was that he was experiencing
>>>>> deadlocks when using the code. Apparently there were and still might be
>>>>> locking issues between the fuse and SELinux code. I'm sure you could dig
>>>>> up Eric's old patch and try to forward port it to see if those locking
>>>>> issues still exist.
>>>>>
>>>>> Dave
>>>>>
>>>>>
>>>> Thanks I'll try and run down the patch and contact Eric. I'll report
>>>> back if I can get this to work.
>>> Patch was posted here:
>>> http://marc.info/?l=selinux&m=121379719014155&w=2
>>>
>>> This bug is relevant:
>>> https://bugzilla.redhat.com/show_bug.cgi?id=493565
>>>
>>> --
>>> Stephen Smalley
>>> National Security Agency
>>>
>>>
>> I'm testing on FC13 which has equal to or greater than versions of the
>> packages referenced in the bug report.
>>
>>
>> For test purposes I patched my policy with:
>>
>> fs_use_xattr fuse.bbfs gen_context(system_u:object_r:fs_t,s0);
>>
>> Mount shows:
>> /home/tedx/Downloads/fuse-tutorial/src/bbfs on /home/tedx/test type
>> fuse.bbfs (rw,nosuid,nodev,user=tedx)
>>
>> I'm runnning kernel-debug but I don't see a "SELinux: initialized (dev
>> " message for the fuse.bbfs type. Shouldn't the fusermount cause one
>> of these messages to be generated?
>>
>> I do see fuse attempting to access the system.posix_acl_access and
>> system.posix_acl_default:
>> getxattr /Music system.posix_acl_access 0
>>    unique: 174, error: -61 (No data available), outsize: 16
>> unique: 175, opcode: GETXATTR (22), nodeid: 36, insize: 73
>> getxattr /Music system.posix_acl_default 0
>>    unique: 175, error: -61 (No data available), outsize: 16
>>
>> So fuse seems to be able to deal with xattrs.
>>
>> I'm pretty new to all of the pieces and could use a little help with
>> figuring out where to focus my investigation. Is the fuse mounts
>> superblock initializing its security structure properly?
> Fuse can deal with xattrs but only AFTER the fuse userspace program
> believes the filesystem is mounted (and if the filesystem can handle
> it).  My original patches didn't work, because I was calling getxattr
> during the mount(2) syscall.  It gets even worse.  We had a 'bug' in
> which the mount(8) program would call stat (or something like that) on
> the root inode before it told the fuse userspace program the mount was
> finished.  The audit system checked for file capabilities on the stat
> call, which resulted in an xattr upcall, which resulted in a deadlock
> because the fuse userspace wouldn't answer until the mount finished.
> The 'fix' was to stop mount(8) from calling stat on fuse mounts.
>
> The 'right' solution (I think) is going to be 2 parts.  First we need
> to get more information in the superblock mounting.  I seem to recall
> that the only information we had was that it was 'fuse.'  Not that is
> was fuse mounting ntfs.  After that we need to fix the other bug you
> pointed out (and other bug I half worked on and you might be able to
> find the patch in the archives somewhere)

I agree with you on this part. I was talking with Steve about this on 
Friday and I said it would be a good idea to have fsues statements based 
on the specific fuse file system type. To do this if you detected a fuse 
file system type you'd take the device string and chop off everything up 
until the first # and that would be the specific fuse file system type. 
Steve said there were some other issues with locking between the fuse 
code and the security code so I left it at that and didn't actually look 
into it further.

> You cannot put fsuse in modules for a number of reasons today, but the
> last problem i never solved was that of holding the genfs context in a
> module.  We don't (as I recall) have a method to represent the MLS
> portion of a label in a module.  Once that is done (and I think to do
> it you actually have to store it as a string and then fix it up at
> link time) you can better handle fuse.  I keep telling myself I'm
> going to look at this stuff again, but people stopped harassing me in
> bugzilla so I never did.....
>
> -Eric
>
>
> --
> This message was distributed to subscribers of the selinux mailing list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.
>


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: fuse and selinux don't seem to work well together

[Xavier Toth]

On Sun, Jul 25, 2010 at 10:37 PM, merlin <merlin@countercultured.net> wrote:
>  On 7/25/2010 6:24 PM, Eric Paris wrote:
>>
>> On Sun, Jul 25, 2010 at 11:14 AM, Xavier Toth<txtoth@gmail.com>  wrote:
>>>
>>> On Fri, Jul 23, 2010 at 3:34 PM, Stephen Smalley<sds@tycho.nsa.gov>
>>>  wrote:
>>>>
>>>> On Fri, 2010-07-23 at 13:57 -0500, Xavier Toth wrote:
>>>>>
>>>>> On Fri, Jul 23, 2010 at 1:32 PM, David P.
>>>>> Quigley<dpquigl@tycho.nsa.gov>  wrote:
>>>>>>
>>>>>> On Fri, 2010-07-23 at 12:14 -0500, Xavier Toth wrote:
>>>>>>>
>>>>>>> I'm looking at building a fuse filesystem for polyinstantiated
>>>>>>> directories which could be used as a alternative to pam_namespace.
>>>>>>> I've noticed that my filesystem is never queried for the xattr
>>>>>>> security.selinux and that the file contexts are defaulting to a fuse
>>>>>>> file type. I've seen some list posting from 2004 related to this
>>>>>>> subject but not much else. Is this a bug or a feature?
>>>>>>>
>>>>>>> Ted
>>>>>>>
>>>>>>> --
>>>>>>> This message was distributed to subscribers of the selinux mailing
>>>>>>> list.
>>>>>>> If you no longer wish to subscribe, send mail to
>>>>>>> majordomo@tycho.nsa.gov with
>>>>>>> the words "unsubscribe selinux" without quotes as the message.
>>>>>>
>>>>>> After a brief conversation with Steve more information has come up
>>>>>> with
>>>>>> respect to this. A while back Eric Paris had developed a patch to
>>>>>> dynamically probe the file system's getxattr handler to determine if
>>>>>> we
>>>>>> can use xattr support on the file system for SELinux labels. The major
>>>>>> stumbling block that Eric ran into was that he was experiencing
>>>>>> deadlocks when using the code. Apparently there were and still might
>>>>>> be
>>>>>> locking issues between the fuse and SELinux code. I'm sure you could
>>>>>> dig
>>>>>> up Eric's old patch and try to forward port it to see if those locking
>>>>>> issues still exist.
>>>>>>
>>>>>> Dave
>>>>>>
>>>>>>
>>>>> Thanks I'll try and run down the patch and contact Eric. I'll report
>>>>> back if I can get this to work.
>>>>
>>>> Patch was posted here:
>>>> http://marc.info/?l=selinux&m=121379719014155&w=2
>>>>
>>>> This bug is relevant:
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=493565
>>>>
>>>> --
>>>> Stephen Smalley
>>>> National Security Agency
>>>>
>>>>
>>> I'm testing on FC13 which has equal to or greater than versions of the
>>> packages referenced in the bug report.
>>>
>>>
>>> For test purposes I patched my policy with:
>>>
>>> fs_use_xattr fuse.bbfs gen_context(system_u:object_r:fs_t,s0);
>>>
>>> Mount shows:
>>> /home/tedx/Downloads/fuse-tutorial/src/bbfs on /home/tedx/test type
>>> fuse.bbfs (rw,nosuid,nodev,user=tedx)
>>>
>>> I'm runnning kernel-debug but I don't see a "SELinux: initialized (dev
>>> " message for the fuse.bbfs type. Shouldn't the fusermount cause one
>>> of these messages to be generated?
>>>
>>> I do see fuse attempting to access the system.posix_acl_access and
>>> system.posix_acl_default:
>>> getxattr /Music system.posix_acl_access 0
>>>   unique: 174, error: -61 (No data available), outsize: 16
>>> unique: 175, opcode: GETXATTR (22), nodeid: 36, insize: 73
>>> getxattr /Music system.posix_acl_default 0
>>>   unique: 175, error: -61 (No data available), outsize: 16
>>>
>>> So fuse seems to be able to deal with xattrs.
>>>
>>> I'm pretty new to all of the pieces and could use a little help with
>>> figuring out where to focus my investigation. Is the fuse mounts
>>> superblock initializing its security structure properly?
>>
>> Fuse can deal with xattrs but only AFTER the fuse userspace program
>> believes the filesystem is mounted (and if the filesystem can handle
>> it).  My original patches didn't work, because I was calling getxattr
>> during the mount(2) syscall.  It gets even worse.  We had a 'bug' in
>> which the mount(8) program would call stat (or something like that) on
>> the root inode before it told the fuse userspace program the mount was
>> finished.  The audit system checked for file capabilities on the stat
>> call, which resulted in an xattr upcall, which resulted in a deadlock
>> because the fuse userspace wouldn't answer until the mount finished.
>> The 'fix' was to stop mount(8) from calling stat on fuse mounts.
>>
>> The 'right' solution (I think) is going to be 2 parts.  First we need
>> to get more information in the superblock mounting.  I seem to recall
>> that the only information we had was that it was 'fuse.'  Not that is
>> was fuse mounting ntfs.  After that we need to fix the other bug you
>> pointed out (and other bug I half worked on and you might be able to
>> find the patch in the archives somewhere)
>
> I agree with you on this part. I was talking with Steve about this on Friday
> and I said it would be a good idea to have fsues statements based on the
> specific fuse file system type. To do this if you detected a fuse file
> system type you'd take the device string and chop off everything up until
> the first # and that would be the specific fuse file system type. Steve said

Can you give me an idea of where this happens?


> there were some other issues with locking between the fuse code and the
> security code so I left it at that and didn't actually look into it further.
>
>> You cannot put fsuse in modules for a number of reasons today, but the
>> last problem i never solved was that of holding the genfs context in a
>> module.  We don't (as I recall) have a method to represent the MLS
>> portion of a label in a module.  Once that is done (and I think to do
>> it you actually have to store it as a string and then fix it up at
>> link time) you can better handle fuse.  I keep telling myself I'm
>> going to look at this stuff again, but people stopped harassing me in
>> bugzilla so I never did.....

Which bugzilla should I harass you on ;)?

>>
>> -Eric
>>
>>
>> --
>> This message was distributed to subscribers of the selinux mailing list.
>> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov
>> with
>> the words "unsubscribe selinux" without quotes as the message.
>>
>
>

Ted


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: fuse and selinux don't seem to work well together

[Xavier Toth]

On Mon, Jul 26, 2010 at 8:44 AM, Xavier Toth <txtoth@gmail.com> wrote:
> On Sun, Jul 25, 2010 at 10:37 PM, merlin <merlin@countercultured.net> wrote:
>>  On 7/25/2010 6:24 PM, Eric Paris wrote:
>>>
>>> On Sun, Jul 25, 2010 at 11:14 AM, Xavier Toth<txtoth@gmail.com>  wrote:
>>>>
>>>> On Fri, Jul 23, 2010 at 3:34 PM, Stephen Smalley<sds@tycho.nsa.gov>
>>>>  wrote:
>>>>>
>>>>> On Fri, 2010-07-23 at 13:57 -0500, Xavier Toth wrote:
>>>>>>
>>>>>> On Fri, Jul 23, 2010 at 1:32 PM, David P.
>>>>>> Quigley<dpquigl@tycho.nsa.gov>  wrote:
>>>>>>>
>>>>>>> On Fri, 2010-07-23 at 12:14 -0500, Xavier Toth wrote:
>>>>>>>>
>>>>>>>> I'm looking at building a fuse filesystem for polyinstantiated
>>>>>>>> directories which could be used as a alternative to pam_namespace.
>>>>>>>> I've noticed that my filesystem is never queried for the xattr
>>>>>>>> security.selinux and that the file contexts are defaulting to a fuse
>>>>>>>> file type. I've seen some list posting from 2004 related to this
>>>>>>>> subject but not much else. Is this a bug or a feature?
>>>>>>>>
>>>>>>>> Ted
>>>>>>>>
>>>>>>>> --
>>>>>>>> This message was distributed to subscribers of the selinux mailing
>>>>>>>> list.
>>>>>>>> If you no longer wish to subscribe, send mail to
>>>>>>>> majordomo@tycho.nsa.gov with
>>>>>>>> the words "unsubscribe selinux" without quotes as the message.
>>>>>>>
>>>>>>> After a brief conversation with Steve more information has come up
>>>>>>> with
>>>>>>> respect to this. A while back Eric Paris had developed a patch to
>>>>>>> dynamically probe the file system's getxattr handler to determine if
>>>>>>> we
>>>>>>> can use xattr support on the file system for SELinux labels. The major
>>>>>>> stumbling block that Eric ran into was that he was experiencing
>>>>>>> deadlocks when using the code. Apparently there were and still might
>>>>>>> be
>>>>>>> locking issues between the fuse and SELinux code. I'm sure you could
>>>>>>> dig
>>>>>>> up Eric's old patch and try to forward port it to see if those locking
>>>>>>> issues still exist.
>>>>>>>
>>>>>>> Dave
>>>>>>>
>>>>>>>
>>>>>> Thanks I'll try and run down the patch and contact Eric. I'll report
>>>>>> back if I can get this to work.
>>>>>
>>>>> Patch was posted here:
>>>>> http://marc.info/?l=selinux&m=121379719014155&w=2
>>>>>
>>>>> This bug is relevant:
>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=493565
>>>>>
>>>>> --
>>>>> Stephen Smalley
>>>>> National Security Agency
>>>>>
>>>>>
>>>> I'm testing on FC13 which has equal to or greater than versions of the
>>>> packages referenced in the bug report.
>>>>
>>>>
>>>> For test purposes I patched my policy with:
>>>>
>>>> fs_use_xattr fuse.bbfs gen_context(system_u:object_r:fs_t,s0);
>>>>
>>>> Mount shows:
>>>> /home/tedx/Downloads/fuse-tutorial/src/bbfs on /home/tedx/test type
>>>> fuse.bbfs (rw,nosuid,nodev,user=tedx)
>>>>
>>>> I'm runnning kernel-debug but I don't see a "SELinux: initialized (dev
>>>> " message for the fuse.bbfs type. Shouldn't the fusermount cause one
>>>> of these messages to be generated?
>>>>
>>>> I do see fuse attempting to access the system.posix_acl_access and
>>>> system.posix_acl_default:
>>>> getxattr /Music system.posix_acl_access 0
>>>>   unique: 174, error: -61 (No data available), outsize: 16
>>>> unique: 175, opcode: GETXATTR (22), nodeid: 36, insize: 73
>>>> getxattr /Music system.posix_acl_default 0
>>>>   unique: 175, error: -61 (No data available), outsize: 16
>>>>
>>>> So fuse seems to be able to deal with xattrs.
>>>>
>>>> I'm pretty new to all of the pieces and could use a little help with
>>>> figuring out where to focus my investigation. Is the fuse mounts
>>>> superblock initializing its security structure properly?
>>>
>>> Fuse can deal with xattrs but only AFTER the fuse userspace program
>>> believes the filesystem is mounted (and if the filesystem can handle
>>> it).  My original patches didn't work, because I was calling getxattr
>>> during the mount(2) syscall.  It gets even worse.  We had a 'bug' in
>>> which the mount(8) program would call stat (or something like that) on
>>> the root inode before it told the fuse userspace program the mount was
>>> finished.  The audit system checked for file capabilities on the stat
>>> call, which resulted in an xattr upcall, which resulted in a deadlock
>>> because the fuse userspace wouldn't answer until the mount finished.
>>> The 'fix' was to stop mount(8) from calling stat on fuse mounts.
>>>
>>> The 'right' solution (I think) is going to be 2 parts.  First we need
>>> to get more information in the superblock mounting.  I seem to recall
>>> that the only information we had was that it was 'fuse.'

After looking at this for awhile it seems to me that fuse_get_sb needs
to call security_sb_set_mnt_opts get its superblock security structure
initialized especially for the case when I used the fs_use_xattrs in
policy.


>>> Not that is
>>> was fuse mounting ntfs.  After that we need to fix the other bug you
>>> pointed out (and other bug I half worked on and you might be able to
>>> find the patch in the archives somewhere)
>>
>> I agree with you on this part. I was talking with Steve about this on Friday
>> and I said it would be a good idea to have fsues statements based on the
>> specific fuse file system type. To do this if you detected a fuse file
>> system type you'd take the device string and chop off everything up until
>> the first # and that would be the specific fuse file system type. Steve said
>
> Can you give me an idea of where this happens?
>
>
>> there were some other issues with locking between the fuse code and the
>> security code so I left it at that and didn't actually look into it further.
>>
>>> You cannot put fsuse in modules for a number of reasons today, but the
>>> last problem i never solved was that of holding the genfs context in a
>>> module.  We don't (as I recall) have a method to represent the MLS
>>> portion of a label in a module.  Once that is done (and I think to do
>>> it you actually have to store it as a string and then fix it up at
>>> link time) you can better handle fuse.  I keep telling myself I'm
>>> going to look at this stuff again, but people stopped harassing me in
>>> bugzilla so I never did.....
>
> Which bugzilla should I harass you on ;)?
>
>>>
>>> -Eric
>>>
>>>
>>> --
>>> This message was distributed to subscribers of the selinux mailing list.
>>> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov
>>> with
>>> the words "unsubscribe selinux" without quotes as the message.
>>>
>>
>>
>
> Ted
>


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: fuse and selinux don't seem to work well together

[Eric Paris]

On Mon, 2010-07-26 at 13:13 -0500, Xavier Toth wrote:
> On Mon, Jul 26, 2010 at 8:44 AM, Xavier Toth <txtoth@gmail.com> wrote:
> > On Sun, Jul 25, 2010 at 10:37 PM, merlin <merlin@countercultured.net> wrote:

> >>> Fuse can deal with xattrs but only AFTER the fuse userspace program
> >>> believes the filesystem is mounted (and if the filesystem can handle
> >>> it).  My original patches didn't work, because I was calling getxattr
> >>> during the mount(2) syscall.  It gets even worse.  We had a 'bug' in
> >>> which the mount(8) program would call stat (or something like that) on
> >>> the root inode before it told the fuse userspace program the mount was
> >>> finished.  The audit system checked for file capabilities on the stat
> >>> call, which resulted in an xattr upcall, which resulted in a deadlock
> >>> because the fuse userspace wouldn't answer until the mount finished.
> >>> The 'fix' was to stop mount(8) from calling stat on fuse mounts.
> >>>
> >>> The 'right' solution (I think) is going to be 2 parts.  First we need
> >>> to get more information in the superblock mounting.  I seem to recall
> >>> that the only information we had was that it was 'fuse.'
> 
> After looking at this for awhile it seems to me that fuse_get_sb needs
> to call security_sb_set_mnt_opts get its superblock security structure
> initialized especially for the case when I used the fs_use_xattrs in
> policy.

For most FS (everything but NFS referrals and submounts as I recall)
this is supposed to get called via the

vfs_kern_mount -> security_sb_kern_mount -> selinux_sb_kern_mount ->
superblock_doinit -> selinux_set_mnt_opts

call chain.  If fuse isn't calling security_sb_kern_mount I'd have to
think something is wrong...

-Eric


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: fuse and selinux don't seem to work well together

[David P. Quigley]

Ok so looking through the code briefly this is what happens with respect
to the fstype for fuse. In the user space mount programs for fuse it
handles all of the parsing of the source string to grab the fuse fs type
out of it. It then crafts an FS type fuse.<subname> which is sent to the
kernel. The creation of the daemon to handle the requests is done in
user space and then it calls open on /dev/fuse. This grabs a new file
descriptor which the kernel uses as its communications channel to the
user space library and this FD is passed with the mount command.

Now here is where my understanding gets a little foggy but hopefully it
will help. Looking at the file_system_type structure for the fuse fs
type it has a flag called FS_HAS_SUBTYPE. Looking closely do_kern_mount
does two things to the fs_type string. First it will call get_fs_type
which pulls off the subtype leaving the base type. This is passed into
vfs_kernel_mount to be processed. After it calls vfs_kern_mount it then
checks if fs_flags has FS_HAS_SUBTYPE set and if it does calls
fs_set_subtype. This strips the first part of the name off and sets the
s_subtype field in the superblock. When the name finally arrives at
selinux_set_mnt_opts the file system name is fuse. This gets passed into
security_fs_use at some point to determine the labeling type for the
file system and grabs the entry in the policy db for fuse and uses that.
So having the fuse code call security_set_mnt_opts earlier isn't a good
idea. 

Now if you want to attempt to use the subtype in a fsuse statement we
need to set the subtype before calling vfs_kern_mount. I'm not sure if
this is allowed so something else might have to be done instead. I hope
this clears some things up for you.

Dave


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: fuse and selinux don't seem to work well together

[Xavier Toth]

On Mon, Jul 26, 2010 at 2:22 PM, David P. Quigley <dpquigl@tycho.nsa.gov> wrote:
> Ok so looking through the code briefly this is what happens with respect
> to the fstype for fuse. In the user space mount programs for fuse it
> handles all of the parsing of the source string to grab the fuse fs type
> out of it. It then crafts an FS type fuse.<subname> which is sent to the
> kernel. The creation of the daemon to handle the requests is done in
> user space and then it calls open on /dev/fuse. This grabs a new file
> descriptor which the kernel uses as its communications channel to the
> user space library and this FD is passed with the mount command.
>
> Now here is where my understanding gets a little foggy but hopefully it
> will help. Looking at the file_system_type structure for the fuse fs
> type it has a flag called FS_HAS_SUBTYPE. Looking closely do_kern_mount
> does two things to the fs_type string. First it will call get_fs_type
> which pulls off the subtype leaving the base type. This is passed into
> vfs_kernel_mount to be processed. After it calls vfs_kern_mount it then
> checks if fs_flags has FS_HAS_SUBTYPE set and if it does calls
> fs_set_subtype. This strips the first part of the name off and sets the
> s_subtype field in the superblock. When the name finally arrives at
> selinux_set_mnt_opts the file system name is fuse. This gets passed into
> security_fs_use at some point to determine the labeling type for the
> file system and grabs the entry in the policy db for fuse and uses that.
> So having the fuse code call security_set_mnt_opts earlier isn't a good
> idea.
>
> Now if you want to attempt to use the subtype in a fsuse statement we
> need to set the subtype before calling vfs_kern_mount. I'm not sure if
> this is allowed so something else might have to be done instead. I hope
> this clears some things up for you.
>
> Dave
>
>

If I understand you're saying that the superblock file_system_type
name needs to be type.subtype when it get to selinux_set_mnt_opts for
security_fs_use to find the policy I've configured?

Ted

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: fuse and selinux don't seem to work well together

[David P. Quigley]

On Mon, 2010-07-26 at 15:22 -0500, Xavier Toth wrote:
> On Mon, Jul 26, 2010 at 2:22 PM, David P. Quigley <dpquigl@tycho.nsa.gov> wrote:
> > Ok so looking through the code briefly this is what happens with respect
> > to the fstype for fuse. In the user space mount programs for fuse it
> > handles all of the parsing of the source string to grab the fuse fs type
> > out of it. It then crafts an FS type fuse.<subname> which is sent to the
> > kernel. The creation of the daemon to handle the requests is done in
> > user space and then it calls open on /dev/fuse. This grabs a new file
> > descriptor which the kernel uses as its communications channel to the
> > user space library and this FD is passed with the mount command.
> >
> > Now here is where my understanding gets a little foggy but hopefully it
> > will help. Looking at the file_system_type structure for the fuse fs
> > type it has a flag called FS_HAS_SUBTYPE. Looking closely do_kern_mount
> > does two things to the fs_type string. First it will call get_fs_type
> > which pulls off the subtype leaving the base type. This is passed into
> > vfs_kernel_mount to be processed. After it calls vfs_kern_mount it then
> > checks if fs_flags has FS_HAS_SUBTYPE set and if it does calls
> > fs_set_subtype. This strips the first part of the name off and sets the
> > s_subtype field in the superblock. When the name finally arrives at
> > selinux_set_mnt_opts the file system name is fuse. This gets passed into
> > security_fs_use at some point to determine the labeling type for the
> > file system and grabs the entry in the policy db for fuse and uses that.
> > So having the fuse code call security_set_mnt_opts earlier isn't a good
> > idea.
> >
> > Now if you want to attempt to use the subtype in a fsuse statement we
> > need to set the subtype before calling vfs_kern_mount. I'm not sure if
> > this is allowed so something else might have to be done instead. I hope
> > this clears some things up for you.
> >
> > Dave
> >
> >
> 
> If I understand you're saying that the superblock file_system_type
> name needs to be type.subtype when it get to selinux_set_mnt_opts for
> security_fs_use to find the policy I've configured?
> 
> Ted

That would be true if you wanted to write rules like
fs_use_xattr(fuse.sshfs....) Steve seems to think a better plan is to
take Eric's patch and see if we can resolve the deadlock issues. This
way if you add a file system in the future that uses xattrs you don't
have to add a new entry to the policy. 


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: fuse and selinux don't seem to work well together

[Eric Paris]

On Mon, 2010-07-26 at 16:31 -0400, David P. Quigley wrote:
> On Mon, 2010-07-26 at 15:22 -0500, Xavier Toth wrote:
> > On Mon, Jul 26, 2010 at 2:22 PM, David P. Quigley <dpquigl@tycho.nsa.gov> wrote:
> > > Ok so looking through the code briefly this is what happens with respect
> > > to the fstype for fuse. In the user space mount programs for fuse it
> > > handles all of the parsing of the source string to grab the fuse fs type
> > > out of it. It then crafts an FS type fuse.<subname> which is sent to the
> > > kernel. The creation of the daemon to handle the requests is done in
> > > user space and then it calls open on /dev/fuse. This grabs a new file
> > > descriptor which the kernel uses as its communications channel to the
> > > user space library and this FD is passed with the mount command.
> > >
> > > Now here is where my understanding gets a little foggy but hopefully it
> > > will help. Looking at the file_system_type structure for the fuse fs
> > > type it has a flag called FS_HAS_SUBTYPE. Looking closely do_kern_mount
> > > does two things to the fs_type string. First it will call get_fs_type
> > > which pulls off the subtype leaving the base type. This is passed into
> > > vfs_kernel_mount to be processed. After it calls vfs_kern_mount it then
> > > checks if fs_flags has FS_HAS_SUBTYPE set and if it does calls
> > > fs_set_subtype. This strips the first part of the name off and sets the
> > > s_subtype field in the superblock. When the name finally arrives at
> > > selinux_set_mnt_opts the file system name is fuse. This gets passed into
> > > security_fs_use at some point to determine the labeling type for the
> > > file system and grabs the entry in the policy db for fuse and uses that.
> > > So having the fuse code call security_set_mnt_opts earlier isn't a good
> > > idea.
> > >
> > > Now if you want to attempt to use the subtype in a fsuse statement we
> > > need to set the subtype before calling vfs_kern_mount. I'm not sure if
> > > this is allowed so something else might have to be done instead. I hope
> > > this clears some things up for you.
> > >
> > > Dave
> > >
> > >
> > 
> > If I understand you're saying that the superblock file_system_type
> > name needs to be type.subtype when it get to selinux_set_mnt_opts for
> > security_fs_use to find the policy I've configured?
> > 
> > Ted
> 
> That would be true if you wanted to write rules like
> fs_use_xattr(fuse.sshfs....) Steve seems to think a better plan is to
> take Eric's patch and see if we can resolve the deadlock issues. This
> way if you add a file system in the future that uses xattrs you don't
> have to add a new entry to the policy.

I'm not sure how the deadlock issues can be 'solved.'  The fuse people
have repeatedly stated that until mount(8) (not even mount (2)) is
finished it is illegal to call call getxattr() and they have every right
to deadlock.  They will not budge on this position.

The only possibility I can think of is to extend fuse such that the
support of xattrs is known during mount(2).   No idea what that would
look like.

I believe that my autodetection patch is dead in the water with fuse as
it stands today....

-Eric


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: fuse and selinux don't seem to work well together

[David P. Quigley]

<snip>
> 
> I'm not sure how the deadlock issues can be 'solved.'  The fuse people
> have repeatedly stated that until mount(8) (not even mount (2)) is
> finished it is illegal to call call getxattr() and they have every right
> to deadlock.  They will not budge on this position.
> 
> The only possibility I can think of is to extend fuse such that the
> support of xattrs is known during mount(2).   No idea what that would
> look like.
> 
> I believe that my autodetection patch is dead in the water with fuse as
> it stands today....
> 
> -Eric

So where is this dead locking occuring? The only thing kernel side that
I can think might deadlock is mount will probably lock the new super
block for writing (although it shouldn't be available yet so maybe not)
and when we call vfs_getxattr on the mount point it might need to grab a
lock on the sb for something. I don't think this is the case since I
looked through the code from vfs_getxattr through the fuse getxattr
handler and I don't see any locking in there for the SB. I'm more
inclined to believe that it is the userspace code for fuse or the
interface they use to send the requests to user space. Actually the
latter sounds more reasonable since fuse_send_request places the request
in a queue. So if we are waiting on mount to finish before we send the
getxattr request but mount depends on the getxattr request we can have a
problem. Maybe the mount request can be modified to make a nested
getxattr call on the file system to find out of it is supported and if
it is add something to indicate xattr support?

Dave


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: fuse and selinux don't seem to work well together

[Eric Paris]

On Mon, 2010-07-26 at 17:40 -0400, David P. Quigley wrote:
> <snip>
> > 
> > I'm not sure how the deadlock issues can be 'solved.'  The fuse people
> > have repeatedly stated that until mount(8) (not even mount (2)) is
> > finished it is illegal to call call getxattr() and they have every right
> > to deadlock.  They will not budge on this position.
> > 
> > The only possibility I can think of is to extend fuse such that the
> > support of xattrs is known during mount(2).   No idea what that would
> > look like.
> > 
> > I believe that my autodetection patch is dead in the water with fuse as
> > it stands today....
> > 
> > -Eric
> 
> So where is this dead locking occuring? The only thing kernel side that
> I can think might deadlock is mount will probably lock the new super
> block for writing (although it shouldn't be available yet so maybe not)
> and when we call vfs_getxattr on the mount point it might need to grab a
> lock on the sb for something. I don't think this is the case since I
> looked through the code from vfs_getxattr through the fuse getxattr
> handler and I don't see any locking in there for the SB. I'm more
> inclined to believe that it is the userspace code for fuse or the
> interface they use to send the requests to user space. Actually the
> latter sounds more reasonable since fuse_send_request places the request
> in a queue. So if we are waiting on mount to finish before we send the
> getxattr request but mount depends on the getxattr request we can have a
> problem. Maybe the mount request can be modified to make a nested
> getxattr call on the file system to find out of it is supported and if
> it is add something to indicate xattr support?

It's not an in kernel deadlock.  fuse userspace refuses to respond to
anything until mount(8) is finished.  So if mount(8) at any point (even
during mount(2)) is waiting on the fuse userspace to respond you are
just stuck.

-Eric


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: fuse and selinux don't seem to work well together

[Stephen Smalley]

On Mon, 2010-07-26 at 21:12 -0400, Eric Paris wrote:
> On Mon, 2010-07-26 at 17:40 -0400, David P. Quigley wrote:
> > <snip>
> > > 
> > > I'm not sure how the deadlock issues can be 'solved.'  The fuse people
> > > have repeatedly stated that until mount(8) (not even mount (2)) is
> > > finished it is illegal to call call getxattr() and they have every right
> > > to deadlock.  They will not budge on this position.
> > > 
> > > The only possibility I can think of is to extend fuse such that the
> > > support of xattrs is known during mount(2).   No idea what that would
> > > look like.
> > > 
> > > I believe that my autodetection patch is dead in the water with fuse as
> > > it stands today....
> > > 
> > > -Eric
> > 
> > So where is this dead locking occuring? The only thing kernel side that
> > I can think might deadlock is mount will probably lock the new super
> > block for writing (although it shouldn't be available yet so maybe not)
> > and when we call vfs_getxattr on the mount point it might need to grab a
> > lock on the sb for something. I don't think this is the case since I
> > looked through the code from vfs_getxattr through the fuse getxattr
> > handler and I don't see any locking in there for the SB. I'm more
> > inclined to believe that it is the userspace code for fuse or the
> > interface they use to send the requests to user space. Actually the
> > latter sounds more reasonable since fuse_send_request places the request
> > in a queue. So if we are waiting on mount to finish before we send the
> > getxattr request but mount depends on the getxattr request we can have a
> > problem. Maybe the mount request can be modified to make a nested
> > getxattr call on the file system to find out of it is supported and if
> > it is add something to indicate xattr support?
> 
> It's not an in kernel deadlock.  fuse userspace refuses to respond to
> anything until mount(8) is finished.  So if mount(8) at any point (even
> during mount(2)) is waiting on the fuse userspace to respond you are
> just stuck.

Then we can't support labeling with fuse filesystems.  Regardless of
whether you pass down the sub-fstype information.  Because to support
fs_use_xattr behavior, we have to be allowed to invoke ->getxattr on the
root inode as part of mount(2) so that we can set up the root inode's
security information before it is grafted into the namespace and
accessible to userspace.  That already happens for any fs_use_xattr
filesystem type; sb_finish_set_opts() first probes ->getxattr to make
sure that the fs truly supports security.selinux and later calls
inode_doinit* on the root inode and on any other inodes set up during
get_sb.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: fuse and selinux don't seem to work well together

[Xavier Toth]

Pursuant to Steve's wishes to not require policy changes for new fuse
filesystems that support xattrs:

On Sun, Jul 25, 2010 at 5:24 PM, Eric Paris <eparis@parisplace.org> wrote:
> On Sun, Jul 25, 2010 at 11:14 AM, Xavier Toth <txtoth@gmail.com> wrote:
>> On Fri, Jul 23, 2010 at 3:34 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>>> On Fri, 2010-07-23 at 13:57 -0500, Xavier Toth wrote:
>>>> On Fri, Jul 23, 2010 at 1:32 PM, David P. Quigley <dpquigl@tycho.nsa.gov> wrote:
>>>> > On Fri, 2010-07-23 at 12:14 -0500, Xavier Toth wrote:
>>>> >> I'm looking at building a fuse filesystem for polyinstantiated
>>>> >> directories which could be used as a alternative to pam_namespace.
>>>> >> I've noticed that my filesystem is never queried for the xattr
>>>> >> security.selinux and that the file contexts are defaulting to a fuse
>>>> >> file type. I've seen some list posting from 2004 related to this
>>>> >> subject but not much else. Is this a bug or a feature?
>>>> >>
>>>> >> Ted
>>>> >>
>>>> >> --
>>>> >> This message was distributed to subscribers of the selinux mailing list.
>>>> >> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
>>>> >> the words "unsubscribe selinux" without quotes as the message.
>>>> >
>>>> > After a brief conversation with Steve more information has come up with
>>>> > respect to this. A while back Eric Paris had developed a patch to
>>>> > dynamically probe the file system's getxattr handler to determine if we
>>>> > can use xattr support on the file system for SELinux labels. The major
>>>> > stumbling block that Eric ran into was that he was experiencing
>>>> > deadlocks when using the code. Apparently there were and still might be
>>>> > locking issues between the fuse and SELinux code. I'm sure you could dig
>>>> > up Eric's old patch and try to forward port it to see if those locking
>>>> > issues still exist.
>>>> >
>>>> > Dave
>>>> >
>>>> >
>>>>
>>>> Thanks I'll try and run down the patch and contact Eric. I'll report
>>>> back if I can get this to work.
>>>
>>> Patch was posted here:
>>> http://marc.info/?l=selinux&m=121379719014155&w=2
>>>
>>> This bug is relevant:
>>> https://bugzilla.redhat.com/show_bug.cgi?id=493565
>>>
>>> --
>>> Stephen Smalley
>>> National Security Agency
>>>
>>>
>>
>> I'm testing on FC13 which has equal to or greater than versions of the
>> packages referenced in the bug report.
>>
>>
>> For test purposes I patched my policy with:
>>
>> fs_use_xattr fuse.bbfs gen_context(system_u:object_r:fs_t,s0);
>>
>> Mount shows:
>> /home/tedx/Downloads/fuse-tutorial/src/bbfs on /home/tedx/test type
>> fuse.bbfs (rw,nosuid,nodev,user=tedx)
>>
>> I'm runnning kernel-debug but I don't see a "SELinux: initialized (dev
>> " message for the fuse.bbfs type. Shouldn't the fusermount cause one
>> of these messages to be generated?
>>
>> I do see fuse attempting to access the system.posix_acl_access and
>> system.posix_acl_default:
>> getxattr /Music system.posix_acl_access 0
>>   unique: 174, error: -61 (No data available), outsize: 16
>> unique: 175, opcode: GETXATTR (22), nodeid: 36, insize: 73
>> getxattr /Music system.posix_acl_default 0
>>   unique: 175, error: -61 (No data available), outsize: 16
>>
>> So fuse seems to be able to deal with xattrs.
>>
>> I'm pretty new to all of the pieces and could use a little help with
>> figuring out where to focus my investigation. Is the fuse mounts
>> superblock initializing its security structure properly?
>
> Fuse can deal with xattrs but only AFTER the fuse userspace program
> believes the filesystem is mounted (and if the filesystem can handle
> it).  My original patches didn't work, because I was calling getxattr
> during the mount(2) syscall.  It gets even worse.  We had a 'bug' in
> which the mount(8) program would call stat (or something like that) on
> the root inode before it told the fuse userspace program the mount was
> finished.  The audit system checked for file capabilities on the stat
> call, which resulted in an xattr upcall, which resulted in a deadlock
> because the fuse userspace wouldn't answer until the mount finished.
> The 'fix' was to stop mount(8) from calling stat on fuse mounts.

So is this past tense, there was a bug in mount(8) that has been addressed?

>
> The 'right' solution (I think) is going to be 2 parts.  First we need
> to get more information in the superblock mounting.  I seem to recall
> that the only information we had was that it was 'fuse.'  Not that is
> was fuse mounting ntfs.

It appear that the superblock contains s_type->name and s_subtype
which should tell you that it is for example an fuse.ntfs mount.

> After that we need to fix the other bug you
> pointed out (and other bug I half worked on and you might be able to
> find the patch in the archives somewhere)

Sorry I'm not sure which bug you are referring to?
http://marc.info/?l=selinux&m=121379719014155&w=2 appears to be your
patch which I will look into applying.

>
> You cannot put fsuse in modules for a number of reasons today, but the
> last problem i never solved was that of holding the genfs context in a
> module.  We don't (as I recall) have a method to represent the MLS
> portion of a label in a module.  Once that is done (and I think to do
> it you actually have to store it as a string and then fix it up at
> link time) you can better handle fuse.  I keep telling myself I'm
> going to look at this stuff again, but people stopped harassing me in
> bugzilla so I never did.....
>
> -Eric
>

Ted


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: fuse and selinux don't seem to work well together

[David P. Quigley]

On Mon, 2010-07-26 at 16:15 -0500, Xavier Toth wrote:
> Pursuant to Steve's wishes to not require policy changes for new fuse
> filesystems that support xattrs:
> 
<Snip>
> >
> > The 'right' solution (I think) is going to be 2 parts.  First we need
> > to get more information in the superblock mounting.  I seem to recall
> > that the only information we had was that it was 'fuse.'  Not that is
> > was fuse mounting ntfs.
> 
> It appear that the superblock contains s_type->name and s_subtype
> which should tell you that it is for example an fuse.ntfs mount.

The is true but as my earlier email mentioned s_subtype isn't set when
we need it to be. This is set after the vfs_do_kern_mnt call (or whateve
it was called). get_fs_type will grab fuse from fuse.ntfs and
get_fs_subtype will grab the ntfs portion of the fstype.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: fuse and selinux don't seem to work well together

[Eric Paris]

On Mon, 2010-07-26 at 16:15 -0500, Xavier Toth wrote:

> > Fuse can deal with xattrs but only AFTER the fuse userspace program
> > believes the filesystem is mounted (and if the filesystem can handle
> > it).  My original patches didn't work, because I was calling getxattr
> > during the mount(2) syscall.  It gets even worse.  We had a 'bug' in
> > which the mount(8) program would call stat (or something like that) on
> > the root inode before it told the fuse userspace program the mount was
> > finished.  The audit system checked for file capabilities on the stat
> > call, which resulted in an xattr upcall, which resulted in a deadlock
> > because the fuse userspace wouldn't answer until the mount finished.
> > The 'fix' was to stop mount(8) from calling stat on fuse mounts.
> 
> So is this past tense, there was a bug in mount(8) that has been addressed?

That's correct.  mount(8) now has a --no-canonicalize option which fuse
uses to make it not call stat before it completes to avoid the deadlock.

> > The 'right' solution (I think) is going to be 2 parts.  First we need
> > to get more information in the superblock mounting.  I seem to recall
> > that the only information we had was that it was 'fuse.'  Not that is
> > was fuse mounting ntfs.
> 
> It appear that the superblock contains s_type->name and s_subtype
> which should tell you that it is for example an fuse.ntfs mount.
> 
> > After that we need to fix the other bug you
> > pointed out (and other bug I half worked on and you might be able to
> > find the patch in the archives somewhere)
> 
> Sorry I'm not sure which bug you are referring to?
> http://marc.info/?l=selinux&m=121379719014155&w=2 appears to be your
> patch which I will look into applying.

I was thinkin of these:
http://www.nsa.gov/research/selinux/list-archive/0805/26041.shtml

genfscon is not allowed in modules.  I stop looking when I realized that
those don't really handle the mls portion of the label correctly...


So sds wants to autodetect xattr support.  that sounds great, but I
think is a large project that will require redesigning fuse.

I am suggesting a smaller interim solution that consists of 2 steps.

1) get all the information about the name you need into the kernel in
the right place.  aka s_type->name and s_subtype in the right hook.  I
think David indicated that is going to take some kernel reworking to get
s_subtype set at the appropriate time.

2) add support to the policy to support filesystem labeling rules in
modules.  I believe this is going to require the changes I was talking
about in the above link.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: fuse and selinux don't seem to work well together

[David P. Quigley]

On Mon, 2010-07-26 at 17:35 -0400, Eric Paris wrote:
> On Mon, 2010-07-26 at 16:15 -0500, Xavier Toth wrote:
> 
> > > Fuse can deal with xattrs but only AFTER the fuse userspace program
> > > believes the filesystem is mounted (and if the filesystem can handle
> > > it).  My original patches didn't work, because I was calling getxattr
> > > during the mount(2) syscall.  It gets even worse.  We had a 'bug' in
> > > which the mount(8) program would call stat (or something like that) on
> > > the root inode before it told the fuse userspace program the mount was
> > > finished.  The audit system checked for file capabilities on the stat
> > > call, which resulted in an xattr upcall, which resulted in a deadlock
> > > because the fuse userspace wouldn't answer until the mount finished.
> > > The 'fix' was to stop mount(8) from calling stat on fuse mounts.
> > 
> > So is this past tense, there was a bug in mount(8) that has been addressed?
> 
> That's correct.  mount(8) now has a --no-canonicalize option which fuse
> uses to make it not call stat before it completes to avoid the deadlock.
> 
> > > The 'right' solution (I think) is going to be 2 parts.  First we need
> > > to get more information in the superblock mounting.  I seem to recall
> > > that the only information we had was that it was 'fuse.'  Not that is
> > > was fuse mounting ntfs.
> > 
> > It appear that the superblock contains s_type->name and s_subtype
> > which should tell you that it is for example an fuse.ntfs mount.
> > 
> > > After that we need to fix the other bug you
> > > pointed out (and other bug I half worked on and you might be able to
> > > find the patch in the archives somewhere)
> > 
> > Sorry I'm not sure which bug you are referring to?
> > http://marc.info/?l=selinux&m=121379719014155&w=2 appears to be your
> > patch which I will look into applying.
> 
> I was thinkin of these:
> http://www.nsa.gov/research/selinux/list-archive/0805/26041.shtml
> 
> genfscon is not allowed in modules.  I stop looking when I realized that
> those don't really handle the mls portion of the label correctly...
> 
> 
> So sds wants to autodetect xattr support.  that sounds great, but I
> think is a large project that will require redesigning fuse.
> 
> I am suggesting a smaller interim solution that consists of 2 steps.
> 
> 1) get all the information about the name you need into the kernel in
> the right place.  aka s_type->name and s_subtype in the right hook.  I
> think David indicated that is going to take some kernel reworking to get
> s_subtype set at the appropriate time.
> 
> 2) add support to the policy to support filesystem labeling rules in
> modules.  I believe this is going to require the changes I was talking
> about in the above link.

If we go this route I think a new sub command for semanage would be a
good thing to have. This way you could change them on the fly if
necessary (although I'm not sure there is a use case for this). I think
it might be a good idea to bring the fuse guys back in on this
especially if we will be tinkering in their world.

Dave


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.