Date:   Wed, 30 Jan 2019 08:19:46 -0800
From:   Casey Schaufler <casey@...aufler-ca.com>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     linux-api@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org, Al Viro <viro@...IV.linux.org.uk>,
        David Howells <dhowells@...hat.com>,
        Miklos Szeredi <miklos@...redi.hu>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Karel Zak <kzak@...hat.com>, util-linux@...r.kernel.org,
        Andy Lutomirski <luto@...capital.net>,
        LSM <linux-security-module@...r.kernel.org>,
        "SMACK-discuss@...ts.01.org" <SMACK-discuss@...ts.01.org>
Subject: Re: [RFD] A mount api that notices previous mounts

On 1/30/2019 4:47 AM, Eric W. Biederman wrote:
> ebiederm@...ssion.com (Eric W. Biederman) writes:
>
>> ebiederm@...ssion.com (Eric W. Biederman) writes:
>>
>>> Casey Schaufler <casey@...aufler-ca.com> 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
>
>

Powered by blists - more mailing lists