On Fri, Jan 2, 2015 at 11:47 AM, Stephen Smalley <[email protected]> wrote:
> A couple of points: > - Don't conflate use of fuse with sdcard daemon (mainline Android) > with use of sdcardfs (seems to be a kernel-resident filesystem based > on wrapfs from the stackable filesystems work, appearing at least in > some Samsung devices, see fs/sdcardfs in Samsung kernel trees). > No thats not what I meant...I mean the sdcard daemon and its fuse fs. I just needed a name to call the FUSE one, and I guess I picked a conflicting name. I am well aware of Samsungs sdcardfs kernel implementation, aparently fuse is too slow. I ll refer to it as sdcard daemon now, to avoid this confusion. > - For fuse and the sdcard daemon, yes, we can either use getpidcon() > in the sdcard daemon and leave fuse unchanged or extend the fuse > kernel api to pass up the process context directly or offer it up via > another call. That's for identifying the subject. > The problem here is sending that data. FUSE is going to access the data from the cred structure, which on older kernels is the union of lsm specific pointers or a void * (finally). However, fuse needs to pass something up, and obviously we cant send any pointers, and enything in the pointed too memory block is LSM specific. So we could add an lsm function for converting the data to something passable to userspace. the fuse header that carries uid, pid, gid, has 32 bytes of padding to allign a 32 bit userspace to work with a 64 bit kernel, we could use this to pass whatever we want. I figured for SELInux sid makes sense since the userspace code eventially distills the string context into an sid before checking the permission. > > - For fuse and xattr support, there is a longstanding problem with a > deadlock between at least some fuse filesystems and SELinux when using > fs_use_xattr. The issue is that SELinux requests the security.selinux > xattr for the root directory inode during mount(), and common FUSE > filesystems will deadlock if they get a request on a file within the > filesystem during the mount operation. See fuse discussions on > selinux list. Don't know for sure if that's an issue with the sdcard > daemon. If not or if that can be easily resolved (permit incoming > requests on other threads while the mount is still being processed), > then the next obvious question is how does the sdcard daemon obtain or > synthesize the attribute values, particularly when the underlying > storage is a real SDcard with a vfat filesystem. > If the deadlock issue is in userspace, then we should be able to handle it sdcard daemon. Currently permissions in sdcard daemon are handled by kind of hardcoded map, this path is associated with this app, or this path has this hardcoded perms. if the app holds sdcard_rw they always allow access, ala legacy mode. However, they always assume backed by ext4 or an fs capable of per-file uid/gid. As they use this to confine apps to their package dir. I don't think we need to worry about if its backed by vfat, AOSP/Google devices have moved away from external sdcards. In the off chance we need to handle this, we can't just store the object secrutiy labels on the sdcard, its trivial to eject it and change the labels by hand, not sure if thats something we care about. We could always have some static path mapping to labels ala file_contexts and just always do a look up there. > > On Fri, Jan 2, 2015 at 1:39 PM, William Roberts > <[email protected]> wrote: > > So I was looking at the todo's placed on the bitbucket site. I figured I > > would take on the FUSE stuff, since that interests me the most. > > > > Outside of my first tought of grabbing PID from fuse_in_header and doing > a > > lookup which is mentioned in the wiki blurb on fuse. > > > > Stephen thinks the problem here is that pid can torially wrap, causing > the > > fs to lookup the context of the wrong application. While possible, the > worst > > case scenario is that data gets released t the FUSE driver, but since the > > original application requesting the data is dead for this occur, I dont > > think it matters. > > > > My second thought is, cant we just implement xattr support in the sdcard > > userspace portion of the fuse filesystem and selinux.security getxattr > > calls? > > > > I was looking at the kernel code in selinux and looks like it just calls > the > > indode operation for getxattr, which should result with fuse forwarding > it > > to the userspace fs. > > > > Then can't we just configure SELinux to use xattrs on fuse via: > > fs_use_xattr fuse u:object_r:labeledfs:s0; > > > > And lastly add the support to sdcardfs. > > > > If these ideas doen't work out of the box (except the userspace portion), > > the other options get gross quick considering that the security field in > the > > cred struct is an apaque pointer. We could replace the padding portion of > > fuse_in_header which is a uint32_t with a 4 byte identifier and some > common > > method for lsms to populate it. This, a call to some generic method would > > call an lsm specific handler to populate this field, for SELinux, it > could > > be the SID, but this seems awful. > > > > > > -- > > Respectfully, > > > > William C Roberts > > > > > > _______________________________________________ > > Seandroid-list mailing list > > [email protected] > > To unsubscribe, send email to [email protected]. > > To get help, send an email containing "help" to > > [email protected]. > -- Respectfully, William C Roberts
_______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
