On 1/30/2019 4:47 AM, Eric W. Biederman wrote: > ebiederm@xxxxxxxxxxxx (Eric W. Biederman) writes: > >> ebiederm@xxxxxxxxxxxx (Eric W. Biederman) writes: >> >>> Casey Schaufler <casey@xxxxxxxxxxxxxxxx> writes: >>>> Are you taking the LSM specific mount options into account? >>> In the design yes, and I allow setting them. It appears in the code >>> to retrieve the mount options I forgot to call security_sb_show_options. >>> >>> For finding the super block that you are going to mount the LSM mount >>> options are not relevant. Even nfs will not want to set those early as >>> they do not help determine the nfs super block. So the only place where >>> there is anything interesting in my api is in reading back the security >>> options so they can be compared to the options the mounter is setting. >>> >>> I will add the missing call to security_sb_show_options which is enough >>> to fix selinux. Unfortunately smack does not currently implement >>> .sb_show_options. Not implementing smack_sb_show_options means >>> /proc/mounts fails to match /etc/mtab which is a bug and it is likely >>> a real workd bug for the people who use smack and don't want to depend >>> on /etc/mtab, or are transitioning away from it. >>> >>> Casey do you want to implement smack_sb_show_options or should I put it >>> on my todo list? >> Oh. I should add that I am always parsing the LSM mount options out so >> that there is not a chance of the individual filesystems implementing >> comflicting options even when there are no LSMs active. Without that I >> am afraid we run the risk of having LSM mount otions in conflict with >> ordinary filesystems options at some point and by the time we discover >> it it would start introducing filesystem regressions. >> >> That does help with stack though as there is no fundamental reason only >> one LSM could process mount options. > Sigh. I just realized that there is a smack variant of the bug I am > working to fix. > > smack on remount does not fail if you change the smack mount options. > It just silently ignores the smack mount options. Which is exactly the > same poor interaction with userspace that has surprised user space > and caused CVEs. > > How much do you think the smack users will care if you start verifying > that if smack options are present in remount that they are unchanged > from mount? I've added the smack-discuss list to the conversation. > I suspect the smack userbase is small enough, and the corner case is > crazy enough we can fix this poor communication by smack. Otherwise it > looks like there needs to be a new security hook so old and new remounts > can be distinguished by the LSMs, and smack can be fixed in the new > version. I fear that it may be worse than that. It's not enough to distinguish a mount from a remount. On remount you need an LSM specific way to compare mount options. Smack may decide that it's OK to remount a filesystem with more restrictive smackfshat values, for example. Or, it may allow smackfsroot=Pop for one and smackfstransmute=Pop on the other. I'm not sure about the 2nd case, but you should get the idea. > > Eric > >
