https://code.google.com/p/android/issues/detail?id=72971
On Fri, Jan 2, 2015 at 3:52 PM, Stephen Smalley <[email protected]> wrote: > No, you can't pass kernel SIDs to userspace; they aren't meaningful > there and there are no facilities for mapping kernel SIDs to security > contexts outside of the kernel. In the kernel, you can call > security_task_getsecid() and security_secid_to_secctx() to obtain a > security context string, but you'll have to pass it up out-of-band of > the regular fuse credentials. We did that in our binder security > context passing patches that were never mainlined. > > On Fri, Jan 2, 2015 at 3: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. 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].
