On Fri, Jan 2, 2015 at 12:15 PM, William Roberts <[email protected]> wrote:
> > > 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. > Sorry meant to write bits, there is a uint32 for padding at the end of the struct. > 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 > > -- 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].
