On Fri, Jan 2, 2015 at 12:54 PM, Stephen Smalley <[email protected]> wrote:
> 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. > I was looking at libselinux to see what selinux_check_access() does when I stated that, I thought this did the conversion, but looking at the type its obvious its a char * and a refcnt coupled. if ((rc = avc_context_to_sid(scon, &scon_id)) < 0) return rc; So I looked at the binder patches, this was the lsm function was what I was looking for: security_secid_to_secctx(). Then I can get the length, the ctx string, pad it, and add it into the transaction. What sucks, is userspace would need to do something like read the header, check if context_len > 0, then read N bytes of context. The nice apart about a fuse header is its a static size, no need to get fancy. Although, I am not a huge fan of this approach at the given time. I think attempting to the xattr support approach is the cleanest approach. Also, getpidcon(pid) isn't bad, as even if the data is sent back to the kernel for an allowed transaction on an invalid pid (in the case of rolled over pid), the originating process is dead, and no data would be transmitted. > > > > 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 > >> > -- 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].
