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].
