From: William Roberts [mailto:bill.c.roberts@xxxxxxxxx]
Sent: Friday, July 10, 2015 8:10 AM
To: Stephen Smalley
Cc: seandroid-list@xxxxxxxxxxxxx; selinux@xxxxxxxxxxxxx; Roberts, William C
Subject: Re: executing off of a fusefs
On Jul 10, 2015 5:48 AM, "Stephen Smalley" <sds@xxxxxxxxxxxxx> wrote:
>
> On 07/09/2015 07:04 PM, Roberts, William C wrote:
> > I have this problem on Android, but it’s SELinux general. I’d like to
> > get some info from those in the know.
> >
> > If you wanted to be able to execute files off of fuse and have the
> > kernel handle the transition, would it be as simple as having the file
> > system return the getxattr call for the security label?
>
> Aren't fuse mounts mounted with nosuid? That disables SELinux context
> transitions as well as suid/sgid/file-capabilities. Otherwise, the
> kernel is trusting the userspace filesystem to not cause a privilege
> escalation, potentially in excess of the privileges of the userspace
> filesystem daemon itself.
On AOSP yes others no. BTW I'm not condoning doing this either.
>
> Aside from that, you would also need to configure SELinux to use xattrs
> from fuse (i.e. fs_use_xattr fuse ...), and change the daemon to support
> getxattr, and ensure that you do not have the deadlock problem that
> exists with upstream FUSE where it
This old problem, I think if you don't use libfuse you can get around it.
Also, I see the manpage for mount has rootcontext, does this provide the
rootnode context so the xattr won’t be queried, or does it provide some transient
label that is replaced at mount with the xattr query?
does not support handling a getxattr
> request on the root directory during the mount(2) call. And doing this
> would affect all fuse mounts (e.g. /storage/emulated), not just a
> specific one. There was an attempt to add per-subtype support for
> fs_use so that one could specify a different labeling behavior for a
> specific kind of fuse filesystem, see kernel commit
> 102aefdda4d8275ce7d7100bc16c88c74272b260, but this was reverted in
> 4d546f81717d253ab67643bf072c6d8821a9249c and
> 29b1deb2a48a9dd02b93597aa4c055a24c0e989f as it did not work and caused a
> deadlock for other fuse filesystems.
>
>
>
>
>
>
>
> _______________________________________________
> Selinux mailing list
> Selinux@xxxxxxxxxxxxx
> To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
> To get help, send an email containing "help" to
Selinux-request@xxxxxxxxxxxxx.
