linux-kernel - Re: Read-only `slaves` with shared subtrees?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20171009001546.GB5675@ram.oc3035372033.ibm.com>
Date:   Sun, 8 Oct 2017 19:15:46 -0500
From:   Ram Pai <linuxram@...ibm.com>
To:     Dawid Ciezarkiewicz <dawid.ciezarkiewicz@...rik.com>
Cc:     "Eric W. Biederman" <ebiederm@...ssion.com>,
        linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: Read-only `slaves` with shared subtrees?

On Fri, Sep 29, 2017 at 04:02:42PM -0700, Dawid Ciezarkiewicz wrote:
> On Fri, Sep 22, 2017 at 11:43 AM, Dawid Ciezarkiewicz
> <dawid.ciezarkiewicz@...rik.com> wrote:
> > On Thu, Sep 21, 2017 at 12:14 PM, Ram Pai <linuxram@...ibm.com> wrote:
> >> Here is a patch that accomplishes the job. tested to work with
> >> some simple use cases.  check if this works for you. If it does
> >> than we will have to think through all the edge cases and make it
> >> acceptable.
> >
> > From your experiments, it looks exactly right.
> >
> > I'll give it a try in the upcoming week. Thank you!
> 
> 
> I've reproduced your setup and results.
> 
> I've played with it for a while, mostly checking some recursive mount scenarios.
> My biggest concern is transitivity of the RO attribute. Once a root of
> slave directory
> is set to be RO + STICKY, it is very important that host directories
> propagated there,
> even recursively (rslave), or any other, are not RW. From what I was
> able to test, everything
> seemed OK, but I don't grok all the semantics around it, so I'm just
> pointing it out, as I might
> have missed something.

yes it will be RO. the patch takes care of that.

> 
> One thing that I don't plan to use, but might be worth thinking about is
>  `slave + RW + STICKY` combination.  If `master` mounts something RO,
> and `slave`
> is `RW + STICKY`, should the mount appear RW inside the slave? I don't
> find it particularly useful,
> but still...

As per the implemented semantics it will become "RW".  Should it be "RO"
aswell?  Will that open up security holes?

> 
> Another thing that popped into my head: Is it worth considering any
> dynamic changes to `slave`'s
> RO status? It complicates everything a lot (it seems to me), since it
> adds a retroactive
> dynamic propagation. I don't currently have any plans to use it, but I
> could imagine scenarios
> in which a slave mount with all it's sub-mounts is remounted from RO
> to RW, in response to
> some external authorization trigger.

The sematics should be something like this. Check if it makes sense.

a) anything mounted under stick-mount will be a sticky-mount and will
	inherit the mount's access-attribute;i.e RO RW attribute.
b) a mount when made sticky will propagate its sticky attribute
	as well as its access-attribute recursively to its children 
c) anything mounted under non-sticky mount will not inherit the
	mount's access-attribute and will be non-sticky aswell.
d) a mount when made non-sticky will just change itself to non-sticky.
	(will NOT propagate its non-sticky attribute and its
	access-attribue recursively to its children.)


Will this work?

> Regards,
> Dawid Ciezarkiewicz

-- 
Ram Pai