On Wed, Mar 22, 2023 at 9:28 AM Johannes Segitz <jsegitz@xxxxxxxx> wrote: > > On Fri, Mar 11, 2022 at 03:52:54PM -0500, Paul Moore wrote: > > On Fri, Mar 11, 2022 at 9:01 AM Vivek Goyal <vgoyal@xxxxxxxxxx> wrote: > > > Agreed. After going through the patch set, I was wondering what's the > > > overall security model and how to visualize that. > > > > > > So probably there needs to be a documentation patch which explains > > > what's the new security model and how does it work. > > > > Yes, of course. I'll be sure to add a section to the existing docs. > > > > > Also think both in terms of DAC and MAC. (Instead of just focussing too > > > hard on SELinux). > > > > Definitely. Most of what I've been thinking about the past day or so > > has been how to properly handle some of the DAC/capability issues; I > > have yet to start playing with the code, but for the most part I think > > the MAC/SELinux bits are already working properly. > > > > > My understanding is that in current model, some of the overlayfs > > > operations require priviliges. So mounter is supposed to be priviliged > > > and does the operation on underlying layers. > > > > > > Now in this new model, there will be two levels of check. Both overlay > > > level and underlying layer checks will happen in the context of task > > > which is doing the operation. So first of all, all tasks will need > > > to have enough priviliges to be able to perform various operations > > > on lower layer. > > > > > > If we do checks at both the levels in with the creds of calling task, > > > I guess that probably is fine. (But will require a closer code inspection > > > to make sure there is no privilege escalation both for mounter as well > > > calling task). > > > > I have thoughts on this, but I don't think I'm yet in a position to > > debate this in depth just yet; I still need to finish poking around > > the code and playing with a few things :) > > > > It may take some time before I'm back with patches, but I appreciate > > all of the tips and insight - thank you! > > Let me resurrect this discussion. With > https://github.com/fedora-selinux/selinux-policy/commit/1e8688ea694393c9d918939322b72dfb44a01792 > the Fedora policy changed kernel_t to a confined domain. This means that > many overlayfs setups that are created in initrd will now run into issues, > as it will have kernel_t as part of the saved credentials. So while the > original use case that inspired the patch set was probably not very common > that now changed. I don't remember anyone rejecting the patches on the account that the Android use case is not important. It was never the issue. > > It's tricky to work around this. Loading a policy in initrd causes a lot of > issues now that kernel_t isn't unconfined anymore. Once the policy is > loaded by systemd changing the mounts is tough since we use it for /etc and > at this time systemd already has open file handles for policy files in > /etc. > I've already explained several times on this thread what needs to be done in order to move forward - express the security model and explain why it is safe. If the security guys are going to be in LSS in Vancouver, perhaps we can have a meetup with overlayfs developers on the overlap day with LSFMM (May 10) to try and figure out a path forward. Thanks, Amir.
